--- 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: draft version: 0.4.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:** Draft (promoted; contract frozen at canon 0.6.0) **Version:** 0.4.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 uses_provisions: - capability: data.object provider: object.scaleway.nl-ams relation: depends_on - capability: security.secrets provider: openbao.reef-railiance relation: may_use consumes: - class: S quantity: {value: 50, unit: GB} period: month basis: measured - class: H quantity: {value: 1.0, unit: hour} period: month supply: internal basis: assumed - class: P quantity: {value: 1, unit: unit} period: month supply: external basis: quoted - class: I quantity: unknown basis: unknown ``` Unknown consumption MUST be recorded as `unknown`, never as zero. Zero means "measured and none"; unknown means "not yet measured or not applicable." Every consumption row MUST declare an **EvidenceBasis** (ITC-GOV): how the quantity was obtained. The closed scale, propagation rule, and decision grades are owned there; this model imports them. A row with basis `unknown` MUST NOT carry a quantity. A row with any other basis MUST carry a quantity. A provision MAY override a class's default `supply` and `capacity_behaviour` (for example contracted operator time recorded as `H` with `supply: external`). A provision MAY name the provisions it relies on under `uses_provisions`. That list is not consumption. `consumes` records resource classes in native units; `uses_provisions` records which other provision supplies an ability. ```yaml uses_provisions: - capability: data.object # catalog id provider: object.scaleway.nl-ams # consumer landscape reference relation: depends_on # or may_use ``` Rules: - `capability` MUST be a catalog id. - `provider` is a consumer landscape reference, not a canon identifier (ITC-LAND owns provider identity). - `relation` MUST be `depends_on` or `may_use` — the same vocabulary as capability-to-capability relationships. There is no third spelling (`uses` is `may_use`). - A `depends_on` entry MUST match a `depends_on` declared between those two capabilities in the catalog. - A `may_use` entry SHOULD match a catalog `may_use`. A specific provision MAY record a use the abstract capability does not declare. - The list does not cap maturity. Whether a provision's maturity is bounded by what it depends on is a separate question. ## 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. A consumption row without a basis is invalid. Collapsing `measured` and `assumed` into one number is the same defect as collapsing hours and tokens into currency: it destroys the information a decision actually rests on. --- # 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. **CAP-R10** A CapabilityConsumption MUST declare `basis` from the ITC-GOV EvidenceBasis catalog. Basis `unknown` MUST NOT carry a quantity; any other basis MUST. A derived value MUST name its inputs; its effective basis is the weakest *tier* among those inputs (ITC-GOV). Members of the same tier do not rank against each other. Evidence items on a provision SHOULD declare a basis on the same scale. **CAP-R11** A provision that relies on another provision MUST record that fact under `uses_provisions`, not as a `consumes` row. `relation` MUST be `depends_on` or `may_use`. A `depends_on` entry MUST be declared between those capabilities in the catalog. Using another capability is not consuming class `P`. --- # 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 | Provision to provision (`uses_provisions`): | Type | Meaning | |---|---| | `depends_on` | This provision requires that provision to operate; the pair MUST be a catalog `depends_on` | | `may_use` | This provision uses that provision without a catalog-hard dependency | 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, and **EvidenceBasis** (how a quantity was obtained). ITC-CAP names capability evidence *hooks*, not evidence semantics. A `CapabilityConsumption` MUST declare an EvidenceBasis. 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 is **draft** as of canon 0.6.0. The contract is frozen. Further shape change needs a new minor of ITC-CAP and a CHANGELOG entry. Promotion from `proposed` required: 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 **joinable proof** that a real capability requirement set has been expressed with provisions and evidence. A proof is either: - a canon Profile containing such a set, or - a consumer record that validates against the live catalog (capability ids, profiles, quality dimensions, evidence hooks, resource classes, native units, constraint predicates, and `uses_provisions` relations) and is cited from this repository as PurposeFit evidence under `feedback/`. Operational facts stay in the consumer repo. The join is the capability id (CAP-R5). A fictional in-repo example is a weaker proof than a consumer record that already fails or passes against this catalog. **Met 2026-08-15** by resource-control `data/capability/platform-audit-storage.json` (commit `13c2b82`), cited in `feedback/2026-08-15-resource-control-cap-restatement.md`. 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`. Version 0.3.0 (canon 0.4.0) accepts a consumer record that validates against the live catalog as a promotion proof (§10.3), and requires EvidenceBasis on every consumption row (CAP-R10). EvidenceBasis is owned by ITC-GOV. Version 0.4.0 (canon 0.5.0) adds `uses_provisions` so a provision can name which other provision satisfies a catalog dependency (CAP-R11). Using another capability is not consuming class `P`. `data.backup` gains catalog `may_use: security.secrets` from consumer evidence. Maturity is not capped across the dependency.