info-tech-canon/infospace/models/capability/InfoTechCanonCapabilityModel.md

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	source_version	source_body	source_file	assimilation	disposition	canonical_owner	namespace	classification	primary_cluster	catalog	imports	related	owned_concepts	created_at	updated_at
itc-cap:CapabilityModel	InfoTechCanon Capability Model	ITC-CAP	domain-model	InfoTechCanon	info-tech-canon	models/capability/InfoTechCanonCapabilityModel.md	proposed	0.1.0	0.1	Information Technology Capability Canon (ITCC)	infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md	assimilation/it-capability-canon	adapt	InfoTechCanonCapabilityModel	itc-cap	model	capability	models/capability/capabilities.yaml	InfoTechCanonCore InfoTechCanonLandscapeModel InfoTechCanonGovernanceModel InfoTechCanonPurposeDemandExtension InfoTechCanonObservabilityModel	InfoTechCanonKernelMap InfoTechCanonDataModel InfoTechCanonDevSecOpsModel InfoTechCanonNetworkModel InfoTechCanonAccessControlModel InfoTechCanonSecurityModel InfoTechCanonTaskModel InfoTechCanonCaringAccessGovernanceStandard	Capability CapabilityDomain CapabilityProfile CapabilityContract CapabilityRequirement CapabilityProvider CapabilityProvision CapabilityMaturityLevel CapabilityQualityDimension CapabilityEvidenceHook CapabilityResourceClass CapabilityInclusionRule	2026-08-14	2026-08-14

InfoTechCanon Capability Model

Short Name: ITC-CAP Document Status: Proposed (assimilated, not yet promoted) Version: 0.1.0 Document Type: InfoTechCanon Domain Model Machine-readable catalog: models/capability/capabilities.yaml Provenance: adapted from ITCC v0.1 — see assimilation/it-capability-canon

---

1. Purpose

The InfoTechCanon Capability Model defines what an information system must be able to do, independently of how that ability is implemented.

Every other InfoTechCanon model describes a structure: landscapes, data, tasks, policies, telemetry, delivery flow, access. None of them names the abilities those structures exist to deliver. The Landscape Model has deferred this ground explicitly since RC1 (§11.4: "The Landscape Model should keep only landscape-relevant references once a dedicated strategy/capability standard exists"). This model occupies it.

It sits deliberately between product and technology:

Consumer purpose / product
        │ requires
        ▼
Capability                      ← owned here
        │ provided by
        ▼
Service / provider              ← ITC-LAND
        │ implemented by
        ▼
Technology                      ← ITC-LAND
        │ consumes
        ▼
Resource classes → cost         ← classification owned here

---

2. Scope

2.1 In Scope

• the concept of a capability and its identity;
• capability profiles, quality dimensions, and evidence hooks;
• capability-to-capability and landscape-to-capability relationships;
• the provision of a capability by a provider in a context;
• the maturity scale that applies to a provision;
• the resource classes used to attribute cost to a provision;
• admission rules governing what may become a canonical capability;
• the canonical capability baseline held in capabilities.yaml.

2.2 Out of Scope

• landscape entities, services, technologies, and runtime resources — ITC-LAND;
• policy, control, and evidence semantics — ITC-GOV;
• permission, grant, and authorization-decision semantics — ITC-ACCESS;
• telemetry, SLO measurement, and health — ITC-OBS;
• delivery pipeline semantics — ITC-DEVSECOPS;
• domain-specific business capabilities (hospital admission, underwriting, warehouse picking) — outside InfoTechCanon;
• product features, protocols, and named technologies.

---

3. Core Principle

A capability is an abstract, implementation-independent ability that an information system, service, platform, or product may require or provide.

Technologies are never capabilities:

Authentication          capability
Keycloak                implementation

Backup & Restore        capability
pgBackRest              implementation

Object Persistence      capability
S3                      implementation

The model is expected to remain stable while technologies, vendors, protocols, and architectures change beneath it.

---

4. Concepts

4.1 Capability

An abstract ability, identified by a stable dotted id (identity.authentication). A capability has a purpose, profiles, quality dimensions, evidence hooks, and relationships — but no maturity, no cost, and no implementation.

Capability ids are durable interfaces. Renaming or removing one requires explicit migration semantics.

4.2 CapabilityDomain

A navigation grouping (identity, data, commerce, …). Domains carry no semantics: the model is a graph, per Core §6.4 Network Before Tree. Capabilities may depend on or compose capabilities across domain boundaries.

