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`](../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.

---

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