--- id: itc-cap:CapabilityModel title: InfoTechCanon Capability Model short_name: ITC-CAP type: domain-model standard_family: InfoTechCanon repository_context: info-tech-canon recommended_path: models/capability/InfoTechCanonCapabilityModel.md status: proposed version: 0.1.0 source_version: "0.1" source_body: Information Technology Capability Canon (ITCC) source_file: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md assimilation: assimilation/it-capability-canon disposition: adapt canonical_owner: InfoTechCanonCapabilityModel namespace: itc-cap classification: model primary_cluster: capability catalog: models/capability/capabilities.yaml imports: - InfoTechCanonCore - InfoTechCanonLandscapeModel - InfoTechCanonGovernanceModel - InfoTechCanonPurposeDemandExtension - InfoTechCanonObservabilityModel related: - InfoTechCanonKernelMap - InfoTechCanonDataModel - InfoTechCanonDevSecOpsModel - InfoTechCanonNetworkModel - InfoTechCanonAccessControlModel - InfoTechCanonSecurityModel - InfoTechCanonTaskModel - InfoTechCanonCaringAccessGovernanceStandard owned_concepts: - Capability - CapabilityDomain - CapabilityProfile - CapabilityContract - CapabilityRequirement - CapabilityProvider - CapabilityProvision - CapabilityMaturityLevel - CapabilityQualityDimension - CapabilityEvidenceHook - CapabilityResourceClass - CapabilityInclusionRule created_at: 2026-08-14 updated_at: 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: ```text 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: ```text 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: ```yaml 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. ```yaml 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: ```yaml # 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: ```text ConsumerPurpose --requires--> Capability <--provides-- Service │ implements ▼ Technology │ consumes ▼ C / S / N / I / P ``` --- # 8. Catalog The baseline is **41 capabilities across 9 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 | 4 | `security.secrets`, `security.keys`, `security.policy`, `security.vulnerability` | | Governance | 2 | `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**~~ — **resolved in canon 0.2.1**: the Security & Governance navigation domain was split into `security` and `governance`, aligning every id with its domain and changing no id; 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.