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