4.3 CapabilityProfile

A constrained specialization of a capability that does not change its identity — subject, assurance level, protocol, consistency, tenancy, geography, and so on.

Distinction. A CapabilityProfile is not a canon Profile (Core §8.6). A canon Profile constrains canon artifacts for an implementation context (e.g. small-saas). A CapabilityProfile constrains one capability. A canon Profile may select capability profiles; it is not one.

Prefer a new profile over a new capability whenever the underlying ability is unchanged (Core §6.5 Profiles, Not Forks).

4.4 CapabilityContract

The machine-readable definition of a capability: id, name, purpose, anchors, profiles, quality dimensions, evidence hooks, relationships, and typical resource classes. Contracts live in capabilities.yaml and are the single source of truth. This document does not restate them.

4.5 CapabilityRequirement

A statement that a system, product, or consumer purpose needs a capability at a minimum maturity:

requires:
  - capability: identity.authentication
    minimum_maturity: D5
  - capability: data.backup
    minimum_maturity: D5

A CapabilityRequirement is a typed DemandSignal (ITC-GOV Purpose and Demand extension) carrying a minimum maturity. It does not introduce a parallel requirement vocabulary.

4.6 CapabilityProvider

A role played by a landscape entity — a service, service instance, platform team, or external provider — that supplies a capability in a context. The entity itself is owned by ITC-LAND; only the role is named here.

4.7 CapabilityProvision

The binding of provider × capability × context. Maturity, evidence, and resource consumption all attach here.

provision:
  provider: auth.prod.eu
  capability: identity.authentication
  environment: production
  maturity: D6

4.8 CapabilityMaturityLevel

Level	State	Meaning
D0	Absent	Capability is not provided
D1	Experimental	Proof of concept or exploratory implementation
D2	Available	A provider exists and can be consumed
D3	Usable	Documented and practically consumable
D4	Production	Approved for production dependency
D5	Reliable	Reliability is measured and actively controlled
D6	Scalable	Capacity and operational scaling are demonstrated
D7	Strategic	Governed, reusable, deliberately evolved as a platform capability

Maturity is not a canon artifact status (Core §10) and not a conformance level (Core §18). It describes a provision, not a document and not a consumer.

4.9 CapabilityQualityDimension

A named quality attribute relevant to a capability (rpo, rto, assurance, decision_latency, explainability). The model names dimensions; targets and measurement belong to ITC-LAND service level objectives and ITC-OBS.

4.10 CapabilityEvidenceHook

The evidence types expected to substantiate a provision (successful_restore_test, measured_rpo, policy_tests). Evidence semantics are imported from ITC-GOV; telemetry-derived evidence comes from ITC-OBS.

4.11 CapabilityResourceClass

ID	Class	Meaning
C	Compute	Generic execution capacity
S	Storage	Persistence capacity
N	Networking	Information movement
I	Intelligence	Metered or purchased cognitive / semantic processing
P	Platform	Enabling operational overhead

Resource consumption attaches to a provision or implementation, never to an abstract capability. This is what makes capability-oriented cost questions answerable ("what does Authentication cost per tenant?").

---

5. Normative Rules

CAP-R1 A Capability MUST be implementation-independent. Naming a technology, product, protocol, or vendor as a capability is invalid.

CAP-R2 Maturity MUST attach to a CapabilityProvision. A maturity claim on a Capability is invalid:

# invalid                          # valid
capability: identity.authentication   provider: auth.prod.eu
maturity: D5                          capability: identity.authentication
                                      maturity: D5

CAP-R3 Every Capability MUST declare anchors — the canon model(s) owning the concepts it exercises — or carry an explicit anchor_note recording that it is new canon surface with no owner yet.

CAP-R4 A Capability MUST NOT define concepts owned elsewhere. security.policy imports ITC-GOV Policy and Control; identity.authorization imports ITC-ACCESS Permission, Grant, and AuthorizationDecision. (Core §6.2, §6.3.)

CAP-R5 Capability ids MUST be treated as durable interfaces. Rename or removal requires a ChangeRecord with migration semantics and a canon major version.

CAP-R6 A specialization that leaves the underlying ability unchanged MUST be expressed as a CapabilityProfile, not a new Capability.

CAP-R7 The Markdown document MUST NOT restate capability definitions held in capabilities.yaml.

---

6. Admission Rules

A concept enters the canonical capability set only if it is:

