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/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 |