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