coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/CHANGELOG.md
tegwick b69b048dcb
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Canon 0.3.0: capability provision economics (ITC-CAP 0.2.0) 
Accept resource-control demand: move resource classes onto provisions,
let requirements carry targets and constraints, add human-effort class H
with native-unit consumption. Model stays proposed.
2026-08-15 18:19:30 +02:00

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