Assimilate ITCC v0.1 as Capability Model; canon 0.2.0

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>
2026-08-14 20:54:32 +02:00 · 2026-08-14 20:54:32 +02:00 · 28d5824362
commit 28d5824362
parent b8d060b5b5
37 changed files with 5333 additions and 93 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -0,0 +1,101 @@
+# Changelog — InfoTechCanon
+
+Canon versions and their change notes. Entries follow the ChangeRecord shape of
+`InfoTechCanonCore` §8.13: what changed, rationale, whether it is breaking, and
+what produced it.
+
+Versioning of `canon.yaml → version`:
+
+- **patch** — editorial or generated-output changes; no concept change
+- **minor** — new artifact, new concepts, backward-compatible extension
+- **major** — a concept is removed, renamed, or its ownership moves
+
+Canonical identifiers are durable interfaces; any break requires migration
+semantics.
+
+---
+
+## 0.2.0 — 2026-08-14
+
+### Added — InfoTechCanon Capability Model (`ITC-CAP`)
+
+**Change.** The canon gains a twelfth domain model,
+`infospace/models/capability/InfoTechCanonCapabilityModel.md`, with its
+machine-readable baseline at `infospace/models/capability/capabilities.yaml`:
+41 capabilities across 8 navigation domains, the D0–D7 provision maturity scale,
+the C/S/N/I/P resource classes, capability relationship types, and admission
+rules.
+
+New canonical concepts: `Capability`, `CapabilityDomain`, `CapabilityProfile`,
+`CapabilityContract`, `CapabilityRequirement`, `CapabilityProvider`,
+`CapabilityProvision`, `CapabilityMaturityLevel`, `CapabilityQualityDimension`,
+`CapabilityEvidenceHook`, `CapabilityResourceClass`, `CapabilityInclusionRule`.
+
+**Rationale.** The canon modelled landscape, data, security, delivery, network,
+observability, governance, organization, task, and access — but never *what an
+information system must be able to do*. The Landscape Model deferred this ground
+explicitly (§11.4). Consumers were already working around the gap.
+
+**Source and disposition.** Adapted from the Information Technology Capability
+Canon (ITCC) v0.1 under assimilation `assimilation/it-capability-canon`,
+disposition `adapt`. Changes made on adoption:
+
+- `Profile` renamed to `CapabilityProfile` — the name collided with the canon
+  `Profile` artifact type (Core §8.6);
+- `CapabilityProvision` made explicit, so maturity has a defined bearer;
+- per-capability `anchors` added, naming the canon model(s) owning the concepts
+  each capability exercises (guards Core §6.2 and §6.3);
+- `CapabilityRequirement` bound to the Purpose and Demand extension as a typed
+  `DemandSignal` rather than a parallel vocabulary;
+- the source's proposed CILM landscape model **rejected** — the Landscape Model
+  already owns that ground;
+- capability definitions held only in YAML; the Markdown does not restate them.
+
+**Breaking:** no. No existing canonical concept was removed, renamed, or moved.
+
+**Artifact status.** The model enters at `proposed`. Promotion requires
+resolution of open question OQ-2 (the `governance.*` id prefix), a published
+contract schema, formal mapping artifacts, and one profile expressing a real
+requirement set with evidence — tracked in `ITC-WP-0014`.
+
+**Known weakness.** Seven capabilities (`commerce.*` except `entitlement`, and
+four `intelligence.*`) are unanchored — new canon surface with no owning model
+(OQ-5). Accepted at `proposed` status.
+
+### Added — Intake and Assimilation Practice
+
+`infospace/assimilation/intake-and-assimilation-practice.md` defines the
+repository-wide procedure for absorbing new concepts and terminology: the
+`incoming/` drop zone, frozen source snapshots, the Minimal Assimilation Profile,
+the disposition gate, canon transformation and registration, and the resulting
+canon version with change notes. `incoming/README.md` documents the drop zone.
+
+**Rationale.** Inputs previously had no defined path from arrival to canon,
+risking the copy-paste assimilation Core §29.6 warns against.
+
+### Changed
+
+- `canon.yaml` — version `0.1.0-scaffold` → `0.2.0`; `itc-cap` registered under
+  `models:` with assimilation provenance.
+- `infospace/artifacts/index.yaml` — registered `model/capability`,
+  `capability-catalog/itc-cap`, `assimilation/it-capability-canon`,
+  `practice/intake-and-assimilation` (65 artifacts, up from 61).
+- `infospace/infospace.yaml` — Capability Model added to disciplines.
+- Regenerated agent briefs, retrieval indexes, and views.
+- `tests/` — artifact and model counts updated to match the registered canon.
+- `workplans/index.yaml` — registered `ITC-WP-0014`, and `ITC-WP-0013` which was
+  missing from the registry.
+
+### Validation
+
+`make validate` passes with 0 errors and 0 warnings (65 artifacts, 286
+relationships, 0 consistency cycles, coverage 1.0, redundancy 0.0).
+`make test` passes (22 tests).
+
+---
+
+## 0.1.0-scaffold
+
+Seed kernel: kernel documents, eleven domain models, three standards, the
+infospace scaffold, service surface (CLI / JSON / API), generated views and
+agent briefs. See `workplans/` ITC-WP-0001 through ITC-WP-0012 for the history.
--- a/canon.yaml
+++ b/canon.yaml
@ -1,7 +1,7 @@
 repository: info-tech-canon
 title: InfoTechCanon
 status: service-baseline
-version: 0.1.0-scaffold
+version: 0.2.0
 description: >
  An evolving, markdown-first canon for building interoperable, adaptable,
  and extensible information-processing systems.
@ -89,6 +89,16 @@ models:
    title: InfoTechCanonObservabilityModel
    path: infospace/models/observability/InfoTechCanonObservabilityModel.md
    status: RC1-seed
+  - id: itc-cap
+    title: InfoTechCanonCapabilityModel
+    path: infospace/models/capability/InfoTechCanonCapabilityModel.md
+    status: proposed
+    catalog: infospace/models/capability/capabilities.yaml
+    provenance:
+      assimilation: assimilation/it-capability-canon
+      source_body: Information Technology Capability Canon (ITCC)
+      source_version: "0.1"
+      disposition: adapt

 standards:
  - id: itc-tag
@ -131,6 +141,20 @@ workplans:
    - ITC-WP-0008
    - ITC-WP-0009
    - ITC-WP-0010
+    - ITC-WP-0011
+    - ITC-WP-0012
+    - ITC-WP-0013
+    - ITC-WP-0014
+
+assimilation:
+  practice: infospace/assimilation/intake-and-assimilation-practice.md
+  intake_dir: incoming/
+  records:
+    - id: assimilation/it-capability-canon
+      source: Information Technology Capability Canon (ITCC) v0.1
+      disposition: adapt
+      status: closed
+      produced: itc-cap

 first_proofs:
  near_term:
@ -146,3 +170,4 @@ next_actions:
  - implement ITC-WP-0003 validation and generated views
  - implement ITC-WP-0004 small-saas profile proof
  - explore ITC-WP-0006 PURPOSES model extension
+  - resolve ITC-WP-0014 T01 capability identifier prefix (blocks ITC-CAP promotion)
--- a/incoming/README.md
+++ b/incoming/README.md
@ -0,0 +1,24 @@
+# incoming/
+
+Drop zone for raw, un-reviewed material proposed for absorption into
+InfoTechCanon: external standards, vocabularies, product schemas, internal
+drafts, and their machine-readable companions.
+
+**Rules**
+
+- Files land here unedited and stay unedited.
+- No canon artifact may reference a path under `incoming/` — nothing here is
+  part of the canon.
+- This directory is expected to be empty after a processing session. Anything
+  left here is unprocessed backlog.
+
+**Processing**
+
+Follow `infospace/assimilation/intake-and-assimilation-practice.md`. In short:
+`git mv` the input into `infospace/assimilation/<slug>/source/` as a frozen
+snapshot, produce the assimilation workspace, record a disposition, and — if
+adopted — transform it into a canon artifact and cut a new canon version with
+notes in `CHANGELOG.md`.
+
+If an input is a *need* rather than a body of knowledge, it belongs in `demand/`
+with a workplan, not here.
--- a/infospace/agent/briefs/model-capability.md
+++ b/infospace/agent/briefs/model-capability.md
@ -0,0 +1,46 @@
+---
+id: agent-brief/model-capability
+artifact_id: model/capability
+source_path: models/capability/InfoTechCanonCapabilityModel.md
+source_kind: model
+generated: true
+---
+
+<!-- GENERATED by info_tech_canon; do not edit by hand. -->
+
+# Agent Brief: InfoTechCanon Capability Model
+
+- Artifact ID: `model/capability`
+- Kind: `model`
+- Canonical path: `models/capability/InfoTechCanonCapabilityModel.md`
+- Full source: `models/capability/InfoTechCanonCapabilityModel.md`
+- Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model.
+
+## Retrieval Hints
+
+Imports and anchors:
+- `kernel/itc-core`
+- `model/governance`
+- `model/landscape`
+- `model/observability`
+- `model/purpose-demand-extension`
+
+## Owned Concepts
+
+- `Capability`
+- `CapabilityContract`
+- `CapabilityDomain`
+- `CapabilityEvidenceHook`
+- `CapabilityInclusionRule`
+- `CapabilityMaturityLevel`
+- `CapabilityProfile`
+- `CapabilityProvider`
+- `CapabilityProvision`
+- `CapabilityQualityDimension`
+- `CapabilityRequirement`
+- `CapabilityResourceClass`
+- `InfoTechCanon Capability Model`
+
+## Related Distinctions
+
+No common distinction is anchored directly on this artifact.
--- a/infospace/agent/global-agent-brief.md
+++ b/infospace/agent/global-agent-brief.md
@ -5,8 +5,8 @@
 This brief summarizes the current canon service surface for agents.

 - Infospace slug: `canon`
- Artifact count: 61
- Retrieval index items: 61
+- Artifact count: 65
+- Retrieval index items: 65
 - Primary confidence command: `make validate`
 - Refresh generated indexes and views with: `make index`
 - Refresh agent briefs and interface templates with: `make agent-briefs`
--- a/infospace/agent/retrieval-index.json
+++ b/infospace/agent/retrieval-index.json
@ -43,8 +43,29 @@
    }
  ],
  "infospace": "canon",
