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>

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.