coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/CHANGELOG.md
tegwick d453e17952
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Canon 0.6.0 freeze: ITC-CAP draft, AVT catalog, joinable review 
Finish ITC-WP-0013 (AttributeValueType under ITC-DATA) and ITC-WP-0014
T02/T03/T05/T06/T07. Capability contract schemas, live-catalog review
CLI, landscape/kernel-map pointers. Sit on this version.
2026-08-15 19:42:30 +02:00

14 KiB
Raw Permalink 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.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.