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.1.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
  - CapabilityInclusionRule
created_at: 2026-08-14
updated_at: 2026-08-14
---

# InfoTechCanon Capability Model

**Short Name:** `ITC-CAP`
**Document Status:** Proposed (assimilated, not yet promoted)
**Version:** 0.1.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 → cost         ← classification 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;
- the resource classes used to attribute cost to a provision;
- 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.

---

# 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, relationships, and typical resource
classes. Contracts live in `capabilities.yaml` and are the single source of
truth. This document does not restate them.

## 4.5 CapabilityRequirement

A statement that a system, product, or consumer purpose needs a capability at a
minimum maturity:

```yaml
requires:
  - capability: identity.authentication
    minimum_maturity: D5
  - capability: data.backup
    minimum_maturity: D5
```

A CapabilityRequirement is a **typed `DemandSignal`** (ITC-GOV Purpose and Demand
extension) carrying a minimum maturity. It does not introduce a parallel
requirement vocabulary.

## 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: auth.prod.eu
  capability: identity.authentication
  environment: production
  maturity: D6
```

## 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`). The model names dimensions; *targets and
measurement* belong to ITC-LAND service level objectives and ITC-OBS.

## 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 | Meaning |
|---|---|---|
| `C` | Compute | Generic execution capacity |
| `S` | Storage | Persistence capacity |
| `N` | Networking | Information movement |
| `I` | Intelligence | Metered or purchased cognitive / semantic processing |
| `P` | Platform | Enabling operational overhead |

Resource consumption attaches to a provision or implementation, never to an
abstract capability. This is what makes capability-oriented cost questions
answerable ("what does Authentication cost per tenant?").

---

# 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`.

---

# 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 |

Traversal from need to cost:

```text
ConsumerPurpose --requires--> Capability <--provides-- Service
                                                        │ implements
                                                        ▼
                                                   Technology
                                                        │ consumes
                                                        ▼
                                                  C / S / N / I / P
```

---

# 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, SLOs. ITC-CAP names abilities; ITC-LAND names the things that provide and implement them. `BusinessCapability` / `ProductCapability` in ITC-LAND §11 should resolve to references here. |
| ITC-GOV | Owns policy, control, evidence, assurance. ITC-CAP names capability evidence *hooks*, not evidence semantics. Capability requirements are typed demand signals from the Purpose and Demand extension. |
| ITC-ACCESS | Owns subject, principal, permission, grant, decision. `identity.*` capabilities are abilities over those mechanisms. |
| CARING | Access-governance analysis. May import `identity.*` ids; ITC-CAP takes no position on access-governance analysis. |
| ITC-OBS | Owns telemetry, SLO measurement, health — the source of measured maturity evidence. |
| ITC-DATA | Owns datasets, schemas, classification, lineage, retention. `data.*` capabilities are abilities over those assets. |
| ITC-DEVSECOPS | Owns source→artifact→release→deployment. `runtime.deployment` anchors there. |
| ITC-NET | Owns addressing, routing, exposure, reachability. `integration.traffic` anchors there. |
| ITC-TASK | Owns work items, actions, dependencies. `runtime.workflow` is the ability to orchestrate them. |

---

# 10. Status and Promotion

This model enters the canon at status `proposed`. Promotion requires:

1. ~~resolution of assimilation open question **OQ-2**~~ — **resolved in canon
   0.2.1**: the Security & Governance navigation domain was split into `security`
   and `governance`, aligning every id with its domain and changing no id;
2. publication of `capability.schema.yaml` validating contracts;
3. at least one canon Profile expressing a real capability requirement set with
   evidence;
4. formal mapping artifacts under `infospace/mappings/` for each anchor.

Tracked in `ITC-WP-0014`.

---

# 11. Provenance

Adapted from the Information Technology Capability Canon (ITCC) v0.1 under
disposition `adapt`. The frozen source snapshot, comparison matrix, mappings,
proposed changes, decision record, and open questions are held in
`infospace/assimilation/it-capability-canon/`.

Changes made on adoption: `Profile` renamed `CapabilityProfile`; `Provision` made
explicit; per-capability `anchors` added; requirements bound to Purpose and
Demand; the proposed CILM landscape model rejected in favour of ITC-LAND;
capability definitions moved wholly into the machine-readable catalog.