info-tech-canon/CHANGELOG.md

# Changelog — InfoTechCanon

Canon versions and their change notes. Entries follow the ChangeRecord shape of
`InfoTechCanonCore` §8.13: what changed, rationale, whether it is breaking, and
what produced it.

Versioning of `canon.yaml → version`:

- **patch** — editorial or generated-output changes; no concept change
- **minor** — new artifact, new concepts, backward-compatible extension
- **major** — a concept is removed, renamed, or its ownership moves

Canonical identifiers are durable interfaces; any break requires migration
semantics.

---

## 0.3.0 — 2026-08-15

### Changed — Capability provision economics (requirement targets, native-unit consumption, class `H`)

**Change.** The still-proposed Capability Model (`ITC-CAP`) moves from `0.1.0` to
`0.2.0` in response to consumer demand `demand/CapabilityProvisionEconomics.md`
(resource-control, a completed procurement-to-control cycle).

- **Contracts** no longer declare `typical_resource_classes`. Resource
  consumption attaches to a provision only (new CAP-R8), matching the rule §4.11
  already stated.
- **CapabilityRequirement** may select a profile, assert intended quality
  targets against the capability's declared dimensions, and state placement
  constraints with a closed predicate set (`not_in`, `in`, `equals`, `lte`,
  `gte`). Measurement remains with ITC-LAND / ITC-OBS (new CAP-R9).
- **Resource classes** gain `H` (Human Effort, native unit `hour`, default
  supply `internal`, default capacity `constrained`). `P` is narrowed to
  purchased platform and enabling services and no longer absorbs human time.
  `I` is recharacterised as the elastic purchased substitute for `H`, native
  unit `token`. Every class declares `native_unit`, `supply`, and
  `capacity_behaviour`; a consumption record may override the last two.
- **CapabilityConsumption** is a new owned concept: one native-unit row on a
  provision. Unknown is recorded as `unknown`, never as zero. Currency is not a
  class. No `substitutes_for` relation and no H↔I exchange rate.
- Quality dimension `intelligence_intensity` is declared on all five
  `intelligence.*` capabilities.

**Rationale.** The catalog, evidence hooks, and D-scale independently matched
the consumer's backup evidence. The three defects were cheapest to fix before
`capability.schema.yaml` freezes the contract and before the consumer restates
the real provision. Splitting ITC-CAP into demand-side and supply-side canons
was considered and rejected: both sides agree about what exists.

**Breaking:** no capability id, anchor, profile (except the new dimension on
`intelligence.*`), evidence hook, or relationship type changed.
`typical_resource_classes` is removed from the catalog; it was never a durable
interface.

**Records.** Decision record in
`assimilation/it-capability-canon/ASSIMILATION.md`; OQ-5 notes a partial fire;
`ITC-WP-0014` T08–T10 done.

**Validation.** `make validate` 0 errors / 0 warnings; `make test` 22 passed.

---

## 0.2.1 — 2026-08-15

### Changed — Capability navigation domains split (OQ-2 resolved)

**Change.** The `security` navigation domain ("Security & Governance") is split
into `security` (`security.secrets`, `security.keys`, `security.policy`,
`security.vulnerability`) and `governance` (`governance.evidence`,
`governance.lifecycle`). The baseline is now **41 capabilities across 9
navigation domains**.

**Rationale.** Four capabilities in the domain used the `security.` prefix while
two used `governance.`. Capability ids are durable interfaces (CAP-R5), so the
mismatch could not be corrected later without migration semantics, and it blocked
promotion of ITC-CAP beyond `proposed`. Navigation domains are declared
`navigation_only: true` and carry no semantics, so splitting one is a
table-of-contents change.

**Options rejected.** Keeping the mismatch (leaves a defect in the model's primary
index); renumbering `governance.*` to `security.*` (breaks two durable interfaces
for a cosmetic gain, requiring a major version).

**Breaking:** no. **No capability id, anchor, profile, quality dimension, evidence
hook, or relationship changed.** Artifact count, schemas, and consumers are
unaffected.

**Records.** Decision record in
`infospace/assimilation/it-capability-canon/ASSIMILATION.md`; OQ-2 closed in
`open-questions.md`; `ITC-WP-0014` T01 done.

