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