coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/CHANGELOG.md
tegwick 28d5824362
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Assimilate ITCC v0.1 as Capability Model; canon 0.2.0 
Define the intake and assimilation practice (incoming/ drop zone -> frozen
source snapshot -> Minimal Assimilation Profile -> disposition gate -> canon
transformation -> versioned change notes) and run it on the first inputs.

- infospace/assimilation/intake-and-assimilation-practice.md, incoming/README.md
- assimilation/it-capability-canon: frozen source, comparison matrix, 26
  mappings, 8 proposed changes, 7 open questions, decision record (adapt)
- new model ITC-CAP with 41-capability machine-readable catalog, anchored to
  owning canon models; CILM rejected, Profile renamed, Provision made explicit
- registered in canon.yaml / artifacts index / infospace.yaml; regenerated
  briefs, indexes, views; canon version 0.1.0-scaffold -> 0.2.0 + CHANGELOG
- ITC-WP-0014 for promotion work; ITC-WP-0013 added to the workplan registry

make validate: ok (65 artifacts, 0 errors/warnings). make test: 22 passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 20:54:32 +02:00

4.6 KiB
Raw Blame History

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