1. implementation-independent — survives replacement of the technology;
2. reusable — occurs across materially different products or systems;
3. demandable — a system can meaningfully require it;
4. providable — something can meaningfully provide it;
5. testable — evidence can show it exists and functions;
6. profileable — specializations expressible as profiles;
7. stable — likely to outlive individual products, protocols, and vendors.

Explicitly excluded: technologies; protocols and standards; product features; and domain-specific business capabilities.

---

7. Relationships

Capability to capability:

Type	Meaning
depends_on	The capability normally requires another to operate
may_use	May use another without conceptual dependency
composes	A higher-level capability or pattern built from lower-level ones

Landscape and consumer to capability:

Type	Meaning
requires	A product, workload, service, or consumer purpose requires a capability
provides	A provider supplies a capability (creates a provision)
implements	A technology realizes all or part of a provider
consumes	A provision consumes resource classes

Traversal from need to cost:

ConsumerPurpose --requires--> Capability <--provides-- Service
                                                        │ implements
                                                        ▼
                                                   Technology
                                                        │ consumes
                                                        ▼
                                                  C / S / N / I / P

---

8. Catalog

The baseline is 41 capabilities across 8 navigation domains, held in models/capability/capabilities.yaml.

Domain	Count	Capability ids
Identity & Access	5	identity.lifecycle, identity.authentication, identity.authorization, identity.federation, identity.organization
Data & State	6	data.transactional, data.object, data.cache, data.backup, data.archive, data.search
Integration & Communication	5	integration.api, integration.messaging, integration.exchange, integration.notification, integration.traffic
Runtime & Automation	5	runtime.execution, runtime.configuration, runtime.scheduling, runtime.workflow, runtime.deployment
Operations & Assurance	5	operations.observability, operations.alerting, operations.audit, operations.recovery, operations.continuity
Security & Governance	6	security.secrets, security.keys, security.policy, security.vulnerability, governance.evidence, governance.lifecycle
Commerce	4	commerce.metering, commerce.billing, commerce.payment, commerce.entitlement
Intelligence	5	intelligence.generation, intelligence.extraction, intelligence.embedding, intelligence.retrieval, intelligence.reasoning

Seven capabilities (commerce.metering, commerce.billing, commerce.payment, intelligence.generation, intelligence.extraction, intelligence.embedding, intelligence.reasoning) are unanchored — new canon surface with no owning model. This is accepted at proposed status and tracked as OQ-5.

---

9. Boundary with Other Models

Model	Boundary
ITC-LAND	Owns services, technologies, runtime resources, SLOs. ITC-CAP names abilities; ITC-LAND names the things that provide and implement them. BusinessCapability / ProductCapability in ITC-LAND §11 should resolve to references here.
ITC-GOV	Owns policy, control, evidence, assurance. ITC-CAP names capability evidence hooks, not evidence semantics. Capability requirements are typed demand signals from the Purpose and Demand extension.
ITC-ACCESS	Owns subject, principal, permission, grant, decision. identity.* capabilities are abilities over those mechanisms.
CARING	Access-governance analysis. May import identity.* ids; ITC-CAP takes no position on access-governance analysis.
ITC-OBS	Owns telemetry, SLO measurement, health — the source of measured maturity evidence.
ITC-DATA	Owns datasets, schemas, classification, lineage, retention. data.* capabilities are abilities over those assets.
ITC-DEVSECOPS	Owns source→artifact→release→deployment. runtime.deployment anchors there.
ITC-NET	Owns addressing, routing, exposure, reachability. integration.traffic anchors there.
ITC-TASK	Owns work items, actions, dependencies. runtime.workflow is the ability to orchestrate them.

---

10. Status and Promotion

This model enters the canon at status proposed. Promotion requires:

1. resolution of assimilation open question OQ-2 (the governance.* id prefix inside the Security & Governance domain) — blocking, because ids are durable interfaces;
2. publication of capability.schema.yaml validating contracts;
3. at least one canon Profile expressing a real capability requirement set with evidence;
4. formal mapping artifacts under infospace/mappings/ for each anchor.

Tracked in ITC-WP-0014.

---

11. Provenance

Adapted from the Information Technology Capability Canon (ITCC) v0.1 under disposition adapt. The frozen source snapshot, comparison matrix, mappings, proposed changes, decision record, and open questions are held in infospace/assimilation/it-capability-canon/.

Changes made on adoption: Profile renamed CapabilityProfile; Provision made explicit; per-capability anchors added; requirements bound to Purpose and Demand; the proposed CILM landscape model rejected in favour of ITC-LAND; capability definitions moved wholly into the machine-readable catalog.