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: 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.