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.6.0 — 2026-08-15

### Frozen — ITC-CAP draft; AttributeValueType catalog; joinable review

**Change.** Canon 0.6.0 is the freeze cut.

- **ITC-CAP** promoted from `proposed` to `draft`. Contract schemas
  published: `capability.schema.yaml` (catalog) and
  `capability-record.schema.yaml` (requirement/provision records).
  `make validate` enforces CAP-R8 on the catalog.
- **Capability-review surface:** `info-tech-canon capability-review PATH`
  and `GET /capability-review?path=` join a consumer record to the live
  catalog (OQ-6 / ITC-WP-0014 T06).
- **Mappings:** `infospace/mappings/capability-anchors.yaml` formalizes
  the assimilation mappings (T03).
- **Landscape §11.4** and **Kernel Map §4.14** now point at ITC-CAP (T05).
- **AttributeValueType** catalog under ITC-DATA
  (`models/data/attribute-value-types.yaml`) from
  `demand/AttributeValueTypes.md` (ITC-WP-0013). citation-evidence
  alignment note published.

ITC-WP-0013 and ITC-WP-0014 are finished. T04 (small-saas illustration)
remains optional and does not block the freeze.

**Rationale.** One consumer cycle has refined the capability model; a
second consumer needed a closed capture-type catalog. Further shape
change of ITC-CAP needs a new minor. 0.6.0 is the version to sit on.

**Breaking:** no capability id or AttributeValueType id invented as a
break. New catalogs and schemas only.

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

---

## 0.5.0 — 2026-08-15

### Added — Provision-to-provision relationships (`uses_provisions`)

**Change.** A `CapabilityProvision` may name the provisions it relies on
under `uses_provisions`. Each entry is a catalog capability, a consumer
landscape `provider` reference, and a `relation` of `depends_on` or
`may_use` — the existing capability-to-capability vocabulary, not a new
one. A `depends_on` entry MUST be declared between those capabilities in
the catalog; a `may_use` entry SHOULD. Using another capability is not
consuming class `P` (CAP-R11).

`data.backup` gains catalog `may_use: security.secrets`, from the
resource-control restatement. Maturity is not derived or capped across
the dependency.

EvidenceBasis tiers are refined in the same cut: `invoiced` and
`measured` remain peers (`observed`); `quoted` sits below them for
propagation and still counts as evidenced for decision grades. The
consumer found that a strict list order made an invoice outrank a
measurement.

**Rationale.** The catalog can say `data.backup depends_on data.object`;
a provision could not say *which* object provision satisfies that for
it. The leftover was a `consumes:P` row for OpenBao credential custody —
the wrong kind, and the start of `P` widening again after finding C
narrowed it. Filed as `demand/ProvisionRelationships.md`.

**Breaking:** no capability id changed. New optional field on the
still-proposed provision record. Consumers who wrote `relation: uses`
should spell it `may_use`.

**Records.** `ADHOC-2026-08-15` T03; demand accepted.

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

---

## 0.4.0 — 2026-08-15

### Changed — Joinable consumer proof counts for ITC-CAP promotion

**Change.** ITC-CAP §10.3 no longer requires a canon Profile as the only
form of "a real capability requirement set with evidence." A consumer
record that validates against the live catalog and is cited from
`feedback/` is a proof. Operational facts stay in the consumer repo; the
join is the capability id.

**Met by** resource-control `data/capability/platform-audit-storage.json`
(commit `13c2b82`), cited in
`feedback/2026-08-15-resource-control-cap-restatement.md`. Requirement
`data.backup` D5 is `below_requirement` at provision D4; all four backup
hooks are measured. ITC-WP-0014 T11 done; T04 (small-saas illustration)
no longer blocks T07.

**Rationale.** A fictional in-repo example is a weaker proof than a
joinable provision that already fails or passes against this catalog.

**Breaking:** no.

### Added — EvidenceBasis (ITC-GOV), required on CapabilityConsumption

**Change.** ITC-GOV gains `EvidenceBasis`: a closed vocabulary for how a
quantity was obtained, in **tiers** rather than a total order
(`evidenced`: invoiced / measured / quoted; then `projected`; then
`judgement`: estimated / assumed; then `unknown`). A derived value
resolves to the weakest *tier* among its inputs. Unknown-is-not-zero.
Optional `proxy_for` / `observed_at`. Decision grades (`evidenced` /
`projected` / `indicative` / `insufficient`). Catalog:
`infospace/models/governance/evidence-basis.yaml`. ITC-CAP 0.3.0 imports
it; CAP-R10 requires `basis` on every consumption row.

**Rationale.** Native units without a basis still let an assumed hour and
a measured gigabyte sit in one list as the same kind of knowledge. The
consumer's first application graded a €29.14/month provider comparison
`indicative`. A private scale would diverge the moment a second
repository reports provision economics — the same argument accepted for
class `H`.

**Ownership.** ITC-GOV Evidence, not a CAP-only dialect. `invoiced` names
a fin-hub booked fact; this canon does not originate booked costs. Not
the OQ-3 state qualifier.

**Breaking:** no capability id changed. New required field on consumption
records of the still-proposed capability model.

**Records.** `demand/EvidenceBasis.md`; `ITC-WP-0015` finished.

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

---

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