info-tech-canon/CHANGELOG.md
tegwick b69b048dcb
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
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

180 lines
8.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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` T08T10 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 D0D7 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.