coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/models/capability/InfoTechCanonCapabilityModel.md
tegwick b69b048dcb
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Canon 0.3.0: capability provision economics (ITC-CAP 0.2.0) 
Accept resource-control demand: move resource classes onto provisions,
let requirements carry targets and constraints, add human-effort class H
with native-unit consumption. Model stays proposed.
2026-08-15 18:19:30 +02:00

546 lines
22 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
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.2.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.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:
```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
- 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:
```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.
---
# 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. 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`.
Reference in a new issue View git blame Copy permalink