# 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. --- ## Decision Record — OQ-2, capability identifier prefix **Date:** 2026-08-15 · **Canon version:** 0.2.1 **Context.** Four capabilities in navigation domain `security` used the `security.` prefix while two used `governance.` (`governance.evidence`, `governance.lifecycle`). Capability ids are durable interfaces (CAP-R5), so the inconsistency could not simply be corrected later without migration semantics. This blocked promotion beyond `proposed`. **Decision.** Split the "Security & Governance" navigation domain into two domains, `security` (4 capabilities) and `governance` (2). Every capability id is unchanged; each now sits in the domain its prefix names. The baseline becomes 41 capabilities across 9 navigation domains. **Options considered.** 1. *Keep as-is.* Rejected: leaves a visible defect in the primary index of a model whose whole value is stable, legible identifiers. 2. *Renumber `governance.*` to `security.*`.* Rejected: breaks two durable interfaces to fix a cosmetic issue, and would require a canon major version with migration semantics. 3. *Split the navigation domain.* Chosen. **Rationale.** Domains are declared `navigation_only: true` and carry no semantics (§4.2, Core §6.4 *Network Before Tree*), so splitting one costs nothing structurally. It is the only option that removes the inconsistency without touching an id. **Consequences.** - Canon `0.2.1` (patch: no concept added, removed, renamed, or reassigned). - `security.policy` and `governance.evidence` now appear in different sections of the catalog index despite being frequently co-used — an accepted navigation cost, and the reason option 1 was defensible. - OQ-2 no longer blocks promotion; `ITC-WP-0014` T01 is complete. **Review trigger.** If a third capability group emerges that spans both domains, revisit whether navigation domains should be replaced by tags.