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

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	source_version	source_body	source_file	assimilation	disposition	canonical_owner	namespace	classification	primary_cluster	catalog	imports	related	owned_concepts	created_at	updated_at
itc-cap:CapabilityModel	InfoTechCanon Capability Model	ITC-CAP	domain-model	InfoTechCanon	info-tech-canon	models/capability/InfoTechCanonCapabilityModel.md	proposed	0.2.0	0.1	Information Technology Capability Canon (ITCC)	infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md	assimilation/it-capability-canon	adapt	InfoTechCanonCapabilityModel	itc-cap	model	capability	models/capability/capabilities.yaml	InfoTechCanonCore InfoTechCanonLandscapeModel InfoTechCanonGovernanceModel InfoTechCanonPurposeDemandExtension InfoTechCanonObservabilityModel	InfoTechCanonKernelMap InfoTechCanonDataModel InfoTechCanonDevSecOpsModel InfoTechCanonNetworkModel InfoTechCanonAccessControlModel InfoTechCanonSecurityModel InfoTechCanonTaskModel InfoTechCanonCaringAccessGovernanceStandard	Capability CapabilityDomain CapabilityProfile CapabilityContract CapabilityRequirement CapabilityProvider CapabilityProvision CapabilityMaturityLevel CapabilityQualityDimension CapabilityEvidenceHook CapabilityResourceClass CapabilityConsumption CapabilityInclusionRule	2026-08-14	2026-08-15

InfoTechCanon Capability Model

Short Name: ITC-CAP Document Status: Proposed (assimilated, not yet promoted) Version: 0.2.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:

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:

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:

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.

provision:
  provider: backup.barman.prod
  capability: data.backup
  profile: database
  environment: production
  maturity: D4
  consumes:
    - class: S
      quantity: {value: 50, unit: GB}
      period: month
    - class: H
      quantity: {value: 1.0, unit: hour}
      period: month
      supply: internal
    - class: P
      quantity: {value: 1, unit: unit}
      period: month
      supply: external
    - class: I
      quantity: unknown

Unknown consumption MUST be recorded as unknown, never as zero. Zero means "measured and none"; unknown means "not yet measured or not applicable."

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.

---

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:

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

---

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:

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

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.