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

---
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
  - InfoTechCanonEvidenceModel
  - InfoTechCanonPurposeDemandExtension
  - InfoTechCanonObservabilityModel
related:
  - InfoTechCanonKernelMap
  - InfoTechCanonDataModel
  - InfoTechCanonDevSecOpsModel
  - InfoTechCanonNetworkModel
  - InfoTechCanonAccessControlModel
  - InfoTechCanonSecurityModel
  - InfoTechCanonTaskModel
  - InfoTechCanonCaringAccessGovernanceStandard
owned_concepts:
  - Capacity behaviour
  - Supply
  - 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 and control semantics — ITC-GOV;
- general evidence and source semantics — ITC-EVID;
- 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.