coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Assimilate ITCC v0.1 as Capability Model; canon 0.2.0
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Define the intake and assimilation practice (incoming/ drop zone -> frozen
source snapshot -> Minimal Assimilation Profile -> disposition gate -> canon
transformation -> versioned change notes) and run it on the first inputs.

- infospace/assimilation/intake-and-assimilation-practice.md, incoming/README.md
- assimilation/it-capability-canon: frozen source, comparison matrix, 26
  mappings, 8 proposed changes, 7 open questions, decision record (adapt)
- new model ITC-CAP with 41-capability machine-readable catalog, anchored to
  owning canon models; CILM rejected, Profile renamed, Provision made explicit
- registered in canon.yaml / artifacts index / infospace.yaml; regenerated
  briefs, indexes, views; canon version 0.1.0-scaffold -> 0.2.0 + CHANGELOG
- ITC-WP-0014 for promotion work; ITC-WP-0013 added to the workplan registry

make validate: ok (65 artifacts, 0 errors/warnings). make test: 22 passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-14 20:54:32 +02:00
parent b8d060b5b5
commit 28d5824362
37 changed files with 5333 additions and 93 deletions
Download patch file Download diff file Expand all files Collapse all files

411
infospace/models/capability/InfoTechCanonCapabilityModel.md Normal file
View file

@ -0,0 +1,411 @@
---
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 8 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 & Governance | 6 | `security.secrets`, `security.keys`, `security.policy`, `security.vulnerability`, `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** (the `governance.*` id prefix
inside the Security & Governance domain) — blocking, because ids are durable
interfaces;
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.