info-tech-canon/infospace/assimilation/it-capability-canon/ASSIMILATION.md

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

---

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.

4. Concept comparison

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