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>

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 |

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
+```

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.

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"

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

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.

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

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.

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 |

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.

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