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