--- 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.3.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.3.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 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`). ## 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. --- # 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, 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 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 **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, and constraint predicates) 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.