--- 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.2.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 - CapabilityConsumption - CapabilityInclusionRule created_at: 2026-08-14 updated_at: 2026-08-15 --- # InfoTechCanon Capability Model **Short Name:** `ITC-CAP` **Document Status:** Proposed (assimilated, not yet promoted) **Version:** 0.2.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 → native units ← classification owned here (currency overlay is not 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; - intended quality targets and placement constraints on a requirement; - the resource classes used to classify consumption of a provision; - consumption records in each class's native unit; - 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; - booked cost, currency handling, and ledgers — `fin-hub` under its exchange contract; - a canonical exchange rate between human effort and intelligence; - timesheet methods or labour rates. --- # 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, and relationships. Contracts live in `capabilities.yaml` and are the single source of truth. This document does not restate them. A contract does **not** declare resource classes. Consumption is a property of a provision, not of an abstract ability (see §4.11, CAP-R8). ## 4.5 CapabilityRequirement A statement that a system, product, or consumer purpose needs a capability at a minimum maturity. It may also select a profile, assert intended quality targets against the capability's declared dimensions, and state placement constraints: ```yaml requires: - capability: identity.authentication minimum_maturity: D5 - capability: data.backup profile: database minimum_maturity: D5 targets: rpo: {value: 5, unit: minutes} rto: {value: 60, unit: minutes} retention: {value: 30, unit: days} constraints: - dimension: geographical_separation predicate: not_in of: - {kind: host, id: railiance01} ``` A CapabilityRequirement is a **typed `DemandSignal`** (ITC-GOV Purpose and Demand extension). It does not introduce a parallel requirement vocabulary. Rules: - `profile`, if present, MUST be a profile declared on that capability. - Every key of `targets` MUST be a quality dimension declared on that capability. - Every `constraints[].dimension` MUST be a quality dimension declared on that capability. - `of` entries are consumer landscape references, not canon identifiers. - Closed predicates: `not_in`, `in`, `equals`, `lte`, `gte`. A target is an *intended* value. It does not create an SLO and does not measure anything. Measurement and observed values belong to ITC-LAND service level objectives and ITC-OBS (see §4.9). This is what lets a consumer write a need before any provider exists. ## 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: backup.barman.prod capability: data.backup profile: database environment: production maturity: D4 consumes: - class: S quantity: {value: 50, unit: GB} period: month - class: H quantity: {value: 1.0, unit: hour} period: month supply: internal - class: P quantity: {value: 1, unit: unit} period: month supply: external - class: I quantity: unknown ``` Unknown consumption MUST be recorded as `unknown`, never as zero. Zero means "measured and none"; unknown means "not yet measured or not applicable." A provision MAY override a class's default `supply` and `capacity_behaviour` (for example contracted operator time recorded as `H` with `supply: external`). ## 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`, `intelligence_intensity`). The model names dimensions. - **Intended targets** against those dimensions belong on a CapabilityRequirement (§4.5). They are demand assertions. - **Measurement and observed values** belong to ITC-LAND service level objectives and ITC-OBS. They are supply observations. A requirement written before any provider exists therefore does not depend on a service-level objective that cannot yet exist. `intelligence_intensity` is the consumption of class `I` per unit of capability output. It is a quality of a provision that consumes Intelligence, not a cost line. It is declared on the `intelligence.*` capabilities and may be used on any provision that consumes `I`. ## 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 | Native unit | Default supply | Default capacity | |---|---|---|---|---| | `C` | Compute | `vCPU-hour` | external | elastic | | `S` | Storage | `GB` | external | elastic | | `N` | Networking | `GB` | external | elastic | | `I` | Intelligence | `token` | external | elastic | | `H` | Human Effort | `hour` | internal | constrained | | `P` | Platform | `unit` | external | elastic | **Supply** is `internal` (drawn from own capacity) or `external` (purchased). It is a sourcing attribute of a consumption record, not a separate class. Internal versus contracted labour are both `H`. **Capacity behaviour** is `elastic` (more is purchasable at roughly linear cost inside the planning horizon) or `constrained` (a hard ceiling). Human effort inside a founder- or team-hour budget is constrained; tokens and object storage are elastic. Class meanings: - `C` — generic execution capacity. - `S` — persistence capacity. - `N` — information movement. Native unit is transfer volume. - `I` — metered cognitive or semantic processing, treated as the elastic purchased substitute for `H`. Its unit cost is assumed to decline over time; that is a modelling assumption, not a constant the canon asserts a value for. - `H` — human attention applied to provide or operate the capability. Native unit is hours. `H` exists so that labour can bind a decision as a ceiling, not only as a price. - `P` — purchased platform and enabling services that make other resources usable. `P` does **not** absorb human time. The letter is `H` (not `L` for labour) so the human / intelligence contrast is the one the class set is designed to make observable. A provision may record a more specific compatible unit (`GPU-hour` under `C`) but SHOULD keep the class. Recommended native units for `C` and `P` are weak because those classes are heterogeneous; `hour`, `token`, and `GB` are the units the class set is required to protect. Resource consumption attaches to a provision or implementation, **never to an abstract capability**. This is what makes capability-oriented questions answerable ("what does Authentication consume per tenant, in hours and in tokens?"). ## 4.12 CapabilityConsumption One row of a provision's `consumes` list. It records use of a single resource class in that class's **native unit**, optionally over a period. Currency is not a resource class and is not a native unit. A financial overlay — converting hours or tokens into money — is performed by the consumer or by `fin-hub` under its own exchange contract. Collapsing classes into currency at capture time destroys the information needed for constraint and substitution reasoning. The canon does **not** declare a `substitutes_for` relation or an exchange rate between classes. If `H` and `I` appear on the same provision in native units, substitution is observable from the time series. --- # 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`. **CAP-R8** Resource consumption MUST attach to a CapabilityProvision or implementation, never to a Capability. A Capability contract MUST NOT carry a normative resource-class declaration. A consumption record MUST use the class's native unit. Unknown MUST be recorded as `unknown`, never as zero. **CAP-R9** A CapabilityRequirement `profile`, target key, or constraint dimension MUST be declared on the required capability. A target is an intended value, not a measurement. --- # 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 in native units | Traversal from need to consumption: ```text ConsumerPurpose --requires--> Capability <--provides-- Service │ │ implements │ targets, constraints ▼ ▼ Technology CapabilityRequirement │ consumes ▼ C / S / N / I / H / P (native units; unknown allowed) ``` --- # 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, and *observed* SLOs. ITC-CAP names abilities and *intended* requirement targets; 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. Version 0.2.0 (canon 0.3.0) refines the proposed model from consumer demand `demand/CapabilityProvisionEconomics.md`: resource-class declaration moved off the contract onto the provision; requirements gained profile, targets, and constraints; class `H` added; `P` narrowed; `I` recharacterised; consumption records use native units. See the decision record in `assimilation/it-capability-canon/ASSIMILATION.md`.