**Validation.** `make validate` 0 errors / 0 warnings; `make test` 22 passed.

---

## 0.2.0 — 2026-08-14

### Added — InfoTechCanon Capability Model (`ITC-CAP`)

**Change.** The canon gains a twelfth domain model,
`infospace/models/capability/InfoTechCanonCapabilityModel.md`, with its
machine-readable baseline at `infospace/models/capability/capabilities.yaml`:
41 capabilities across 8 navigation domains, the D0–D7 provision maturity scale,
the C/S/N/I/P resource classes, capability relationship types, and admission
rules.

New canonical concepts: `Capability`, `CapabilityDomain`, `CapabilityProfile`,
`CapabilityContract`, `CapabilityRequirement`, `CapabilityProvider`,
`CapabilityProvision`, `CapabilityMaturityLevel`, `CapabilityQualityDimension`,
`CapabilityEvidenceHook`, `CapabilityResourceClass`, `CapabilityInclusionRule`.

**Rationale.** The canon modelled landscape, data, security, delivery, network,
observability, governance, organization, task, and access — but never *what an
information system must be able to do*. The Landscape Model deferred this ground
explicitly (§11.4). Consumers were already working around the gap.

**Source and disposition.** Adapted from the Information Technology Capability
Canon (ITCC) v0.1 under assimilation `assimilation/it-capability-canon`,
disposition `adapt`. Changes made on adoption:

- `Profile` renamed to `CapabilityProfile` — the name collided with the canon
  `Profile` artifact type (Core §8.6);
- `CapabilityProvision` made explicit, so maturity has a defined bearer;
- per-capability `anchors` added, naming the canon model(s) owning the concepts
  each capability exercises (guards Core §6.2 and §6.3);
- `CapabilityRequirement` bound to the Purpose and Demand extension as a typed
  `DemandSignal` rather than a parallel vocabulary;
- the source's proposed CILM landscape model **rejected** — the Landscape Model
  already owns that ground;
- capability definitions held only in YAML; the Markdown does not restate them.

**Breaking:** no. No existing canonical concept was removed, renamed, or moved.

**Artifact status.** The model enters at `proposed`. Promotion requires
resolution of open question OQ-2 (the `governance.*` id prefix), a published
contract schema, formal mapping artifacts, and one profile expressing a real
requirement set with evidence — tracked in `ITC-WP-0014`.

**Known weakness.** Seven capabilities (`commerce.*` except `entitlement`, and
four `intelligence.*`) are unanchored — new canon surface with no owning model
(OQ-5). Accepted at `proposed` status.

### Added — Intake and Assimilation Practice

`infospace/assimilation/intake-and-assimilation-practice.md` defines the
repository-wide procedure for absorbing new concepts and terminology: the
`incoming/` drop zone, frozen source snapshots, the Minimal Assimilation Profile,
the disposition gate, canon transformation and registration, and the resulting
canon version with change notes. `incoming/README.md` documents the drop zone.

**Rationale.** Inputs previously had no defined path from arrival to canon,
risking the copy-paste assimilation Core §29.6 warns against.

### Changed

- `canon.yaml` — version `0.1.0-scaffold` → `0.2.0`; `itc-cap` registered under
  `models:` with assimilation provenance.
- `infospace/artifacts/index.yaml` — registered `model/capability`,
  `capability-catalog/itc-cap`, `assimilation/it-capability-canon`,
  `practice/intake-and-assimilation` (65 artifacts, up from 61).
- `infospace/infospace.yaml` — Capability Model added to disciplines.
- Regenerated agent briefs, retrieval indexes, and views.
- `tests/` — artifact and model counts updated to match the registered canon.
- `workplans/index.yaml` — registered `ITC-WP-0014`, and `ITC-WP-0013` which was
  missing from the registry.

### Validation

`make validate` passes with 0 errors and 0 warnings (65 artifacts, 286
relationships, 0 consistency cycles, coverage 1.0, redundancy 0.0).
`make test` passes (22 tests).

---

## 0.1.0-scaffold

Seed kernel: kernel documents, eleven domain models, three standards, the
infospace scaffold, service surface (CLI / JSON / API), generated views and
agent briefs. See `workplans/` ITC-WP-0001 through ITC-WP-0012 for the history.