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.

---

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.

---

Decision Record — Capability provision economics (demand 2026-08-15)

Date: 2026-08-15 · Canon version: 0.3.0 · Model version: ITC-CAP 0.2.0 Demand: demand/CapabilityProvisionEconomics.md (resource-control)

Context. After a completed procurement-to-control cycle, resource-control mapped a real backup provision onto ITC-CAP v0.1.0. The catalog, evidence hooks, and D-scale worked. Three defects did not: typical_resource_classes contradicted §4.11 and carried almost no information; a requirement could not express profile, quality targets, or failure-domain constraints; the class set had no human-effort class and treated Intelligence as one more purchased input, so labour-inverted provider selection was inexpressible.

Decision. Refine the still-proposed model in place. Do not split ITC-CAP into supply-side and demand-side canons. Do not open a separate workplan for finding C: the LAND and commerce touches are boundary clarifications, not new owning models.

1. Finding A. Remove typical_resource_classes from every capability contract. Consumption is declared on CapabilityProvision only (CAP-R8). No non-normative hint is kept — 29 of 41 entries were identical.
2. Finding B. Enrich CapabilityRequirement with optional profile, targets against declared quality dimensions, and constraints with a closed predicate set. Intended targets stay on the requirement; measurement and observed SLOs stay with ITC-LAND / ITC-OBS. No new dimension vocabulary.
3. Finding C. Add class H (Human Effort, native unit hour, default supply internal, default capacity constrained). Narrow P so it no longer absorbs human time. Recharacterise I as the elastic purchased substitute for H, native unit token. Declare native_unit, supply, and capacity_behaviour on each class; a consumption record may override the last two. Record unknown as unknown, never zero. Add quality dimension intelligence_intensity on intelligence.*. Do not declare substitutes_for or an exchange rate.

Options considered.

1. Leave the proposed model unchanged until promotion. Rejected: the defects are cheapest to fix before capability.schema.yaml (ITC-WP-0014 T02) freezes the contract shape, and before a consumer restates a real provision against it.
2. Split ITC-CAP into demand-side and supply-side canons. Rejected by the consumer and accepted here: the two sides agree about what exists. Splitting would replace CAP-R5's joinable id with a translation layer.
3. Solve finding C only inside resource-control. Rejected: a private class set would diverge the moment a second repository reports provision economics.
4. Name the new class L (Labour). Rejected: H/I is the contrast the class set exists to make observable; L also collides with Landscape in casual speech.
5. Fix A and B now, defer C to a new workplan. Rejected for this revision: publishing A+B without C would leave the class set still wrong and force an immediate follow-up version. C does not require a LAND or commerce model change.

Rationale. The capability layer is working. The demand is a refinement of a model that independently converged on the same backup evidence hooks the consumer had already produced. Native units preserve constraint and substitution information that currency destroys. Observing H/I substitution from a time series is cheaper and more defensible than asserting a rate the canon cannot know.

Consequences.

• Canon 0.3.0 (minor: new concepts and backward-compatible extensions; no capability id changed). ITC-CAP 0.1.0 → 0.2.0. Status remains proposed.
• New owned concept: CapabilityConsumption.
• New rules: CAP-R8, CAP-R9.
• typical_resource_classes removed from the catalog. Any consumer that read that field must stop; it was never a durable interface.
• ITC-WP-0014 T02 will encode the refined contract, not the v0.1.0 one.
• Success criterion 6 of the demand (restate the backup case in canon terms) remains a consumer contribution, now against this shape.

Review trigger. First provision that needs a native unit the class table cannot host, or a constraint predicate outside {not_in, in, equals, lte, gte}. A full intelligence domain model remains OQ-5.