-  "item_count": 61,
+  "item_count": 65,
  "items": [
+    {
+      "canonical_path": "assimilation/it-capability-canon/ASSIMILATION.md",
+      "id": "assimilation/it-capability-canon",
+      "imports": [
+        "kernel/itc-core"
+      ],
+      "kind": "assimilation",
+      "owned_concepts": [
+        "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
+      ],
+      "relationships": [
+        {
+          "target": "kernel/itc-core",
+          "type": "conforms_to"
+        }
+      ],
+      "source_path": "infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md",
+      "summary": "Canon artifact: Assimilation \u2014 IT Capability Canon (ITCC) v0.1.",
+      "title": "Assimilation \u2014 IT Capability Canon (ITCC) v0.1",
+      "warnings": []
+    },
    {
      "canonical_path": "standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml",
      "id": "benchmark/caring/kubernetes-rbac",
@ -232,6 +253,20 @@
      "title": "Kubernetes RBAC Native Concept Map",
      "warnings": []
    },
+    {
+      "canonical_path": "models/capability/capabilities.yaml",
+      "id": "capability-catalog/itc-cap",
+      "imports": [],
+      "kind": "capability-catalog",
+      "owned_concepts": [
+        "InfoTechCanon Capability Catalog"
+      ],
+      "relationships": [],
+      "source_path": "infospace/assimilation/it-capability-canon/source/capabilities.yaml",
+      "summary": "Canon artifact: InfoTechCanon Capability Catalog.",
+      "title": "InfoTechCanon Capability Catalog",
+      "warnings": []
+    },
    {
      "canonical_path": "evaluations/repo-scoping/canon-benefit-analysis.yaml",
      "id": "comparison/repo-scoping/canon-benefit-analysis",
@ -1049,6 +1084,67 @@
      "title": "InfoTechCanon Access Control Model",
      "warnings": []
    },
+    {
+      "canonical_path": "models/capability/InfoTechCanonCapabilityModel.md",
+      "id": "model/capability",
+      "imports": [
+        "kernel/itc-core",
+        "model/governance",
+        "model/landscape",
+        "model/observability",
+        "model/purpose-demand-extension"
+      ],
+      "kind": "model",
+      "owned_concepts": [
+        "Capability",
+        "CapabilityContract",
+        "CapabilityDomain",
+        "CapabilityEvidenceHook",
+        "CapabilityInclusionRule",
+        "CapabilityMaturityLevel",
+        "CapabilityProfile",
+        "CapabilityProvider",
+        "CapabilityProvision",
+        "CapabilityQualityDimension",
+        "CapabilityRequirement",
+        "CapabilityResourceClass",
+        "InfoTechCanon Capability Model"
+      ],
+      "relationships": [
+        {
+          "target": "kernel/itc-core",
+          "type": "conforms_to"
+        },
+        {
+          "target": "model/landscape",
+          "type": "uses"
+        },
+        {
+          "target": "model/governance",
+          "type": "uses"
+        },
+        {
+          "target": "model/purpose-demand-extension",
+          "type": "uses"
+        },
+        {
+          "target": "model/observability",
+          "type": "uses"
+        },
+        {
+          "target": "capability-catalog/itc-cap",
+          "type": "introduces"
+        },
+        {
+          "target": "assimilation/it-capability-canon",
+          "type": "derived_from"
+        }
+      ],
+      "source_path": "infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md",
+      "summary": "Domain model used by canon profiles and standards: InfoTechCanon Capability Model.",
+      "title": "InfoTechCanon Capability Model",
+      "warnings": []
+    },
    {
      "canonical_path": "models/data/InfoTechCanonDataModel.md",
      "id": "model/data",
@ -1363,6 +1459,27 @@
      "title": "Intent Scope Purposes Pattern",
      "warnings": []
    },
+    {
+      "canonical_path": "assimilation/intake-and-assimilation-practice.md",
+      "id": "practice/intake-and-assimilation",
+      "imports": [
+        "kernel/itc-core"
+      ],
+      "kind": "practice",
+      "owned_concepts": [
+        "Intake and Assimilation Practice"
+      ],
+      "relationships": [
+        {
+          "target": "kernel/itc-core",
+          "type": "conforms_to"
+        }
+      ],
+      "source_path": "assimilation/intake-and-assimilation-practice.md",
+      "summary": "Canon artifact: Intake and Assimilation Practice.",
+      "title": "Intake and Assimilation Practice",
+      "warnings": []
+    },
    {
      "canonical_path": "profiles/small-saas/profile.yaml",
      "id": "profile/small-saas",
--- a/infospace/agent/retrieval-index.md
+++ b/infospace/agent/retrieval-index.md
@ -4,7 +4,7 @@

 Schema: `info-tech-canon.retrieval-index.v1`
 Infospace: `canon`
-Items: **61**
+Items: **65**

 ## Common Distinctions

@ -15,6 +15,16 @@ Items: **61**

 ## Items

+### Assimilation — IT Capability Canon (ITCC) v0.1
+
+- ID: `assimilation/it-capability-canon`
+- Kind: `assimilation`
+- Canonical path: `assimilation/it-capability-canon/ASSIMILATION.md`
+- Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
+- Summary: Canon artifact: Assimilation — IT Capability Canon (ITCC) v0.1.
+- Imports and anchors: `kernel/itc-core`
+- Owned concepts: `Assimilation — IT Capability Canon (ITCC) v0.1`
+
 ### CARING Kubernetes RBAC Benchmark

 - ID: `benchmark/caring/kubernetes-rbac`
@ -65,6 +75,16 @@ Items: **61**
 - Imports and anchors: none
 - Owned concepts: `Kubernetes RBAC Native Concept Map`

+### InfoTechCanon Capability Catalog
+
+- ID: `capability-catalog/itc-cap`
+- Kind: `capability-catalog`
+- Canonical path: `models/capability/capabilities.yaml`
+- Source path: `infospace/assimilation/it-capability-canon/source/capabilities.yaml`
+- Summary: Canon artifact: InfoTechCanon Capability Catalog.
+- Imports and anchors: none
+- Owned concepts: `InfoTechCanon Capability Catalog`
+
 ### Repo Scoping Canon Benefit Analysis

 - ID: `comparison/repo-scoping/canon-benefit-analysis`
@ -275,6 +295,16 @@ Items: **61**
 - Imports and anchors: `kernel/itc-core`, `model/governance`, `model/organization`
 - Owned concepts: `InfoTechCanon Access Control Model`

+### InfoTechCanon Capability Model
+
+- ID: `model/capability`
+- Kind: `model`
+- Canonical path: `models/capability/InfoTechCanonCapabilityModel.md`
+- Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
+- Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model.
+- Imports and anchors: `kernel/itc-core`, `model/governance`, `model/landscape`, `model/observability`, `model/purpose-demand-extension`
+- Owned concepts: `Capability`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model`
+
 ### InfoTechCanon Data Model

 - ID: `model/data`
@ -395,6 +425,16 @@ Items: **61**
 - Imports and anchors: `model/governance`, `model/task`
 - Owned concepts: `Intent Scope Purposes Pattern`, `IntentScopePurposePattern`

+### Intake and Assimilation Practice
+
+- ID: `practice/intake-and-assimilation`
+- Kind: `practice`
+- Canonical path: `assimilation/intake-and-assimilation-practice.md`
+- Source path: `assimilation/intake-and-assimilation-practice.md`
+- Summary: Canon artifact: Intake and Assimilation Practice.
+- Imports and anchors: `kernel/itc-core`
+- Owned concepts: `Intake and Assimilation Practice`
+
 ### Small SaaS System Profile

 - ID: `profile/small-saas`
--- a/infospace/agent/retrieval-index.yaml
+++ b/infospace/agent/retrieval-index.yaml
@ -1,7 +1,21 @@
 schema: info-tech-canon.retrieval-index.v1
 infospace: canon
-item_count: 61
+item_count: 65
 items:
+- id: assimilation/it-capability-canon
+  kind: assimilation
+  title: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
+  canonical_path: assimilation/it-capability-canon/ASSIMILATION.md
+  source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+  summary: "Canon artifact: Assimilation \u2014 IT Capability Canon (ITCC) v0.1."
+  owned_concepts:
+  - "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
+  imports:
+  - kernel/itc-core
+  relationships:
+  - type: conforms_to
+    target: kernel/itc-core
+  warnings: []
 - id: benchmark/caring/kubernetes-rbac
  kind: benchmark-workspace
  title: CARING Kubernetes RBAC Benchmark
@ -119,6 +133,17 @@ items:
  - type: maps
    target: model/landscape
  warnings: []
+- id: capability-catalog/itc-cap
+  kind: capability-catalog
+  title: InfoTechCanon Capability Catalog
+  canonical_path: models/capability/capabilities.yaml
+  source_path: infospace/assimilation/it-capability-canon/source/capabilities.yaml
+  summary: 'Canon artifact: InfoTechCanon Capability Catalog.'
+  owned_concepts:
+  - InfoTechCanon Capability Catalog
+  imports: []
+  relationships: []
+  warnings: []
 - id: comparison/repo-scoping/canon-benefit-analysis
  kind: benefit-analysis
  title: Repo Scoping Canon Benefit Analysis
@ -639,6 +664,49 @@ items:
  - type: uses
    target: model/governance
  warnings: []
+- id: model/capability
+  kind: model
+  title: InfoTechCanon Capability Model
+  canonical_path: models/capability/InfoTechCanonCapabilityModel.md
+  source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+  summary: 'Domain model used by canon profiles and standards: InfoTechCanon Capability
+    Model.'
+  owned_concepts:
+  - Capability
+  - CapabilityContract
+  - CapabilityDomain
+  - CapabilityEvidenceHook
+  - CapabilityInclusionRule
+  - CapabilityMaturityLevel
+  - CapabilityProfile
+  - CapabilityProvider
+  - CapabilityProvision
+  - CapabilityQualityDimension
+  - CapabilityRequirement
+  - CapabilityResourceClass
+  - InfoTechCanon Capability Model
+  imports:
+  - kernel/itc-core
+  - model/governance
+  - model/landscape
+  - model/observability
+  - model/purpose-demand-extension
+  relationships:
+  - type: conforms_to
+    target: kernel/itc-core
+  - type: uses
+    target: model/landscape
+  - type: uses
+    target: model/governance
+  - type: uses
+    target: model/purpose-demand-extension
+  - type: uses
+    target: model/observability
+  - type: introduces
+    target: capability-catalog/itc-cap
+  - type: derived_from
+    target: assimilation/it-capability-canon
+  warnings: []
 - id: model/data
  kind: model
  title: InfoTechCanon Data Model
@ -858,6 +926,20 @@ items:
  - type: uses
    target: model/task
  warnings: []
+- id: practice/intake-and-assimilation
+  kind: practice
+  title: Intake and Assimilation Practice
+  canonical_path: assimilation/intake-and-assimilation-practice.md
+  source_path: assimilation/intake-and-assimilation-practice.md
+  summary: 'Canon artifact: Intake and Assimilation Practice.'
+  owned_concepts:
+  - Intake and Assimilation Practice
+  imports:
+  - kernel/itc-core
+  relationships:
+  - type: conforms_to
+    target: kernel/itc-core
+  warnings: []
 - id: profile/small-saas
  kind: profile
  title: Small SaaS System Profile
--- a/infospace/artifacts/index.yaml
+++ b/infospace/artifacts/index.yaml
@ -107,6 +107,58 @@ artifacts:
        target: model/task
      - type: introduces
        target: concept-catalog/purpose-demand
+  - id: model/capability
+    path: models/capability/InfoTechCanonCapabilityModel.md
+    kind: model
+    title: InfoTechCanon Capability Model
+    provenance:
+      source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+      placement: adapted
+      assimilation: assimilation/it-capability-canon
+      source_body: Information Technology Capability Canon (ITCC) v0.1
+    relationships:
+      - type: conforms_to
+        target: kernel/itc-core
+      - type: uses
+        target: model/landscape
+      - type: uses
+        target: model/governance
+      - type: uses
+        target: model/purpose-demand-extension
+      - type: uses
+        target: model/observability
+      - type: introduces
+        target: capability-catalog/itc-cap
+      - type: derived_from
+        target: assimilation/it-capability-canon
+  - id: capability-catalog/itc-cap
+    path: models/capability/capabilities.yaml
+    kind: capability-catalog
+    title: InfoTechCanon Capability Catalog
+    provenance:
+      source_path: infospace/assimilation/it-capability-canon/source/capabilities.yaml
+      placement: adapted
+      assimilation: assimilation/it-capability-canon
+    relationships: []
+  - id: assimilation/it-capability-canon
+    path: assimilation/it-capability-canon/ASSIMILATION.md
+    kind: assimilation
+    title: Assimilation — IT Capability Canon (ITCC) v0.1
+    provenance:
+      source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+      disposition: adapt
+    relationships:
+      - type: conforms_to
+        target: kernel/itc-core
+  - id: practice/intake-and-assimilation
+    path: assimilation/intake-and-assimilation-practice.md
+    kind: practice
+    title: Intake and Assimilation Practice
+    provenance:
+      placement: authored
+    relationships:
+      - type: conforms_to
+        target: kernel/itc-core
  - id: model/task
    path: models/task/InfoTechCanonTaskModel.md
    kind: model
--- a/infospace/assimilation/README.md
+++ b/infospace/assimilation/README.md
@ -1,3 +1,29 @@
 # Assimilation

 Assimilation records for external knowledge and consumer demand live here.
+
+The procedure that governs them — from the `incoming/` drop zone through frozen
+source snapshots, comparison, disposition, canon transformation, and the
+resulting canon version — is
+[`intake-and-assimilation-practice.md`](intake-and-assimilation-practice.md).
+
+Each assimilation is one directory:
+
+```text
+<slug>/
+  assimilation.yaml        record (schemas/assimilation.schema.yaml)
+  ASSIMILATION.md          scope, findings, decision record
+  source/                  frozen snapshot of the processed input
+  source-summary.md
+  extracted-concepts.yaml
+  comparison-matrix.md
+  mappings.yaml
+  proposed-changes.md
+  open-questions.md
+```
+
+## Records
+
+| Assimilation | Source | Disposition | Status |
+|---|---|---|---|
+| [`it-capability-canon`](it-capability-canon/) | Information Technology Capability Canon (ITCC) v0.1 | adapt | decided |
--- a/infospace/assimilation/intake-and-assimilation-practice.md
+++ b/infospace/assimilation/intake-and-assimilation-practice.md
@ -0,0 +1,207 @@
+# Intake and Assimilation Practice
+
+**Status:** Practice (normative for this repository)
+**Applies to:** every external or internally-drafted document, schema, vocabulary,
+or model proposed for absorption into InfoTechCanon
+**Anchors:** `InfoTechCanonCore` §14 (Assimilation Model), §8.13 (ChangeRecord),
+§8.14 (DecisionRecord), §27.4 (Minimal Assimilation Profile)
+
+---
+
+## 1. Why this exists
+
+New concepts and terminology arrive continuously — from consumers, from external
+standards, from Bernd's own drafts. Without a fixed pipeline they either rot in a
+drop directory or get pasted into the canon without comparison, which is the
+anti-pattern Core §29.6 names explicitly ("Assimilation by copy-paste").
+
+This practice defines the full path:
+
+```text
+incoming/                     drop zone, un-reviewed, never referenced by canon
+   │  (1) intake
+   ▼
+infospace/assimilation/<slug>/source/     processed input, frozen snapshot
+   │  (2) scope, extract, compare
+   ▼
+infospace/assimilation/<slug>/            assimilation workspace + proposals
+   │  (3) disposition decision  ← human gate
+   ▼
+infospace/{models,standards,...}/         canon change (adopt / adapt)
+   │  (4) register + regenerate + validate
+   ▼
+canon.yaml version bump + CHANGELOG.md    new canon version with change notes
+```
+
+**Governing rule (Core §14.7):** assimilation produces *proposals*, not automatic
+canon changes. Steps 1–2 may run unattended. Step 3 requires an explicit
+disposition recorded by the canon owner.
+
+---
+
+## 2. The drop zone: `incoming/`
+
+- `incoming/` holds raw, un-reviewed inputs exactly as received. Do not edit them.
+- Nothing in the canon (`canon.yaml`, `infospace/artifacts/index.yaml`, links from
+  canon documents) may reference a path under `incoming/`.
+- An input may be several files (a Markdown document plus its machine-readable
+  companion). Keep them together; they assimilate as one unit.
+- `incoming/` is expected to be **empty** after a processing session. A file
+  remaining there is an unprocessed backlog item, not a resting place.
+
+Related but distinct front doors — do not confuse them:
+
+| Directory | Holds | Next step |
+|---|---|---|
+| `incoming/` | raw candidate material to absorb | this practice |
+| `demand/` | a stated consumer need, not yet a document | workplan + design |
+| `seeds/` | historical provenance of first-generation canon files | frozen |
+
+If an input turns out to be a *need* rather than a *body of knowledge*, move it to
+`demand/` and open a workplan instead of an assimilation workspace.
+
+---
+
+## 3. Stage 1 — Intake
+
+Create the workspace and move the input into it. Use `git mv` so the provenance
+chain stays visible in history.
+
+```bash
+slug=<kebab-slug>
+mkdir -p infospace/assimilation/$slug/source
+git mv incoming/<file> infospace/assimilation/$slug/source/
+```
+
+The snapshot under `source/` is **frozen**: it is the evidence of what was
+assimilated and what version it was. Later revisions of the same external body
+arrive as a new intake with a new `source_version`, never as an edit in place.
+
+Write `infospace/assimilation/<slug>/assimilation.yaml` conforming to
+`infospace/schemas/assimilation.schema.yaml`:
+
+```yaml
+id: assimilation/<slug>
+title: <human title>
+source: <source body name and version>
+source_version: "<version>"
+source_type: external-standard | internal-draft | product-schema | ...
+source_files: [source/<file>, ...]
+requested_by: <who>
+status: intake | scoping | analysis | proposed | decided | closed
+disposition: observe | map | adopt | adapt | reject   # provisional until stage 3
+impacts: [<artifact ids the input touches>]
+```
+
+## 4. Stage 2 — Scoping, extraction, comparison
+
+Produce the Minimal Assimilation Profile (Core §27.4). One file per output so
+each can be reviewed and diffed independently:
+
+| File | Content |
+|---|---|
+| `ASSIMILATION.md` | the record: scope, stages, findings, recommendation |
+| `source-summary.md` | faithful précis of the input, no canon opinion |
+| `extracted-concepts.yaml` | every concept the input introduces, with its own terms |
+| `comparison-matrix.md` | each extracted concept classified against the canon |
+| `mappings.yaml` | concept-level mappings to existing canon owners |
+| `proposed-changes.md` | concrete, reviewable canon change proposals |
+| `open-questions.md` | unresolved issues blocking or following adoption |
+
+Classify every extracted concept with one of the Core §14.6 result categories:
+`already_covered`, `covered_differently`, `broader_than_existing`,
+`narrower_than_existing`, `missing_concept`, `conflicting_concept`,
+`implementation_detail_only`, `viewpoint_difference`,
+`terminology_difference_only`.
+
+Two canon principles decide most rows:
+
+- **Single canonical owner** (Core §6.2) — a concept has exactly one owning
+  artifact. If the input redefines something an existing model owns, that is a
+  mapping or a conflict, never a second definition.
+- **Import, do not redefine** (Core §6.3) — where the input needs a concept the
+  canon already owns, the proposal is an import, not a copy.
+
+## 5. Stage 3 — Disposition (human gate)
+
+The canon owner records one disposition for the assimilation as a whole, and, where
+they differ, per proposed change:
+
+| Disposition | Meaning | Canon effect |
+|---|---|---|
+| `observe` | recorded, no change yet | workspace only |
+| `map` | related to canon via mappings | `infospace/mappings/` entries |
+| `adopt` | taken in essentially as-is | new/extended canon artifact |
+| `adapt` | taken in, restructured to canon shape | new/extended canon artifact |
+| `reject` | out of scope or conflicting | rationale in the record |
+
+Record the decision in `ASSIMILATION.md` as a DecisionRecord (Core §8.14):
+Context, Decision, Options Considered, Rationale, Consequences, Review Trigger.
+Set `status: decided` and the final `disposition` in `assimilation.yaml`.
+
+For `adopt`/`adapt`, open a workplan (`workplans/ITC-WP-NNNN-<slug>.md`) for any
+follow-on work that is not completed in the same session — mappings to sibling
+models, profiles, schemas, consumer alignment notes.
+
+## 6. Stage 4 — Transforming into the canon
+
+When adopting or adapting, the new artifact is written in canon shape, not pasted:
+
+1. **Place** it under the correct classification — `infospace/models/<domain>/`
+   for a broad domain structure, `infospace/standards/<name>/` for a cross-cutting
+   convention or named framework, `infospace/patterns/`, `infospace/profiles/`.
+2. **Head it with canon frontmatter** — `id`, `title`, `short_name`, `type`,
+   `status`, `version`, `source_version`, `source_file`, `canonical_owner`,
+   `namespace`, `imports`, `related`, `owned_concepts`, `created_at`, `updated_at`.
+   `source_version` and `source_file` preserve the provenance chain back to the
+   frozen snapshot (see CARING for the reference example).
+3. **Separate normative prose from data.** Human-readable normative content goes
+   in the Markdown; enumerations, catalogs and baselines go in a sibling YAML that
+   is the single machine-readable source of truth. Do not maintain the same list
+   in both.
+4. **Declare owned concepts and imports** so ownership stays checkable, and add
+   the imported-from relationships rather than restating imported definitions.
+5. **Register** the artifact:
+   - `canon.yaml` — `kernel:` / `models:` / `standards:` entry with `path` and `status`
+   - `infospace/artifacts/index.yaml` — `id`, `path`, `kind`, `title`, `provenance`
+     (with `source_path` pointing at the frozen snapshot), `relationships`
+   - `infospace/infospace.yaml` — `disciplines:` entry for the primary document
+6. **Regenerate and validate**:
+   ```bash
+   make agent-briefs && make index && make tree
+   make validate && make test
+   ```
+   Generated files (agent briefs, retrieval indexes, views) carry a
+   `GENERATED` notice — never hand-edit them; fix the source and regenerate.
+
+## 7. Stage 5 — New canon version with change notes
+
+A canon change that adds, removes, or redefines canonical concepts produces a new
+canon version.
+
+- **Version field:** `canon.yaml → version`, semantic:
+  - *patch* — editorial, generated output, no concept change;
+  - *minor* — new artifact, new concepts, backward-compatible extension;
+  - *major* — a concept is removed, renamed, or its ownership moves; identifiers
+    are durable interfaces, so any break requires migration semantics.
+- **Change notes:** every version gets an entry in `CHANGELOG.md` at the repo root,
+  structured as a ChangeRecord (Core §8.13): what changed, rationale, whether it is
+  breaking, what it supersedes, and the assimilation or workplan that produced it.
+- **Artifact status:** a newly assimilated artifact enters at `proposed` or
+  `draft` status and is promoted only after practical use, even when the canon
+  version itself is released.
+- Close the loop: set the assimilation `status: closed`, add a progress event, and
+  run `statehub fix-consistency` if workplan files changed.
+
+## 8. Session checklist
+
+```text
+[ ] incoming/ is empty (every input intaken or routed to demand/)
+[ ] each input has a frozen source/ snapshot and an assimilation.yaml
+[ ] Minimal Assimilation Profile files exist and every concept is classified
+[ ] disposition recorded as a DecisionRecord
+[ ] adopted artifacts registered in canon.yaml, artifacts/index.yaml, infospace.yaml
+[ ] make agent-briefs && make index && make tree && make validate && make test pass
+[ ] canon.yaml version bumped and CHANGELOG.md entry written
+[ ] follow-on workplan opened for anything deferred
+```
--- a/infospace/assimilation/it-capability-canon/ASSIMILATION.md
+++ b/infospace/assimilation/it-capability-canon/ASSIMILATION.md
@ -0,0 +1,138 @@
+# Assimilation — Information Technology Capability Canon (ITCC) v0.1
+
+**Record:** `assimilation/it-capability-canon`
+**Source:** ITCC v0.1 (`source/ITCapabilityCanonV0.1.md`, `source/capabilities.yaml`)
+**Disposition:** `adapt`
+**Status:** decided
+**Canon version produced:** `0.2.0`
+**Date:** 2026-08-14
+**Practice:** [`../intake-and-assimilation-practice.md`](../intake-and-assimilation-practice.md)
+
+---
+
+## 1. Intake
+
+Both files arrived in `incoming/` and were moved unmodified into `source/` as the
+frozen snapshot. The source document itself (§15) asks to be reconciled with and
+incorporated into InfoTechCanon, so the request is explicit rather than inferred.
+
+## 2. Scoping
+
+**In scope:** the capability object model, inclusion rules, exclusions, the eight
+navigation domains and 41-capability baseline, capability relationship types, the
+D0–D7 maturity scale, the C/S/N/I/P resource model, evidence hooks, and the
+capability contract shape.
+
+**Out of scope:** the proposed CILM landscape model (§15) — the canon Landscape
+Model already owns that ground; and the FinOps cost formula (§13) beyond the
+resource classification itself.
+
+## 3. Concept extraction
+
+18 concepts extracted — see [`extracted-concepts.yaml`](extracted-concepts.yaml).
+
+## 4. Concept comparison
+
+See [`comparison-matrix.md`](comparison-matrix.md). Summary:
+
+- `missing_concept`: Capability, CapabilityDomain, Provision, MaturityLevel,
+  QualityDimension, EvidenceHook, CapabilityContract, ResourceClass, and the
+  capability relationship types
+- `already_covered`: Implementation, Evidence, CILM, and four of the source's
+  design principles (all four restate existing Core principles)
+- `covered_differently`: Profile (name collision with Core §8.6), Provider
+- `narrower_than_existing`: Requirement (a typed DemandSignal), quality dimensions
+- `viewpoint_difference`: the entire capability baseline against the domain models
+  — abilities versus the structures that realize them
+- `conflicting_concept`: one naming conflict only (`governance.*` prefix, OQ-2)
+
+## 5. Gap and conflict analysis
+
+**Primary gap filled.** The canon models landscape, data, security, delivery,
+network, observability, governance, organization, task, and access, but nowhere
+states *what an information system must be able to do*. The Landscape Model
+defers exactly this (§11.4). Consumers hit the gap in practice: repo-scoping
+already needs `Ability` / `Capability` / `Feature` distinctions.
+
+**No definitional conflicts.** Not one source concept redefines a concept an
+existing model owns. The relationship is anchoring, not overlap — which is why
+the disposition is `adapt` rather than `observe`.
+
+**Conflicts found:** (1) `Profile` name collision, resolved by renaming to
+`CapabilityProfile`; (2) inconsistent `governance.*` ID prefix, unresolved and
+recorded as OQ-2, blocking promotion beyond `proposed`.
+
+**Risk.** A capability catalog is the kind of artifact that quietly becomes a
+second ontology. Mitigated by PC-3: every capability must name the canon model(s)
+that own the concepts it exercises.
+
+## 6. Canon impact proposal
+
+Eight proposals — see [`proposed-changes.md`](proposed-changes.md). All eight were
+accepted; PC-6 is an accepted *rejection* (CILM not adopted). Six further items
+are deferred to `ITC-WP-0014`.
+
+## 7. Mapping and publication
+
+[`mappings.yaml`](mappings.yaml) records 26 concept-level mappings to canonical
+owners. Formal per-pair mapping artifacts under `infospace/mappings/` are deferred
+to ITC-WP-0014.
+
+Published as:
+
+- `infospace/models/capability/InfoTechCanonCapabilityModel.md`
+- `infospace/models/capability/capabilities.yaml`
+
+---
+
+## Decision Record
+
+**Context.** InfoTechCanon has no owner for abstract capability. A well-formed
+draft vocabulary (41 capabilities, machine-readable, explicitly written for
+reconciliation with InfoTechCanon) was submitted for absorption. The Landscape
+Model has deferred this ground since RC1.
+
+**Decision.** Disposition `adapt`. Adopt the vocabulary as a new domain model,
+`InfoTechCanonCapabilityModel`, restructured to canon shape: canon frontmatter and
+declared ownership, imports instead of redefinitions, per-capability anchors to
+owning models, `Profile` renamed to `CapabilityProfile`, `Provision` made
+explicit, CILM rejected. The artifact enters at status `proposed`.
+
+**Options considered.**
+
+1. *`observe`* — record and change nothing. Rejected: leaves a known gap open while
+   consumers work around it.
+2. *`map` only* — map the source to existing models without a new artifact.
+   Rejected: there is no artifact to map *to*; capability has no owner.
+3. *`adopt` as-is* — take the document in unchanged. Rejected: it carries a name
+   collision on `Profile`, a competing landscape model, an implicit provision
+   bearer, and no anchoring to canon owners.
+4. *`adapt`* — chosen.
+5. *Classify as a standard rather than a model.* Deferred as OQ-1; a capability
+   set is a broad domain structure, which is the definition of a model here.
+
+**Rationale.** The source passes its own inclusion rules and the canon's:
+implementation-independent, reusable, demandable, providable, testable,
+profileable, stable. It conflicts with nothing the canon already owns. The two
+genuinely new surfaces (`commerce.*`, `intelligence.*`) extend the canon into
+areas no existing model reaches. Adapting rather than adopting preserves single
+canonical ownership.
+
+**Consequences.**
+
+- Canon version `0.2.0`; the canon gains a twelfth model and 41 capability IDs
+  that are treated as durable interfaces from here on.
+- The Landscape Model's deferred strategy/capability concepts
+  (`BusinessCapability`, `ProductCapability`) now have a destination; the
+  Landscape §11.4 note should be revised — deferred to ITC-WP-0014.
+- Capability IDs must not be renamed without migration semantics, which makes
+  OQ-2 blocking for promotion.
+- `commerce.*` and `intelligence.*` create canon surface with no anchoring model
+  (OQ-5), an accepted weakness at `proposed` status.
+
+**Review trigger.** Promotion beyond `proposed` requires: OQ-2 resolved, the
+contract schema published, and at least one profile expressing a real capability
+requirement set with evidence.
+
+**Supersession.** None. A later ITCC revision arrives as a new intake with a new
+`source_version`, never as an edit to this frozen snapshot.
--- a/infospace/assimilation/it-capability-canon/assimilation.yaml
+++ b/infospace/assimilation/it-capability-canon/assimilation.yaml
@ -0,0 +1,44 @@
+id: assimilation/it-capability-canon
+title: Information Technology Capability Canon (ITCC) v0.1
+source: Information Technology Capability Canon (ITCC) v0.1
+source_version: "0.1"
+source_type: internal-draft
+source_files:
+  - source/ITCapabilityCanonV0.1.md
+  - source/capabilities.yaml
+reason: >
+  Standalone draft capability vocabulary written to be reconciled with and
+  incorporated into InfoTechCanon (source document section 15). Fills the
+  capability gap the Landscape Model explicitly defers (section 11.4).
+requested_by: bernd
+owner: info-tech-canon
+scope: >
+  The abstract capability vocabulary, its profile/provider/implementation/
+  resource/evidence/maturity object model, relationship types, and the 41
+  capability baseline. Excludes the source document's proposed CILM
+  landscape-state model, which the Landscape Model already owns.
+status: decided
+disposition: adapt
+impacts:
+  - model/capability
+  - model/landscape
+  - model/governance
+  - model/observability
+  - model/devsecops
+  - standard/caring
+  - kernel/itc-kernel-map
+outputs:
+  - ASSIMILATION.md
+  - source-summary.md
+  - extracted-concepts.yaml
+  - comparison-matrix.md
+  - mappings.yaml
+  - proposed-changes.md
+  - open-questions.md
+adopted_as:
+  - infospace/models/capability/InfoTechCanonCapabilityModel.md
+  - infospace/models/capability/capabilities.yaml
+follow_on_workplan: ITC-WP-0014
+canon_version: 0.2.0
+created_at: "2026-08-14"
+updated_at: "2026-08-14"
--- a/infospace/assimilation/it-capability-canon/comparison-matrix.md
+++ b/infospace/assimilation/it-capability-canon/comparison-matrix.md
@ -0,0 +1,68 @@
+# Comparison Matrix — ITCC v0.1 vs InfoTechCanon
+
+Result categories per `InfoTechCanonCore` §14.6.
+
+## 1. Object model
+
+| ITCC concept | Nearest canon owner | Category | Resolution |
+|---|---|---|---|
+| Capability | none — Landscape §11 defers it ("keep only landscape-relevant references once a dedicated strategy/capability standard exists") | `missing_concept` | New model owns `Capability` |
+| Capability Profile | Core §8.6 `Profile` | `covered_differently` | Keep both; rename to `CapabilityProfile`, state the distinction explicitly |
+| Capability Domain | Core namespaces | `missing_concept` | Adopt as navigation-only, non-semantic |
+| Requirement | `DemandSignal`, `ConsumerNeed` (Purpose and Demand extension) | `narrower_than_existing` | Adopt as `CapabilityRequirement`, defined as a typed DemandSignal carrying a minimum maturity |
+| Provider | Landscape `ServiceProvider`, `Service`, `ServiceInstance` | `covered_differently` | Import Landscape entities; `CapabilityProvider` is a *role*, not a new entity type |
+| Implementation | Landscape `Technology`, `SoftwareEntity`, `RuntimeEntity` | `already_covered` | Import; do not redefine |
+| Resource (C/S/N/I/P) | Landscape `RuntimeResource` | `broader_than_existing` | Adopt the classification as `CapabilityResourceClass` for cost attribution; the entity stays with Landscape |
+| Evidence | Governance `Evidence`; Observability signals | `already_covered` | Import; add `CapabilityEvidenceHook` as the capability-scoped expectation |
+| Maturity D0–D7 | Core status/lifecycle model; conformance levels | `missing_concept` | Adopt; explicitly *not* an artifact status and *not* a conformance level |
+| Provision | none | `missing_concept` | Make explicit — maturity attaches here, per the source's own correct/incorrect example |
+| Quality dimension | Landscape `ServiceLevelObjective`; Observability SLOs | `narrower_than_existing` | Adopt as named dimensions; measured targets stay with Observability |
+| Capability contract | Core `Standard`/schema conventions | `missing_concept` | Adopt as the machine-readable capability record |
+
+## 2. Relationships
+
+| ITCC relationship | Category | Resolution |
+|---|---|---|
+| `depends_on`, `may_use`, `composes` | `missing_concept` | Owned by the new model |
+| `requires` | `missing_concept` | Landscape entity or consumer purpose → capability |
+| `provides` | `missing_concept` | Landscape service/provider → capability |
+| `implements` | `covered_differently` | Landscape already relates technology to service; the capability-typed form is new |
+| `consumes` | `missing_concept` | Provision → resource class, for cost attribution |
+
+## 3. Capability baseline vs existing domain models
+
+The 41 capabilities are *abilities*; the existing models own the *structures* that
+realize, govern, or observe them. No capability duplicates a canon concept — but
+each anchors to an owning model, which is what makes the baseline safe to adopt.
+
+| Capability group | Anchoring canon owner | Category | Note |
+|---|---|---|---|
+| `identity.*` | Access Control, Organization, CARING | `viewpoint_difference` | Access Control owns Subject/Principal/Permission/Grant/Decision; `identity.authorization` is the *ability*, not the mechanism. `identity.organization` anchors on Organization (tenancy) — no second tenancy definition. |
+| `data.*` | Data Model | `viewpoint_difference` | Data owns Dataset/Schema/Classification/Lineage/Contract; persistence, backup, archive, search are abilities over them |
+| `integration.*` | Landscape, Network | `viewpoint_difference` | `integration.traffic` overlaps Network exposure/reachability — mapped, not redefined |
+| `runtime.*` | Landscape, DevSecOps | `viewpoint_difference` | `runtime.deployment` anchors on DevSecOps source→artifact→release→deployment flow |
+| `operations.*` | Observability, Governance | `viewpoint_difference` | `operations.audit` anchors on Governance evidence, `operations.observability` on the Observability model |
+| `security.*` | Security, Governance | `viewpoint_difference` | `security.policy` must import Governance `Policy`/`Control`; it does not define policy semantics |
+| `governance.evidence`, `governance.lifecycle` | Governance, Data | `conflicting_concept` (naming) | IDs sit in the *Security & Governance* navigation domain while using a `governance.` prefix — see `open-questions.md` OQ-2 |
+| `commerce.*` | none | `missing_concept` | Genuinely new canon surface; no existing model covers metering, billing, payment, entitlement |
+| `intelligence.*` | none | `missing_concept` | Genuinely new canon surface; Information Space covers retrieval of markdown knowledge, not metered cognitive processing |
+
+## 4. Structural claims
+
+| Claim | Category | Note |
+|---|---|---|
+| "The model is a graph, domains are navigation only" | `terminology_difference_only` | Core §6.4 *Network Before Tree* already says this |
+| "Import; do not duplicate" (§15) | `already_covered` | Core §6.3 *Import, Do Not Redefine* |
+| Prefer profiles over new capabilities (§8) | `already_covered` | Core §6.5 *Profiles, Not Forks* |
+| Evidence over assertion (§19) | `already_covered` | Core §6.9 *Evidence and Provenance Matter* |
+| CILM as a proposed sibling model (§15) | `already_covered` | The Landscape Model already owns landscape entities — **rejected as a new model** |
+| Intended / declared / applied / observed / assessed state (§15) | `broader_than_existing` | Not currently a canon-wide qualifier set — carried to OQ-3, not adopted here |
+
+## 5. Verdict
+
+- No conflicting definition of an existing canonical concept was found.
+- Two capability groups (`commerce.*`, `intelligence.*`) are canon-new surface.
+- One naming conflict (`governance.*` prefix) and one structural proposal (CILM)
+  require resolution or rejection before promotion beyond `proposed`.
+- The dominant relationship to existing models is **anchoring**, not overlap,
+  which supports disposition `adapt` rather than `observe` or `reject`.
--- a/infospace/assimilation/it-capability-canon/extracted-concepts.yaml
+++ b/infospace/assimilation/it-capability-canon/extracted-concepts.yaml
@ -0,0 +1,107 @@
+assimilation: assimilation/it-capability-canon
+source: ITCC v0.1
+note: >
+  Concepts as the source names them, before canon comparison. Classification
+  against the canon lives in comparison-matrix.md; the canonical names chosen on
+  adoption are recorded in the canon_name field.
+
+concepts:
+  - source_name: Capability
+    definition: Abstract, implementation-independent ability an information system may require or provide.
+    canon_name: Capability
+    category: missing_concept
+
+  - source_name: Capability Profile
+    definition: Constrained specialization of a capability that does not change its identity.
+    canon_name: CapabilityProfile
+    category: covered_differently
+    note: Distinct from a canon Profile (Core §8.6), which constrains canon artifacts for an implementation context.
+
+  - source_name: Capability Domain
+    definition: Navigation grouping of capabilities; not a semantic container.
+    canon_name: CapabilityDomain
+    category: missing_concept
+
+  - source_name: Requirement
+    definition: A statement that a system needs a capability at a minimum maturity.
+    canon_name: CapabilityRequirement
+    category: narrower_than_existing
+    note: A typed, maturity-bearing form of DemandSignal / ConsumerNeed from the Purpose and Demand extension.
+
+  - source_name: Provider
+    definition: Operational entity that provides a capability in a particular context.
+    canon_name: CapabilityProvider
+    category: covered_differently
+    note: Landscape owns ServiceProvider / Service / ServiceInstance; provider here is a role played by a landscape entity.
+
+  - source_name: Implementation
+    definition: Concrete technology, product, configuration, or composition used by a provider.
+    canon_name: (imported)
+    category: already_covered
+    note: Landscape owns Technology / SoftwareEntity / RuntimeEntity.
+
+  - source_name: Resource
+    definition: Economic resource consumed while providing a capability (C, S, N, I, P).
+    canon_name: CapabilityResourceClass
+    category: missing_concept
+    note: Landscape owns RuntimeResource as an entity; the C/S/N/I/P classification for cost attribution is new.
+
+  - source_name: Evidence
+    definition: Information supporting a capability or maturity claim.
+    canon_name: (imported)
+    category: already_covered
+    note: Governance owns Evidence; Observability owns telemetry evidence.
+
+  - source_name: Evidence Hook
+    definition: Named evidence type expected for a specific capability.
+    canon_name: CapabilityEvidenceHook
+    category: missing_concept
+
+  - source_name: Maturity
+    definition: Quality and operational standing of a capability as provided in a specific context.
+    canon_name: CapabilityMaturityLevel
+    category: missing_concept
+
+  - source_name: Provision
+    definition: The relationship binding provider, capability, context, and maturity.
+    canon_name: CapabilityProvision
+    category: missing_concept
+    note: Implicit in the source; made explicit on adoption because maturity attaches here and nowhere else.
+
+  - source_name: Quality Dimension
+    definition: Named quality attribute relevant to a capability (rpo, latency, assurance, ...).
+    canon_name: CapabilityQualityDimension
+    category: missing_concept
+
+  - source_name: Capability Contract
+    definition: Minimal machine-readable definition of a capability (id, purpose, profiles, qualities, relationships, evidence).
+    canon_name: CapabilityContract
+    category: missing_concept
+
+  - source_name: Canon Graph
+    definition: Capability relationships form a graph traversable from product need to technology and cost.
+    canon_name: (structural)
+    category: viewpoint_difference
+    note: Core §6.4 "Network Before Tree" already states this stance canon-wide.
+
+  - source_name: depends_on / may_use / composes
+    definition: Capability-to-capability relationship types.
+    canon_name: depends_on / may_use / composes
+    category: missing_concept
+
+  - source_name: requires / provides / implements / consumes
+    definition: Landscape-entity-to-capability relationship types.
+    canon_name: requires / provides / implements / consumes
+    category: missing_concept
+
+  - source_name: Canon inclusion rules
+    definition: Seven tests a concept must pass to enter the capability set.
+    canon_name: CapabilityInclusionRule
+    category: narrower_than_existing
+    note: Core §14 governs canon change generally; these are capability-specific admission tests.
+
+  - source_name: CILM (Canonical IT Landscape Model)
+    definition: Proposed sibling model owning landscape entities and intended/declared/applied/observed/assessed state.
+    canon_name: (rejected)
+    category: already_covered
+    note: InfoTechCanonLandscapeModel owns this. Only the state-qualifier idea is carried forward as an open question.
--- a/infospace/assimilation/it-capability-canon/mappings.yaml
+++ b/infospace/assimilation/it-capability-canon/mappings.yaml
@ -0,0 +1,181 @@
+assimilation: assimilation/it-capability-canon
+source: ITCC v0.1
+target_canon_version: "0.2.0"
+note: >
+  Concept-level mappings from the source vocabulary to canonical owners.
+  mapping_type follows the canon mapping vocabulary: equivalent, narrower,
+  broader, related, imports, superseded_by, no_mapping.
+
+mappings:
+  - source_concept: Implementation
+    target_concept: Technology / SoftwareEntity / RuntimeEntity
+    target_owner: model/landscape
+    mapping_type: imports
+    rationale: Landscape is the canonical owner of concrete landscape entities.
+    confidence: high
+
+  - source_concept: Provider
+    target_concept: Service / ServiceProvider / ServiceInstance
+    target_owner: model/landscape
+    mapping_type: related
+    rationale: CapabilityProvider is a role played by a landscape entity, not a new entity type.
+    confidence: high
+
+  - source_concept: Resource
+    target_concept: RuntimeResource
+    target_owner: model/landscape
+    mapping_type: broader
+    rationale: C/S/N/I/P are cost-attribution classes over runtime resources, including non-runtime metered intelligence.
+    confidence: medium
+
+  - source_concept: Evidence
+    target_concept: Evidence
+    target_owner: model/governance
+    mapping_type: imports
+    rationale: Governance owns evidence semantics; capability evidence hooks name expected evidence types.
+    confidence: high
+
+  - source_concept: Evidence (telemetry-derived)
+    target_concept: TelemetrySignal / Metric / SLO
+    target_owner: model/observability
+    mapping_type: related
+    rationale: Measured maturity evidence (availability, latency, RPO/RTO) is produced by observability.
+    confidence: high
+
+  - source_concept: Requirement
+    target_concept: DemandSignal / ConsumerNeed
+    target_owner: model/purpose-demand-extension
+    mapping_type: narrower
+    rationale: A capability requirement is a typed demand signal carrying a minimum maturity.
+    confidence: high
+
+  - source_concept: Quality dimension
+    target_concept: ServiceLevelObjective
+    target_owner: model/landscape
+    mapping_type: related
+    rationale: Dimensions are named; targets and measurement remain with SLOs and observability.
+    confidence: medium
+
+  - source_concept: identity.authentication
+    target_concept: Principal / AuthenticationEvent
+    target_owner: model/access-control
+    mapping_type: related
+    rationale: The capability is the ability; Access Control owns the mechanism semantics.
+    confidence: high
+
+  - source_concept: identity.authorization
+    target_concept: AuthorizationDecision / Permission / Grant
+    target_owner: model/access-control
+    mapping_type: related
+    rationale: Same ability/mechanism split; CARING adds access-governance analysis over it.
+    confidence: high
+
+  - source_concept: identity.organization
+    target_concept: Organization / Team / Tenant
+    target_owner: model/organization
+    mapping_type: related
+    rationale: Tenancy structure stays with Organization; the capability is the ability to scope by it.
+    confidence: high
+
+  - source_concept: security.policy
+    target_concept: Policy / Rule / Control
+    target_owner: model/governance
+    mapping_type: imports
+    rationale: Policy semantics are owned by Governance and must not be redefined per capability.
+    confidence: high
+
+  - source_concept: security.secrets / security.keys / security.vulnerability
+    target_concept: Secret / Key / Vulnerability / Finding
+    target_owner: model/security
+    mapping_type: related
+    confidence: high
+
+  - source_concept: governance.evidence
+    target_concept: Evidence / Assurance / Control
+    target_owner: model/governance
+    mapping_type: related
+    confidence: high
+
+  - source_concept: governance.lifecycle
+    target_concept: Retention / Classification / DataContract
+    target_owner: model/data
+    mapping_type: related
+    confidence: medium
+
+  - source_concept: data.* (transactional, object, cache, backup, archive, search)
+    target_concept: Dataset / DataStore / Schema / Lineage / Retention
+    target_owner: model/data
+    mapping_type: related
+    rationale: Data owns the assets; capabilities are the abilities exercised over them.
+    confidence: high
+
+  - source_concept: integration.traffic
+    target_concept: Routing / Exposure / Reachability / NetworkPolicy
+    target_owner: model/network
+    mapping_type: related
+    confidence: high
+
+  - source_concept: integration.api / integration.messaging / integration.exchange
+    target_concept: Endpoint / Interface / Flow
+    target_owner: model/landscape
+    mapping_type: related
+    confidence: medium
+
+  - source_concept: runtime.deployment
+    target_concept: Release / Deployment / Artifact
+    target_owner: model/devsecops
+    mapping_type: related
+    confidence: high
+
+  - source_concept: runtime.execution / runtime.configuration / runtime.scheduling
+    target_concept: RuntimeEntity / RuntimeResource / Configuration
+    target_owner: model/landscape
+    mapping_type: related
+    confidence: medium
+
+  - source_concept: runtime.workflow
+    target_concept: Task / Action / Dependency
+    target_owner: model/task
+    mapping_type: related
+    rationale: Task owns work-item semantics; workflow orchestration is the ability to run them.
+    confidence: medium
+
+  - source_concept: operations.observability / operations.alerting
+    target_concept: Telemetry / Alert / Health / SLO
+    target_owner: model/observability
+    mapping_type: related
+    confidence: high
+
+  - source_concept: operations.audit
+    target_concept: Evidence / AuditRecord
+    target_owner: model/governance
+    mapping_type: related
+    confidence: high
+
+  - source_concept: operations.recovery / operations.continuity
+    target_concept: Incident / ServiceLevelObjective
+    target_owner: model/security
+    mapping_type: related
+    confidence: low
+    note: Continuity has no strong canon owner today — see open question OQ-4.
+
+  - source_concept: commerce.*
+    target_concept: (none)
+    target_owner: model/capability
+    mapping_type: no_mapping
+    rationale: New canon surface; no existing model covers metering, billing, payment, or entitlement.
+    confidence: high
+
+  - source_concept: intelligence.*
+    target_concept: (none)
+    target_owner: model/capability
+    mapping_type: no_mapping
+    rationale: New canon surface. Information Space covers markdown knowledge packaging and retrieval, not metered cognitive processing.
+    confidence: high
+
+  - source_concept: CILM (Canonical IT Landscape Model)
+    target_concept: InfoTechCanonLandscapeModel
+    target_owner: model/landscape
+    mapping_type: superseded_by
+    rationale: The proposed sibling model is already the canon Landscape Model. Not adopted as a separate artifact.
+    confidence: high
--- a/infospace/assimilation/it-capability-canon/open-questions.md
+++ b/infospace/assimilation/it-capability-canon/open-questions.md
@ -0,0 +1,56 @@
+# Open Questions — ITCC v0.1 assimilation
+
+## OQ-1 — Is the capability set a model or a standard?
+
+Resolved for now as a **model** (broad domain structure). If capability contracts
+later grow enforcement rules and conformance levels for consumers, part of it may
+split into a standard. **Review trigger:** first consumer conformance request.
+
+## OQ-2 — The `governance.*` prefix inside the Security & Governance domain
+
+Six capabilities sit in navigation domain `security` but two use a `governance.`
+ID prefix (`governance.evidence`, `governance.lifecycle`). Options:
+
+1. keep as-is — IDs are durable interfaces and already drafted;
+2. renumber to `security.*` — consistent prefixes, but breaks IDs;
+3. split the navigation domain into `security` and `governance`.
+
+Capability IDs are durable interfaces, so this must be settled **before**
+promotion beyond `proposed`. Preference: option 3 — it preserves every ID and
+removes the inconsistency. **Owner:** canon owner. **Blocks:** promotion to
+`draft`/`release-candidate`.
+
+## OQ-3 — Should the intended/declared/applied/observed/assessed state qualifier be canon-wide?
+
+The source proposes it for maturity claims (a provider may claim D5 while an
+assessment concludes D4). The same distinction would be useful for controls,
+access maps, and network policy. Adopting it inside the capability model alone
+would create a local dialect. **Deferred:** raise as kernel-level (Core) pressure,
+not a capability-model decision.
+
+## OQ-4 — Who owns continuity and service recovery?
+
+`operations.recovery` and `operations.continuity` have no strong canon owner:
+Security owns incidents, Observability owns health, Data owns backup assets, but
+business continuity and recovery objectives sit between them. Mapping confidence
+is `low`. **Candidate:** a Governance or Landscape extension.
+
+## OQ-5 — Do `commerce.*` and `intelligence.*` need their own domain models?
+
+Both are canon-new surface with no anchoring model. Today they are capability IDs
+with no owner behind them, which is acceptable for a capability catalog but weak
+if consumers start requiring structural semantics (invoices, entitlements,
+prompts, evaluations). **Review trigger:** the first consumer demand that needs
+structure rather than ability.
+
+## OQ-6 — How are capability requirements validated against provisions?
+
+The source sketches a validator (§18) comparing product requirements to provider
+maturity. That belongs to the service surface (`ITC-WP-0002`) and needs the
+contract schema first. **Deferred:** ITC-WP-0014.
+
+## OQ-7 — Relationship between `CapabilityProfile` and canon `Profile`
+
+Named and distinguished, but not yet formally related. A canon `Profile` (e.g.
+small-saas) will plausibly *select* capability profiles. **Deferred:** ITC-WP-0014
+alongside the small-SaaS requirement set.
--- a/infospace/assimilation/it-capability-canon/proposed-changes.md
+++ b/infospace/assimilation/it-capability-canon/proposed-changes.md
@ -0,0 +1,125 @@
+# Proposed Changes — ITCC v0.1
+
+Each proposal is a reviewable canon change. Status reflects what was applied in
+canon version `0.2.0`.
+
+---
+
+## PC-1 — Add a Capability Model to `models/`
+
+**Change:** create `InfoTechCanonCapabilityModel` (`ITC-CAP`, namespace `itc-cap`)
+at `infospace/models/capability/`, owning the capability object model, the
+maturity scale, the resource classes, and the capability relationship types.
+
+**Rationale:** the canon has no owner for *abstract ability*. The Landscape Model
+(§11.4) explicitly defers it: "The Landscape Model should keep only
+landscape-relevant references once a dedicated strategy/capability standard
+exists." This is that standard.
+
+**Classification:** model, not standard — it defines a broad domain structure
+(abilities and their provision), not a cross-cutting convention.
+
+**Breaking:** no. **Status:** applied, artifact status `proposed`.
+
+---
+
+## PC-2 — Adopt the 41-capability baseline as machine-readable data
+
+**Change:** `infospace/models/capability/capabilities.yaml` holds the canonical
+baseline — domains, capability contracts, profiles, quality dimensions, evidence
+hooks, relationships, maturity levels, resource classes. The Markdown carries
+normative prose and an ID index only; the list is not duplicated in both places.
+
+**Rationale:** capability IDs are durable interfaces and the primary consumer is
+tooling. Prose and data must not drift apart.
+
+**Breaking:** no. **Status:** applied.
+
+---
+
+## PC-3 — Anchor every capability to an owning canon model
+
+**Change:** each capability entry carries an `anchors` field naming the canon
+model(s) that own the concepts it exercises (e.g. `identity.authorization` →
+`model/access-control`; `runtime.deployment` → `model/devsecops`).
+
+**Rationale:** enforces Core §6.2 (single canonical owner) and §6.3 (import, do
+not redefine) mechanically. Without anchors, a capability catalog quietly grows
+into a second, competing ontology.
+
+**Breaking:** no. **Status:** applied.
+
+---
+
+## PC-4 — Make Provision explicit; forbid maturity on the abstract capability
+
+**Change:** introduce `CapabilityProvision` as the binding of provider ×
+capability × context, and state normatively that maturity attaches to a provision
+and never to a `Capability`.
+
+**Rationale:** the source states the rule correctly (§3.8) but leaves the bearer
+implicit, which is what lets `capability: X, maturity: D5` get written by mistake.
+
+**Breaking:** no. **Status:** applied.
+
+---
+
+## PC-5 — Rename Profile → CapabilityProfile
+
+**Change:** the source's "Profile" becomes `CapabilityProfile`; the model states
+its distinction from the canon `Profile` (Core §8.6).
+
+**Rationale:** Core §8.6 already owns `Profile` as an artifact type constraining
+models for an implementation context. Two meanings of one word inside one canon
+is a defect, not a nuance.
+
+**Breaking:** no (source was never canon). **Status:** applied.
+
+---
+
+## PC-6 — Reject CILM as a separate model
+
+**Change:** the source's proposed Canonical IT Landscape Model is not adopted.
+The Landscape Model already owns landscape entities and relationships. The
+capability model *imports* Landscape rather than proposing a sibling.
+
+**Rationale:** Core §6.2. Adopting CILM would create a second landscape owner.
+
+**Breaking:** no. **Status:** applied (rejection recorded).
+
+---
+
+## PC-7 — Requirement expressed through Purpose and Demand
+
+**Change:** `CapabilityRequirement` is defined as a typed `DemandSignal` carrying
+a minimum maturity, importing the Purpose and Demand extension rather than
+inventing a parallel requirement vocabulary.
+
+**Rationale:** the canon already models consumer demand; capability requirements
+are a maturity-bearing specialization of it.
+
+**Breaking:** no. **Status:** applied.
+
+---
+
+## PC-8 — Register in kernel map, canon.yaml, artifact index, infospace disciplines
+
+**Change:** register `model/capability` across `canon.yaml`,
+`infospace/artifacts/index.yaml`, `infospace/infospace.yaml`; regenerate agent
+briefs, retrieval indexes, and views.
+
+**Breaking:** no. **Status:** applied. Kernel-map prose update is deferred to
+ITC-WP-0014 T01 (the map is a seed document with its own revision cycle).
+
+---
+
+## Deferred to ITC-WP-0014
+
+| Item | Reason |
+|---|---|
+| Formal mapping artifacts under `infospace/mappings/` for each anchor | Needs the mapping schema applied per concept pair, not just the assimilation-level mappings recorded here |
+| `capability.schema.yaml` under `infospace/schemas/` | Contract shape should stabilize against one real profile first |
+| Small-SaaS profile capability requirement set | Profile proof work belongs with ITC-WP-0004 |
+| Resolution of the `governance.*` prefix (OQ-2) | Requires an ID-stability decision before promotion |
+| CARING import of `identity.*` capability ids | Touches a release-candidate standard; needs its own review |
+| Kernel map revision | Seed document revision cycle |
--- a/infospace/assimilation/it-capability-canon/source-summary.md
+++ b/infospace/assimilation/it-capability-canon/source-summary.md
@ -0,0 +1,99 @@
+# Source Summary — ITCC v0.1
+
+Faithful précis of `source/ITCapabilityCanonV0.1.md` and `source/capabilities.yaml`.
+No canon judgement here; comparison lives in `comparison-matrix.md`.
+
+## Identity
+
+- **Name:** Information Technology Capability Canon
+- **Short name:** ITCC
+- **Version:** 0.1, status *draft baseline*
+- **Companion data:** `capabilities.yaml` — declared by the document (§17) as the
+  initial machine-readable representation
+
+## Stated purpose
+
+Define **what an information system must be able to do**, independently of how it
+is implemented, positioned deliberately between product and technology:
+
+```text
+Business / Product → requires → Capability → provided by → Service
+  → implemented by → Technology → consumes → Resources → Cost
+```
+
+The document states (§15) that ITCC is intended to become a capability-oriented
+component of the wider InfoTechCanon, governed by "import; do not duplicate".
+
+## Object model (§3)
+
+| Object | Meaning |
+|---|---|
+| Capability | Abstract, implementation-independent ability that may be required or provided |
+| Profile | Constrained specialization of a capability, preferred over new capabilities |
+| Requirement | A system's statement that it needs a capability at a minimum maturity |
+| Provider | Operational entity providing a capability in a context |
+| Implementation | Concrete technology/product/configuration used by a provider |
+| Resource | Economic resource consumed while providing: C, S, N, I, P |
+| Evidence | Information supporting a capability or maturity claim |
+| Maturity | Quality/operational standing **of a provision**, never of the abstract capability |
+
+## Inclusion rules (§4)
+
+A concept enters the canon only if it is implementation-independent, reusable,
+demandable, providable, testable, profileable, and stable.
+
+## Exclusions (§5)
+
+Technologies (PostgreSQL, Keycloak, Stripe), protocols and standards (REST,
+OIDC, OpenTelemetry), product features (password reset screen), and
+domain-specific business capabilities (hospital admission, insurance
+underwriting).
+
+## Structure (§6, §7)
+
+Eight navigation domains over 41 capabilities; the underlying model is asserted
+to be a **graph**, not a tree:
+
+| Domain | Capabilities |
+|---|---|
+| Identity & Access | lifecycle, authentication, authorization, federation, organization |
+| Data & State | transactional, object, cache, backup, archive, search |
+| Integration & Communication | api, messaging, exchange, notification, traffic |
+| Runtime & Automation | execution, configuration, scheduling, workflow, deployment |
+| Operations & Assurance | observability, alerting, audit, recovery, continuity |
+| Security & Governance | secrets, keys, policy, vulnerability, governance.evidence, governance.lifecycle |
+| Commerce | metering, billing, payment, entitlement |
+| Intelligence | generation, extraction, embedding, retrieval, reasoning |
+
+Each capability carries `id`, `name`, `purpose`, `profiles`, `qualities`,
+`evidence`, and optional `depends_on` / `may_use`.
+
+## Relationship types (§9)
+
+`depends_on`, `may_use`, `composes` (capability-to-capability);
+`requires`, `provides`, `implements`, `consumes` (landscape-to-capability).
+
+## Maturity scale (§10, §11)
+
+`D0` Absent · `D1` Experimental · `D2` Available · `D3` Usable · `D4` Production ·
+`D5` Reliable · `D6` Scalable · `D7` Strategic. Claims are per provision and per
+environment; the same provider may hold different levels in dev/staging/prod.
+
+## Resource and cost model (§13)
+
+`C` Compute · `S` Storage · `N` Networking · `I` Intelligence · `P` Platform.
+Cost attaches to provisions and implementations, not to abstract capabilities,
+enabling capability-oriented FinOps questions.
+
+## Evolution stance (§16, §19)
+
+Conservative: prefer profiles over new capabilities, treat capability IDs as
+durable interfaces, require explicit migration semantics for rename/removal,
+introduce provisionally and promote only after repeated practical use. v0.1
+explicitly does not aim at completeness.
+
+## Proposed ownership split (§15)
+
+ITCC owns *what abstract abilities exist*; a "CILM" landscape model owns *what
+entities exist and what state they are in*; CARING keeps specialized
+access-governance semantics and may import ITCC concepts.
--- a/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+++ b/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
--- a/infospace/assimilation/it-capability-canon/source/capabilities.yaml
+++ b/infospace/assimilation/it-capability-canon/source/capabilities.yaml
@ -0,0 +1,787 @@
+canon:
+  id: itcc
+  name: Information Technology Capability Canon
+  short_name: ITCC
+  version: '0.1'
+  status: draft
+  purpose: Implementation-independent canonical vocabulary for common information-technology capabilities.
+resources:
+- id: C
+  name: Compute
+  description: Generic execution capacity.
+- id: S
+  name: Storage
+  description: Persistence capacity.
+- id: N
+  name: Networking
+  description: Information movement.
+- id: I
+  name: Intelligence
+  description: Metered or purchased cognitive or semantic processing capability.
+- id: P
+  name: Platform
+  description: Enabling operational overhead that makes other resources usable.
+maturity_model:
+- id: D0
+  name: Absent
+  description: Capability is not provided.
+- id: D1
+  name: Experimental
+  description: Proof of concept or exploratory implementation.
+- id: D2
+  name: Available
+  description: A provider exists and can be consumed.
+- id: D3
+  name: Usable
+  description: Documented and practically consumable.
+- id: D4
+  name: Production
+  description: Approved for production dependency.
+- id: D5
+  name: Reliable
+  description: Reliability is measured and actively controlled.
+- id: D6
+  name: Scalable
+  description: Capacity and operational scaling are demonstrated.
+- id: D7
+  name: Strategic
+  description: Governed, reusable, and deliberately evolved as a platform capability.
+relationship_types:
+- id: depends_on
+  description: Capability normally requires another capability to operate.
+- id: may_use
+  description: Capability may use another capability without conceptual dependency.
+- id: composes
+  description: A higher-level capability or pattern is composed from lower-level capabilities.
+- id: requires
+  description: A landscape entity requires a capability.
+- id: provides
+  description: A provider supplies a capability.
+- id: implements
+  description: A technology or implementation realizes a provider or capability provision.
+- id: consumes
+  description: A provider or implementation consumes economic resources.
+domains:
+- id: identity
+  name: Identity & Access
+  capabilities:
+  - id: identity.lifecycle
+    name: Identity Lifecycle
+    purpose: Create, maintain, suspend, recover, and remove identities over time.
+    profiles:
+    - human
+    - machine
+    - external
+    - privileged
+    qualities:
+    - provisioning_latency
+    - deprovisioning_latency
+    - recovery
+    - ownership
+    evidence:
+    - successful_provisioning
+    - successful_deprovisioning
+    - ownership_record
+  - id: identity.authentication
+    name: Authentication
+    purpose: Establish that an actor controls or legitimately represents an identity.
+    profiles:
+    - human
+    - machine
+    - password
+    - passkey
+    - mfa
+    - passwordless
+    - high-assurance
+    qualities:
+    - assurance
+    - availability
+    - latency
+    - factor_support
+    evidence:
+    - successful_authentication
+    - failure_metrics
+    - availability_metrics
+  - id: identity.authorization
+    name: Authorization
+    purpose: Determine whether an actor may perform an action on a resource.
+    profiles:
+    - rbac
+    - abac
+    - relationship-based
+    - policy-based
+    qualities:
+    - decision_latency
+    - policy_coverage
+    - explainability
+    evidence:
+    - policy_tests
+    - authorization_decisions
+    - denial_evidence
+  - id: identity.federation
+    name: Identity Federation
+    purpose: Establish and use trust relationships between identity domains.
+    profiles:
+    - workforce
+    - customer
+    - partner
+    - machine
+    qualities:
+    - trust_scope
+    - protocol_support
+    - availability
+    evidence:
+    - federation_configuration
+    - successful_federated_login
+  - id: identity.organization
+    name: Organization & Tenancy
+    purpose: Associate identities, resources, policies, and operations with organizational or tenant boundaries.
+    profiles:
+    - organization
+    - team
+    - tenant
+    - hierarchy
+    - delegation
+    qualities:
+    - isolation
+    - delegation
+    - hierarchy_depth
+    evidence:
+    - tenant_isolation_tests
+    - membership_records
+- id: data
+  name: Data & State
+  capabilities:
+  - id: data.transactional
+    name: Transactional Persistence
+    purpose: Persist structured mutable state with defined consistency and transaction semantics.
+    profiles:
+    - relational
+    - document
+    - key-value
+    qualities:
+    - consistency
+    - durability
+    - availability
+    - latency
+    - throughput
+    evidence:
+    - durability_tests
+    - availability_metrics
+  - id: data.object
+    name: Object Persistence
+    purpose: Persist opaque objects, files, blobs, documents, or similar binary or semi-structured objects.
+    profiles:
+    - blob
+    - document
+    - artifact
+    qualities:
+    - durability
+    - availability
+    - retention
+    - size_limits
+    evidence:
+    - object_integrity_tests
+    - availability_metrics
+  - id: data.cache
+    name: Caching
+    purpose: Maintain temporary or derived state for accelerated access.
+    profiles:
+    - local
+    - distributed
+    - content
+    qualities:
+    - hit_rate
+    - latency
+    - eviction_policy
+    - freshness
+    evidence:
+    - cache_metrics
+    - latency_metrics
+  - id: data.backup
+    name: Backup & Restore
+    purpose: Create recoverable copies or recovery points and restore previously valid persisted state after loss,
+      corruption, or erroneous modification.
+    profiles:
+    - database
+    - object
+    - volume
+    qualities:
+    - rpo
+    - rto
+    - retention
+    - isolation
+    - geographical_separation
+    - restore_validation
+    depends_on:
+    - data.object
+    may_use:
+    - runtime.scheduling
+    - operations.observability
+    evidence:
+    - successful_backup
+    - successful_restore_test
+    - measured_rpo
+    - measured_rto
+  - id: data.archive
+    name: Archive & Retention
+    purpose: Preserve information for long-term retention under defined lifecycle, integrity, and retrieval rules.
+    profiles:
+    - regulatory
+    - operational
+    - cold
+    qualities:
+    - retention
+    - immutability
+    - retrievability
+    - integrity
+    evidence:
+    - retention_policy
+    - integrity_verification
+    - retrieval_test
+  - id: data.search
+    name: Search & Retrieval
+    purpose: Locate persisted information based on indexed or queryable characteristics.
+    profiles:
+    - lexical
+    - structured
+    - faceted
+    - semantic
+    - hybrid
+    qualities:
+    - latency
+    - recall
+    - precision
+    - freshness
+    evidence:
+    - search_tests
+    - latency_metrics
+- id: integration
+  name: Integration & Communication
+  capabilities:
+  - id: integration.api
+    name: API Exposure
+    purpose: Expose machine-consumable interfaces through which systems can invoke or retrieve functionality.
+    profiles:
+    - request-response
+    - streaming
+    - public
+    - internal
+    qualities:
+    - availability
+    - latency
+    - compatibility
+    - rate_limits
+    evidence:
+    - contract_tests
+    - availability_metrics
+  - id: integration.messaging
+    name: Messaging & Eventing
+    purpose: Exchange asynchronous messages or events between producers and consumers.
+    profiles:
+    - queue
+    - pub-sub
+    - event-stream
+    - event-bus
+    qualities:
+    - delivery_semantics
+    - ordering
+    - durability
+    - latency
+    - throughput
+    evidence:
+    - delivery_tests
+    - lag_metrics
+  - id: integration.exchange
+    name: Data Exchange
+    purpose: Move datasets, files, or structured information between systems.
+    profiles:
+    - batch
+    - file
+    - stream
+    - managed-transfer
+    qualities:
+    - integrity
+    - latency
+    - throughput
+    - retries
+    evidence:
+    - transfer_tests
+    - integrity_checks
+  - id: integration.notification
+    name: Notification
+    purpose: Deliver information to human users or external endpoints.
+    profiles:
+    - email
+    - sms
+    - push
+    - chat
+    - webhook
+    - physical-mail
+    qualities:
+    - delivery_rate
+    - latency
+    - channel_support
+    - tracking
+    evidence:
+    - delivery_receipts
+    - failure_metrics
+  - id: integration.traffic
+    name: Traffic Management
+    purpose: Route, balance, control, filter, or shape communication between endpoints.
+    profiles:
+    - load-balancing
+    - ingress
+    - service-routing
+    - rate-limiting
+    - api-gateway
+    qualities:
+    - availability
+    - latency
+    - routing_correctness
+    - capacity
+    evidence:
+    - routing_tests
+    - availability_metrics
+- id: runtime
+  name: Runtime & Automation
+  capabilities:
+  - id: runtime.execution
+    name: Workload Execution
+    purpose: Execute software workloads with defined runtime resources and isolation.
+    profiles:
+    - process
+    - container
+    - virtual-machine
+    - function
+    - batch
+    qualities:
+    - availability
+    - isolation
+    - startup_time
+    - capacity
+    evidence:
+    - execution_tests
+    - capacity_metrics
+  - id: runtime.configuration
+    name: Configuration
+    purpose: Supply controlled runtime configuration to software and services.
+    profiles:
+    - static
+    - dynamic
+    - environment
+    - feature
+    qualities:
+    - versioning
+    - propagation_latency
+    - consistency
+    - auditability
+    evidence:
+    - configuration_history
+    - propagation_tests
+  - id: runtime.scheduling
+    name: Scheduling
+    purpose: Initiate activities according to time, delay, calendar, or recurrence.
+    profiles:
+    - cron
+    - calendar
+    - delay
+    - recurring
+    qualities:
+    - timing_accuracy
+    - delivery_guarantee
+    - timezone_support
+    evidence:
+    - schedule_execution_records
+  - id: runtime.workflow
+    name: Workflow Orchestration
+    purpose: Coordinate multi-step activities, state transitions, dependencies, retries, and completion.
+    profiles:
+    - durable
+    - human-in-the-loop
+    - saga
+    - agentic
+    qualities:
+    - durability
+    - retry_semantics
+    - visibility
+    - recovery
+    may_use:
+    - integration.messaging
+    - runtime.scheduling
+    - integration.notification
+    evidence:
+    - workflow_completion_records
+    - recovery_tests
+  - id: runtime.deployment
+    name: Deployment & Release
+    purpose: Bring defined software versions and configurations into operational environments in a controlled manner.
+    profiles:
+    - rolling
+    - blue-green
+    - canary
+    - immutable
+    qualities:
+    - rollback
+    - lead_time
+    - failure_rate
+    - traceability
+    evidence:
+    - deployment_records
+    - rollback_test
+- id: operations
+  name: Operations & Assurance
+  capabilities:
+  - id: operations.observability
+    name: Observability
+    purpose: Establish operational state and behavior from telemetry such as logs, metrics, traces, events, and
+      derived signals.
+    profiles:
+    - logs
+    - metrics
+    - traces
+    - events
+    - profiles
+    qualities:
+    - coverage
+    - freshness
+    - retention
+    - queryability
+    evidence:
+    - telemetry_coverage
+    - dashboard_or_query_evidence
+  - id: operations.alerting
+    name: Alerting
+    purpose: Detect relevant conditions and surface them to humans or automation.
+    profiles:
+    - threshold
+    - anomaly
+    - event
+    - slo
+    qualities:
+    - detection_latency
+    - precision
+    - delivery
+    - escalation
+    may_use:
+    - operations.observability
+    - integration.notification
+    evidence:
+    - alert_tests
+    - incident_linkage
+  - id: operations.audit
+    name: Audit
+    purpose: Produce attributable historical evidence about relevant actions, changes, and decisions.
+    profiles:
+    - security
+    - administrative
+    - business
+    - decision
+    qualities:
+    - integrity
+    - attribution
+    - retention
+    - queryability
+    evidence:
+    - audit_records
+    - integrity_verification
+  - id: operations.recovery
+    name: Service Recovery
+    purpose: Restore an operational service after failure or degradation.
+    profiles:
+    - restart
+    - failover
+    - rebuild
+    - disaster-recovery
+    qualities:
+    - rto
+    - recovery_success_rate
+    - automation
+    may_use:
+    - data.backup
+    - operations.observability
+    evidence:
+    - recovery_tests
+    - incident_recovery_records
+  - id: operations.continuity
+    name: Continuity
+    purpose: Maintain acceptable service operation despite disruption.
+    profiles:
+    - high-availability
+    - multi-zone
+    - multi-region
+    - degraded-mode
+    qualities:
+    - availability
+    - fault_tolerance
+    - capacity_reserve
+    evidence:
+    - continuity_tests
+    - availability_metrics
+- id: security
+  name: Security & Governance
+  capabilities:
+  - id: security.secrets
+    name: Secret Management
+    purpose: Protect, distribute, rotate, and revoke confidential credentials and secrets.
+    profiles:
+    - static
+    - dynamic
+    - application
+    - human
+    qualities:
+    - rotation
+    - access_control
+    - auditability
+    - availability
+    evidence:
+    - rotation_records
+    - access_audit
+  - id: security.keys
+    name: Key & Certificate Management
+    purpose: Create, protect, distribute, rotate, validate, and revoke cryptographic keys and certificates.
+    profiles:
+    - tls
+    - signing
+    - encryption
+    - pki
+    qualities:
+    - rotation
+    - revocation
+    - expiry_control
+    - key_protection
+    evidence:
+    - certificate_inventory
+    - rotation_records
+  - id: security.policy
+    name: Policy Management & Enforcement
+    purpose: Define, distribute, evaluate, and enforce machine-interpretable policies.
+    profiles:
+    - access
+    - configuration
+    - admission
+    - compliance
+    qualities:
+    - coverage
+    - decision_latency
+    - versioning
+    - explainability
+    evidence:
+    - policy_tests
+    - decision_records
+  - id: security.vulnerability
+    name: Vulnerability Management
+    purpose: Identify, assess, prioritize, remediate, mitigate, and track exploitable weaknesses.
+    profiles:
+    - source
+    - dependency
+    - image
+    - runtime
+    - infrastructure
+    qualities:
+    - coverage
+    - time_to_detect
+    - time_to_remediate
+    - risk_acceptance
+    evidence:
+    - scan_results
+    - remediation_records
+  - id: governance.evidence
+    name: Compliance Evidence
+    purpose: Produce and maintain evidence supporting governance, assurance, certification, or compliance assertions.
+    profiles:
+    - technical
+    - organizational
+    - regulatory
+    qualities:
+    - completeness
+    - traceability
+    - freshness
+    - integrity
+    evidence:
+    - evidence_records
+    - assessment_links
+  - id: governance.lifecycle
+    name: Information Lifecycle Governance
+    purpose: Apply rules governing information retention, handling, deletion, preservation, and lifecycle transitions.
+    profiles:
+    - retention
+    - deletion
+    - legal-hold
+    - classification
+    qualities:
+    - coverage
+    - enforcement
+    - traceability
+    evidence:
+    - lifecycle_policy
+    - deletion_records
+    - retention_evidence
+- id: commerce
+  name: Commerce
+  capabilities:
+  - id: commerce.metering
+    name: Metering
+    purpose: Measure usage or activity that is commercially or contractually relevant.
+    profiles:
+    - usage
+    - event
+    - capacity
+    - time
+    qualities:
+    - accuracy
+    - completeness
+    - latency
+    - auditability
+    evidence:
+    - meter_records
+    - reconciliation
+  - id: commerce.billing
+    name: Billing
+    purpose: Calculate amounts owed based on contracts, pricing rules, entitlements, metering, or events.
+    profiles:
+    - subscription
+    - usage-based
+    - one-time
+    - hybrid
+    qualities:
+    - accuracy
+    - explainability
+    - reconciliation
+    - currency_support
+    may_use:
+    - commerce.metering
+    - commerce.entitlement
+    evidence:
+    - invoice_tests
+    - billing_reconciliation
+  - id: commerce.payment
+    name: Payment
+    purpose: Transfer monetary value between parties.
+    profiles:
+    - card
+    - sepa
+    - bank-transfer
+    - wallet
+    - payout
+    - recurring
+    qualities:
+    - success_rate
+    - settlement_time
+    - currency_support
+    - refund_support
+    may_use:
+    - identity.authentication
+    - operations.audit
+    - integration.api
+    evidence:
+    - payment_records
+    - settlement_reconciliation
+  - id: commerce.entitlement
+    name: Entitlement
+    purpose: Determine which products, features, capacities, or service levels a customer or actor is contractually
+      allowed to use.
+    profiles:
+    - feature
+    - capacity
+    - plan
+    - time-bound
+    qualities:
+    - decision_latency
+    - consistency
+    - auditability
+    may_use:
+    - identity.authorization
+    evidence:
+    - entitlement_tests
+    - decision_records
+- id: intelligence
+  name: Intelligence
+  capabilities:
+  - id: intelligence.generation
+    name: Generation
+    purpose: Produce novel information representations from context or instructions.
+    profiles:
+    - text
+    - image
+    - audio
+    - video
+    - code
+    - structured-data
+    qualities:
+    - quality
+    - latency
+    - cost
+    - safety
+    evidence:
+    - evaluation_results
+    - latency_metrics
+  - id: intelligence.extraction
+    name: Extraction & Classification
+    purpose: Derive structured information, labels, attributes, or classifications from input.
+    profiles:
+    - ocr
+    - document-extraction
+    - entity-extraction
+    - classification
+    - speech-recognition
+    qualities:
+    - accuracy
+    - recall
+    - precision
+    - latency
+    evidence:
+    - evaluation_results
+    - golden_set_tests
+  - id: intelligence.embedding
+    name: Semantic Representation
+    purpose: Produce machine-usable semantic representations of information.
+    profiles:
+    - text
+    - image
+    - multimodal
+    qualities:
+    - dimensionality
+    - semantic_quality
+    - latency
+    - cost
+    evidence:
+    - retrieval_benchmarks
+    - latency_metrics
+  - id: intelligence.retrieval
+    name: Semantic Retrieval & Ranking
+    purpose: Select or rank information according to semantic relevance.
+    profiles:
+    - vector
+    - reranking
+    - hybrid
+    - multimodal
+    qualities:
+    - recall
+    - precision
+    - ranking_quality
+    - latency
+    may_use:
+    - intelligence.embedding
+    - data.search
+    evidence:
+    - retrieval_benchmarks
+  - id: intelligence.reasoning
+    name: Reasoning & Decision
+    purpose: Derive judgments, plans, decisions, hypotheses, or action proposals from context and constraints.
+    profiles:
+    - analysis
+    - planning
+    - decision
+    - agentic
+    qualities:
+    - task_success
+    - reliability
+    - latency
+    - cost
+    - explainability
+    may_use:
+    - intelligence.retrieval
+    evidence:
+    - task_evaluations
+    - decision_records
--- a/infospace/indexes/artifact-tree.yaml
+++ b/infospace/indexes/artifact-tree.yaml
@ -1,5 +1,5 @@
 root: infospace
-file_count: 161
+file_count: 175
 files:
 - path: README.md
  directory: .
@ -85,6 +85,9 @@ files:
 - path: agent/briefs/model-access-control.md
  directory: agent/briefs
  name: model-access-control.md
+- path: agent/briefs/model-capability.md
+  directory: agent/briefs
+  name: model-capability.md
 - path: agent/briefs/model-data.md
  directory: agent/briefs
  name: model-data.md
@ -199,6 +202,39 @@ files:
 - path: assimilation/README.md
  directory: assimilation
  name: README.md
+- path: assimilation/intake-and-assimilation-practice.md
+  directory: assimilation
+  name: intake-and-assimilation-practice.md
+- path: assimilation/it-capability-canon/ASSIMILATION.md
+  directory: assimilation/it-capability-canon
+  name: ASSIMILATION.md
+- path: assimilation/it-capability-canon/assimilation.yaml
+  directory: assimilation/it-capability-canon
+  name: assimilation.yaml
+- path: assimilation/it-capability-canon/comparison-matrix.md
+  directory: assimilation/it-capability-canon
+  name: comparison-matrix.md
+- path: assimilation/it-capability-canon/extracted-concepts.yaml
+  directory: assimilation/it-capability-canon
+  name: extracted-concepts.yaml
+- path: assimilation/it-capability-canon/mappings.yaml
+  directory: assimilation/it-capability-canon
+  name: mappings.yaml
+- path: assimilation/it-capability-canon/open-questions.md
+  directory: assimilation/it-capability-canon
+  name: open-questions.md
+- path: assimilation/it-capability-canon/proposed-changes.md
+  directory: assimilation/it-capability-canon
+  name: proposed-changes.md
+- path: assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
+  directory: assimilation/it-capability-canon/source
+  name: ITCapabilityCanonV0.1.md
+- path: assimilation/it-capability-canon/source/capabilities.yaml
+  directory: assimilation/it-capability-canon/source
+  name: capabilities.yaml
+- path: assimilation/it-capability-canon/source-summary.md
+  directory: assimilation/it-capability-canon
+  name: source-summary.md
 - path: concepts/purpose-demand.yaml
  directory: concepts
  name: purpose-demand.yaml
@ -304,6 +340,12 @@ files:
 - path: models/access-control/InfoTechCanonAccessControlModel.md
  directory: models/access-control
  name: InfoTechCanonAccessControlModel.md
+- path: models/capability/InfoTechCanonCapabilityModel.md
+  directory: models/capability
+  name: InfoTechCanonCapabilityModel.md
+- path: models/capability/capabilities.yaml
+  directory: models/capability
+  name: capabilities.yaml
 - path: models/data/InfoTechCanonDataModel.md
  directory: models/data
  name: InfoTechCanonDataModel.md
--- a/infospace/indexes/concept-ownership.yaml
+++ b/infospace/indexes/concept-ownership.yaml
@ -1,5 +1,9 @@
-concept_count: 90
+concept_count: 106
 concepts:
+- concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
+  owner: assimilation/it-capability-canon
+  path: assimilation/it-capability-canon/ASSIMILATION.md
+  source: artifact_title
 - concept: CARING Kubernetes RBAC Benchmark
  owner: benchmark/caring/kubernetes-rbac
  path: standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml
@ -20,6 +24,10 @@ concepts:
  owner: benchmark/caring/kubernetes-rbac/native-concepts
  path: standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml
  source: artifact_title
+- concept: InfoTechCanon Capability Catalog
+  owner: capability-catalog/itc-cap
+  path: models/capability/capabilities.yaml
+  source: artifact_title
 - concept: Repo Scoping Canon Benefit Analysis
  owner: comparison/repo-scoping/canon-benefit-analysis
  path: evaluations/repo-scoping/canon-benefit-analysis.yaml
@ -104,6 +112,58 @@ concepts:
  owner: model/access-control
  path: models/access-control/InfoTechCanonAccessControlModel.md
  source: artifact_title
+- concept: InfoTechCanon Capability Model
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: artifact_title
+- concept: Capability
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityDomain
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityProfile
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityContract
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityRequirement
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityProvider
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityProvision
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityMaturityLevel
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityQualityDimension
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityEvidenceHook
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityResourceClass
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: CapabilityInclusionRule
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
 - concept: InfoTechCanon Data Model
  owner: model/data
  path: models/data/InfoTechCanonDataModel.md
@ -192,6 +252,10 @@ concepts:
  owner: pattern/intent-scope-purposes
  path: patterns/intent-scope-purposes.md
  source: frontmatter.owned_concepts
+- concept: Intake and Assimilation Practice
+  owner: practice/intake-and-assimilation
+  path: assimilation/intake-and-assimilation-practice.md
+  source: artifact_title
 - concept: Small SaaS System Profile
  owner: profile/small-saas
  path: profiles/small-saas/profile.yaml
--- a/infospace/indexes/import-matrix.yaml
+++ b/infospace/indexes/import-matrix.yaml
@ -1,9 +1,11 @@
 artifacts:
+- assimilation/it-capability-canon
 - benchmark/caring/kubernetes-rbac
 - benchmark/caring/kubernetes-rbac/access-descriptors
 - benchmark/caring/kubernetes-rbac/caring-mapping
 - benchmark/caring/kubernetes-rbac/findings
 - benchmark/caring/kubernetes-rbac/native-concepts
+- capability-catalog/itc-cap
 - comparison/repo-scoping/canon-benefit-analysis
 - comparison/repo-scoping/consumer-workplan-brief
 - comparison/repo-scoping/extension-candidates
@ -25,6 +27,7 @@ artifacts:
 - kernel/itc-kernel-map
 - mapping/purpose-demand-governance-candidates
 - model/access-control
+- model/capability
 - model/data
 - model/devsecops
 - model/governance
@ -37,6 +40,7 @@ artifacts:
 - model/security
 - model/task
 - pattern/intent-scope-purposes
+- practice/intake-and-assimilation
 - profile/small-saas
 - review-kit/alignment
 - review-kit/alignment/model-selection-guide
@ -61,6 +65,10 @@ artifacts:
 - standard/repository-layout
 - standard/tagging
 rows:
+- artifact: assimilation/it-capability-canon
+  targets:
+    kernel/itc-core:
+    - conforms_to
 - artifact: benchmark/caring/kubernetes-rbac
  targets:
    model/access-control:
@ -123,6 +131,8 @@ rows:
    - maps
    standard/caring:
    - maps
+- artifact: capability-catalog/itc-cap
+  targets: {}
 - artifact: comparison/repo-scoping/canon-benefit-analysis
  targets:
    comparison/repo-scoping/report:
@ -381,6 +391,22 @@ rows:
    - uses
    model/organization:
    - uses
+- artifact: model/capability
+  targets:
+    assimilation/it-capability-canon:
+    - derived_from
+    capability-catalog/itc-cap:
+    - introduces
+    kernel/itc-core:
+    - conforms_to
+    model/governance:
+    - uses
+    model/landscape:
+    - uses
+    model/observability:
+    - uses
+    model/purpose-demand-extension:
+    - uses
 - artifact: model/data
  targets:
    kernel/itc-core:
@ -451,6 +477,10 @@ rows:
    - implements
    model/task:
    - uses
+- artifact: practice/intake-and-assimilation
+  targets:
+    kernel/itc-core:
+    - conforms_to
 - artifact: profile/small-saas
  targets:
    kernel/itc-core:
--- a/infospace/infospace.yaml
+++ b/infospace/infospace.yaml
@ -31,6 +31,8 @@ disciplines:
    path: models/network/InfoTechCanonNetworkModel.md
  - name: Observability Model
    path: models/observability/InfoTechCanonObservabilityModel.md
+  - name: Capability Model
+    path: models/capability/InfoTechCanonCapabilityModel.md
  - name: Tagging Standard
    path: standards/tagging/InfoTechCanonTaggingStandard.md
  - name: CARING Access Governance Standard
--- a/infospace/models/capability/InfoTechCanonCapabilityModel.md
+++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md
@ -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.
--- a/infospace/models/capability/capabilities.yaml
+++ b/infospace/models/capability/capabilities.yaml
--- a/infospace/validation/latest.json
+++ b/infospace/validation/latest.json
@ -1,21 +1,16 @@
 {
  "details": {
-    "artifact_count": 61,
-    "relationship_count": 277
+    "artifact_count": 65,
+    "relationship_count": 286
  },
  "errors": [],
  "metrics": {
    "coherence_components": 1.0,
    "consistency_cycles": 0.0,
    "coverage_ratio": 1.0,
-    "granularity_entropy": 4.329602269609256,
+    "granularity_entropy": 4.443367176892838,
    "redundancy_ratio": 0.0
  },
  "ok": true,
-  "warnings": [
-    {
-      "code": "empty_optional_collection",
-      "path": "infospace/assimilation"
-    }
-  ]
+  "warnings": []
 }
--- a/infospace/views/by-concept.md
+++ b/infospace/views/by-concept.md
@ -2,15 +2,17 @@

 # By Concept

-Concept count: **90**
+Concept count: **106**

 | Concept | Owner | Source |
 | --- | --- | --- |
+| Assimilation — IT Capability Canon (ITCC) v0.1 | `assimilation/it-capability-canon` | `artifact_title` |
 | CARING Kubernetes RBAC Benchmark | `benchmark/caring/kubernetes-rbac` | `artifact_title` |
 | Kubernetes RBAC CARING Access Descriptors | `benchmark/caring/kubernetes-rbac/access-descriptors` | `artifact_title` |
 | Kubernetes RBAC To CARING Mapping | `benchmark/caring/kubernetes-rbac/caring-mapping` | `artifact_title` |
 | Kubernetes RBAC Benchmark Findings And Canon Pressure | `benchmark/caring/kubernetes-rbac/findings` | `artifact_title` |
 | Kubernetes RBAC Native Concept Map | `benchmark/caring/kubernetes-rbac/native-concepts` | `artifact_title` |
+| InfoTechCanon Capability Catalog | `capability-catalog/itc-cap` | `artifact_title` |
 | Repo Scoping Canon Benefit Analysis | `comparison/repo-scoping/canon-benefit-analysis` | `artifact_title` |
 | Repo Scoping Consumer Workplan Brief | `comparison/repo-scoping/consumer-workplan-brief` | `artifact_title` |
 | Repo Scoping Canon Extension Candidates | `comparison/repo-scoping/extension-candidates` | `artifact_title` |
@ -32,6 +34,19 @@ Concept count: **90**
 | InfoTechCanon Kernel Map | `kernel/itc-kernel-map` | `artifact_title` |
 | Purpose Demand Governance Extension Candidates | `mapping/purpose-demand-governance-candidates` | `artifact_title` |
 | InfoTechCanon Access Control Model | `model/access-control` | `artifact_title` |
+| InfoTechCanon Capability Model | `model/capability` | `artifact_title` |
+| Capability | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityDomain | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityProfile | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityContract | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityRequirement | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityProvider | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityProvision | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityMaturityLevel | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityQualityDimension | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityEvidenceHook | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityResourceClass | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityInclusionRule | `model/capability` | `frontmatter.owned_concepts` |
 | InfoTechCanon Data Model | `model/data` | `artifact_title` |
 | InfoTechCanon DevSecOps Model | `model/devsecops` | `artifact_title` |
 | InfoTechCanon Governance Model | `model/governance` | `artifact_title` |
@ -54,6 +69,7 @@ Concept count: **90**
 | InfoTechCanon Task Model | `model/task` | `artifact_title` |
 | Intent Scope Purposes Pattern | `pattern/intent-scope-purposes` | `artifact_title` |
 | IntentScopePurposePattern | `pattern/intent-scope-purposes` | `frontmatter.owned_concepts` |
+| Intake and Assimilation Practice | `practice/intake-and-assimilation` | `artifact_title` |
 | Small SaaS System Profile | `profile/small-saas` | `artifact_title` |
 | Canon Consumer Alignment Review Kit | `review-kit/alignment` | `artifact_title` |
 | Canon Model And Standard Selection Guide | `review-kit/alignment/model-selection-guide` | `artifact_title` |
--- a/infospace/views/by-mapping-target.md
+++ b/infospace/views/by-mapping-target.md
@ -2,6 +2,10 @@

 # By Mapping Target

+## `assimilation/it-capability-canon`
+
+- `model/capability` via `derived_from`
+
 ## `benchmark/caring/kubernetes-rbac`

 - `benchmark/caring/kubernetes-rbac/access-descriptors` via `part_of`
@ -11,6 +15,10 @@
 - `review-kit/alignment` via `uses`
 - `review-kit/alignment/model-selection-guide` via `uses`

+## `capability-catalog/itc-cap`
+
+- `model/capability` via `introduces`
+
 ## `comparison/repo-scoping/report`

 - `comparison/repo-scoping/canon-benefit-analysis` via `part_of`
@ -46,9 +54,11 @@

 ## `kernel/itc-core`

+- `assimilation/it-capability-canon` via `conforms_to`
 - `concept-catalog/purpose-demand` via `conforms_to`
 - `kernel/itc-kernel-map` via `maps`
 - `model/access-control` via `conforms_to`
+- `model/capability` via `conforms_to`
 - `model/data` via `conforms_to`
 - `model/devsecops` via `conforms_to`
 - `model/governance` via `conforms_to`
@ -60,6 +70,7 @@
 - `model/purpose-demand-extension` via `conforms_to`
 - `model/security` via `conforms_to`
 - `model/task` via `conforms_to`
+- `practice/intake-and-assimilation` via `conforms_to`
 - `profile/small-saas` via `conforms_to`
 - `review-kit/alignment` via `conforms_to`
 - `standard/caring` via `conforms_to`
@ -127,6 +138,7 @@
 - `kernel/itc-kernel-map` via `maps`
 - `mapping/purpose-demand-governance-candidates` via `maps`
 - `model/access-control` via `uses`
+- `model/capability` via `uses`
 - `model/data` via `uses`
 - `model/purpose-demand-extension` via `extends`
 - `pattern/intent-scope-purposes` via `uses`
@ -156,6 +168,7 @@
 - `conformance/railiance-fabric/entity-edge-capture-criteria` via `uses`
 - `conformance/railiance-fabric/mapping-expectations` via `maps`
 - `kernel/itc-kernel-map` via `maps`
+- `model/capability` via `uses`
 - `profile/small-saas` via `requires`
 - `review-kit/alignment/model-selection-guide` via `uses`
 - `small-saas/service/billing-portal` via `uses`
@ -180,6 +193,7 @@
 - `conformance/railiance-fabric/entity-edge-capture-criteria` via `uses`
 - `conformance/railiance-fabric/mapping-expectations` via `maps`
 - `kernel/itc-kernel-map` via `maps`
+- `model/capability` via `uses`
 - `profile/small-saas` via `requires`
 - `review-kit/alignment/model-selection-guide` via `uses`
 - `small-saas/evidence/access-review-2026-05` via `uses`
@ -217,6 +231,7 @@
 - `evaluation/user-engine/questions` via `uses`
 - `example/consumer-purpose-portfolio` via `illustrates`
 - `mapping/purpose-demand-governance-candidates` via `maps`
+- `model/capability` via `uses`
 - `pattern/intent-scope-purposes` via `implements`
 - `review-kit/alignment` via `uses`
 - `review-kit/alignment/model-selection-guide` via `uses`
--- a/infospace/views/import-matrix.md
+++ b/infospace/views/import-matrix.md
@ -2,66 +2,70 @@

 # Import Matrix

-| Artifact | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `benchmark/caring/kubernetes-rbac` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `stress_tests` |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  | `uses` |
-| `benchmark/caring/kubernetes-rbac/access-descriptors` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `benchmark/caring/kubernetes-rbac/caring-mapping` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` |  |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
-| `benchmark/caring/kubernetes-rbac/findings` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |
-| `benchmark/caring/kubernetes-rbac/native-concepts` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
-| `comparison/repo-scoping/canon-benefit-analysis` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |  |  |  |  | `maps` |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |
-| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |
-| `conformance/railiance-fabric/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/entity-edge-capture-criteria` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/mapping-expectations` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` | `maps` |  | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/interface-card-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `evaluation/user-engine/questions` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-kernel-map` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  | `maps` |
-| `mapping/purpose-demand-governance-candidates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `profile/small-saas` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `requires` |  | `requires` |
-| `review-kit/alignment` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `review-kit/alignment/model-selection-guide` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` |  | `uses` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |
-| `review-kit/alignment/schema` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workplan-template` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/control/namespace-per-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `small-saas/dataset/subscription-ledger` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` | `owned_by` |  |  |  | `partitioned_for` | `partitioned_for` |  |  |  |  |
-| `small-saas/deployment/production` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `implements` |  |  |  |  |  | `deploys` |  |  |  | `separates` | `separates` |  |  |  |  |
-| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/incident/cross-tenant-access-attempt` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  | `constrained_by` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/policy/tenant-isolation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `requires` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |  |
-| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |  |
-| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |  |
-| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |  |
-| `small-saas/tenant/globex` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/user/ada-admin` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `access_evidenced_by` |  | `has_access_under` |  |  |  | `member_of` |  |  |  |  |  |  |
-| `standard/caring` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `imports` | `imports` | `imports` | `imports` |  |  | `imports` | `imports` | `imports` |  | `imports` | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |
-| `standard/repository-layout` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `imports` | `imports` |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `standard/tagging` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| Artifact | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `assimilation/it-capability-canon` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `benchmark/caring/kubernetes-rbac` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `stress_tests` |  |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  | `uses` |
+| `benchmark/caring/kubernetes-rbac/access-descriptors` |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `benchmark/caring/kubernetes-rbac/caring-mapping` |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  | `maps` |  |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
+| `benchmark/caring/kubernetes-rbac/findings` |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |
+| `benchmark/caring/kubernetes-rbac/native-concepts` |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
+| `capability-catalog/itc-cap` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/canon-benefit-analysis` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |  |  |  |  | `maps` |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |
+| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |
+| `conformance/railiance-fabric/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/entity-edge-capture-criteria` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/mapping-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` | `maps` |  | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/interface-card-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `evaluation/user-engine/questions` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `kernel/itc-kernel-map` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` |  | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  | `maps` |
+| `mapping/purpose-demand-governance-candidates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/capability` | `derived_from` |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `uses` |  | `uses` |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `practice/intake-and-assimilation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `profile/small-saas` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `requires` |  | `requires` | `requires` | `requires` |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `requires` |  | `requires` |
+| `review-kit/alignment` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `review-kit/alignment/model-selection-guide` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` |  |  | `uses` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |
+| `review-kit/alignment/schema` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/workplan-template` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/control/namespace-per-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `small-saas/dataset/subscription-ledger` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` | `owned_by` |  |  |  | `partitioned_for` | `partitioned_for` |  |  |  |  |
+| `small-saas/deployment/production` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `implements` |  |  |  |  |  | `deploys` |  |  |  | `separates` | `separates` |  |  |  |  |
+| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/incident/cross-tenant-access-attempt` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `instantiates` |  |  |  |  |  |  | `constrained_by` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/policy/tenant-isolation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `requires` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |  |
+| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |  |
+| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |  |
+| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |  |
+| `small-saas/tenant/globex` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/user/ada-admin` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `access_evidenced_by` |  | `has_access_under` |  |  |  | `member_of` |  |  |  |  |  |  |
+| `standard/caring` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `imports` |  | `imports` | `imports` | `imports` |  |  | `imports` | `imports` | `imports` |  | `imports` | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |
+| `standard/repository-layout` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  | `imports` | `imports` |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `standard/tagging` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
--- a/infospace/views/kernel-overview.md
+++ b/infospace/views/kernel-overview.md
@ -3,7 +3,7 @@
 # Kernel Overview

 - Infospace: `canon`
- Artifacts: 61
+- Artifacts: 65

 ## Artifact Kinds

@ -12,9 +12,11 @@
 - `alignment-review-schema`: 1
 - `alignment-review-workflow`: 1
 - `alignment-scorecard`: 1
+- `assimilation`: 1
 - `benchmark-findings`: 1
 - `benchmark-workspace`: 1
 - `benefit-analysis`: 1
+- `capability-catalog`: 1
 - `capture-criteria`: 1
 - `caring-mapping`: 1
 - `comparison-frame`: 1
@ -31,11 +33,12 @@
 - `kernel`: 2
 - `mapping`: 1
 - `mapping-expectation`: 1
- `model`: 11
+- `model`: 12
 - `model-extension`: 1
 - `model-selection-guide`: 1
 - `native-concept-map`: 1
 - `pattern`: 1
+- `practice`: 1
 - `profile`: 1
 - `profile-alignment`: 1
 - `profile-artifact`: 13
@ -47,9 +50,10 @@
 - `access_evidenced_by`: 1
 - `changes`: 1
 - `compares`: 1
- `conforms_to`: 19
+- `conforms_to`: 22
 - `constrained_by`: 1
 - `deploys`: 1
+- `derived_from`: 1
 - `evaluates`: 2
 - `evidenced_by`: 3
 - `extends`: 1
@ -59,7 +63,7 @@
 - `implements`: 2
 - `imports`: 14
 - `instantiates`: 13
- `introduces`: 1
+- `introduces`: 2
 - `isolated_by`: 2
 - `maps`: 36
 - `member_of`: 1
@ -72,4 +76,4 @@
 - `separates`: 2
 - `serves`: 2
 - `stress_tests`: 6
- `uses`: 113
+- `uses`: 117
--- a/infospace/views/repository-tree.md
+++ b/infospace/views/repository-tree.md
@ -2,7 +2,7 @@

 # Repository Tree

-File count: **161**
+File count: **175**

 - `README.md`
 - `agent/README.md`
@ -32,6 +32,7 @@ File count: **161**
 - `agent/briefs/kernel-itc-kernel-map.md`
 - `agent/briefs/mapping-purpose-demand-governance-candidates.md`
 - `agent/briefs/model-access-control.md`
+- `agent/briefs/model-capability.md`
 - `agent/briefs/model-data.md`
 - `agent/briefs/model-devsecops.md`
 - `agent/briefs/model-governance.md`
@ -70,6 +71,17 @@ File count: **161**
 - `agent/templates/consumer-brief.template.md`
 - `artifacts/index.yaml`
 - `assimilation/README.md`
+- `assimilation/intake-and-assimilation-practice.md`
+- `assimilation/it-capability-canon/ASSIMILATION.md`
+- `assimilation/it-capability-canon/assimilation.yaml`
+- `assimilation/it-capability-canon/comparison-matrix.md`
+- `assimilation/it-capability-canon/extracted-concepts.yaml`
+- `assimilation/it-capability-canon/mappings.yaml`
+- `assimilation/it-capability-canon/open-questions.md`
+- `assimilation/it-capability-canon/proposed-changes.md`
+- `assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
+- `assimilation/it-capability-canon/source/capabilities.yaml`
+- `assimilation/it-capability-canon/source-summary.md`
 - `concepts/purpose-demand.yaml`
 - `evaluations/railiance-fabric/conformance-pack.yaml`
 - `evaluations/railiance-fabric/consumer-workplan-brief.md`
@ -105,6 +117,8 @@ File count: **161**
 - `mappings/README.md`
 - `mappings/purpose-demand-governance-candidates.yaml`
 - `models/access-control/InfoTechCanonAccessControlModel.md`
+- `models/capability/InfoTechCanonCapabilityModel.md`
+- `models/capability/capabilities.yaml`
 - `models/data/InfoTechCanonDataModel.md`
 - `models/devsecops/InfoTechCanonDevSecOpsModel.md`
 - `models/governance/InfoTechCanonGovernanceModel.md`
--- a/tests/test_cli.py
+++ b/tests/test_cli.py
@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None:
    assert exit_code == 0
    payload = json.loads(capsys.readouterr().out)
    assert payload["ok"] is True
-    assert payload["infospace"]["artifact_count"] == 61
+    assert payload["infospace"]["artifact_count"] == 65


 def test_cli_missing_profile_uses_structured_error(capsys) -> None:
--- a/tests/test_service.py
+++ b/tests/test_service.py
@ -21,16 +21,18 @@ def test_inspect_canon_counts_artifact_kinds() -> None:

    assert payload["ok"] is True
    assert payload["infospace"]["slug"] == "canon"
-    assert payload["infospace"]["artifact_count"] == 61
+    assert payload["infospace"]["artifact_count"] == 65
    assert payload["infospace"]["kinds"] == {
        "access-descriptor-set": 1,
        "alignment-review-kit": 1,
+        "assimilation": 1,
        "alignment-review-schema": 1,
        "alignment-review-workflow": 1,
        "alignment-scorecard": 1,
        "benefit-analysis": 1,
        "benchmark-findings": 1,
        "benchmark-workspace": 1,
+        "capability-catalog": 1,
        "capture-criteria": 1,
        "caring-mapping": 1,
        "comparison-frame": 1,
@ -47,11 +49,12 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
        "kernel": 2,
        "mapping": 1,
        "mapping-expectation": 1,
-        "model": 11,
+        "model": 12,
        "model-extension": 1,
        "model-selection-guide": 1,
        "native-concept-map": 1,
        "pattern": 1,
+        "practice": 1,
        "profile-alignment": 1,
        "profile": 1,
        "profile-artifact": 13,
@ -61,7 +64,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:


 def test_model_and_standard_lists_are_filtered() -> None:
-    assert list_models()["count"] == 11
+    assert list_models()["count"] == 12
    assert list_standards()["count"] == 3


@ -90,14 +93,14 @@ def test_validate_canon_passes_scaffold() -> None:
    assert payload["ok"] is True
    assert payload["errors"] == []
    assert "warnings" in payload
-    assert payload["details"]["artifact_count"] == 61
+    assert payload["details"]["artifact_count"] == 65


 def test_graph_exports_relationship_summary() -> None:
    payload = artifact_graph()

    assert payload["ok"] is True
-    assert payload["graph"]["node_count"] == 61
+    assert payload["graph"]["node_count"] == 65
    assert payload["graph"]["edge_count"] > 15


--- a/workplans/ITC-WP-0014-capability-model-consolidation.md
+++ b/workplans/ITC-WP-0014-capability-model-consolidation.md
@ -0,0 +1,133 @@
+---
+id: ITC-WP-0014
+type: workplan
+title: "Capability Model consolidation (post-ITCC assimilation)"
+domain: infotech
+topic_slug: canon
+repo: info-tech-canon
+status: proposed
+priority: medium
+created: "2026-08-14"
+updated: "2026-08-14"
+depends_on_workplans:
+  - ITC-WP-0003
+  - ITC-WP-0006
+owner: claude
+spec_refs:
+  - infospace/assimilation/it-capability-canon/ASSIMILATION.md
+  - infospace/assimilation/it-capability-canon/proposed-changes.md
+  - infospace/assimilation/it-capability-canon/open-questions.md
+  - infospace/models/capability/InfoTechCanonCapabilityModel.md
+---
+
+# ITC-WP-0014 — Capability Model Consolidation
+
+## Goal
+
+Promote `InfoTechCanonCapabilityModel` from `proposed` to a usable canon model by
+closing the items the ITCC v0.1 assimilation deliberately deferred.
+
+## Intent
+
+Canon version 0.2.0 adopted the capability vocabulary under disposition `adapt`.
+The model is registered, validated, and anchored, but it has no schema, no formal
+mapping artifacts, no profile exercising it, and one unresolved identifier
+question that is blocking because capability ids are durable interfaces.
+
+## Tasks
+
+### T01 — Resolve the `governance.*` identifier prefix (OQ-2)
+
+```task
+id: ITC-WP-0014-T01
+status: todo
+priority: high
+```
+
+Decide between keeping the ids, renumbering to `security.*`, or splitting the
+navigation domain into `security` and `governance` (preferred — preserves every
+id). Record as a DecisionRecord. **Blocks promotion beyond `proposed`.**
+
+### T02 — Publish `capability.schema.yaml`
+
+```task
+id: ITC-WP-0014-T02
+status: todo
+priority: high
+depends_on: [T01]
+```
+
+Add the capability contract schema under `infospace/schemas/`, register it in
+`infospace/infospace.yaml`, and validate `capabilities.yaml` against it.
+
+### T03 — Formal mapping artifacts for each anchor
+
+```task
+id: ITC-WP-0014-T03
+status: todo
+priority: medium
+depends_on: [T02]
+```
+
+Turn `assimilation/it-capability-canon/mappings.yaml` into per-pair mapping
+artifacts under `infospace/mappings/` conforming to `mapping.schema.yaml`.
+
+### T04 — Small-SaaS capability requirement set
+
+```task
+id: ITC-WP-0014-T04
+status: todo
+priority: medium
+depends_on: [T02]
+```
+
+Express a real `CapabilityRequirement` set with provisions and evidence in the
+small-saas profile (coordinate with ITC-WP-0004). This is the practical proof
+required for promotion.
+
+### T05 — Landscape and kernel-map revision
+
+```task
+id: ITC-WP-0014-T05
+status: todo
+priority: medium
+depends_on: [T01]
+```
+
+Revise `InfoTechCanonLandscapeModel` §11.4 (the deferred strategy/capability note)
+to reference ITC-CAP, and add the capability model to
+`InfoTechCanonKernelMap`.
+
+### T06 — Requirement/provision validation in the service surface
+
+```task
+id: ITC-WP-0014-T06
+status: todo
+priority: low
+depends_on: [T02]
+```
+
+Extend the CLI/JSON/API surface (ITC-WP-0002) to answer "does this environment
+satisfy this product's capability requirements?" — the validator sketched in
+source §18. Covers OQ-6.
+
+### T07 — Promotion review
+
+```task
+id: ITC-WP-0014-T07
+status: todo
+priority: medium
+depends_on: [T01, T02, T03, T04]
+```
+
+Promote the model from `proposed` to `draft` or `release-candidate`, bump the
+canon version, and write the `CHANGELOG.md` entry.
+
+## Out of scope
+
+- New domain models for `commerce.*` / `intelligence.*` (OQ-5) — needs a real
+  consumer demand first.
+- Canon-wide intended/declared/applied/observed/assessed state qualifiers (OQ-3)
+  — kernel-level pressure, not a capability-model decision.
+- CARING importing `identity.*` ids — touches a release-candidate standard and
+  needs its own review.
--- a/workplans/index.yaml
+++ b/workplans/index.yaml
@ -179,3 +179,31 @@ workplans:
      - repository-layout standard placement and extension candidates
      - registered repository-layout standard
      - consumer adoption brief
+
+  - id: ITC-WP-0013
+    title: Attribute Value Type catalog (Data Model extension)
+    status: proposed
+    priority: high
+    path: workplans/ITC-WP-0013-attribute-value-type-catalog.md
+    depends_on:
+      - ITC-WP-0006
+    produces:
+      - reviewed attribute-value-type demand signal
+      - attribute value type catalog standard section
+      - machine-readable attribute value type catalog
+      - consumer alignment note
+
+  - id: ITC-WP-0014
+    title: Capability Model consolidation (post-ITCC assimilation)
+    status: proposed
+    priority: medium
+    path: workplans/ITC-WP-0014-capability-model-consolidation.md
+    depends_on:
+      - ITC-WP-0003
+      - ITC-WP-0006
+    produces:
+      - resolved capability identifier prefix decision
+      - capability contract schema
+      - formal capability mapping artifacts
+      - small-saas capability requirement set
+      - capability requirement/provision validation surface