tegwick
f2d216af53
§10.3 now accepts a consumer record that validates against the live catalog; resource-control's backup restatement is that proof. ITC-GOV gains EvidenceBasis in tiers (invoiced and measured are peers) and ITC-CAP requires it on every consumption row (CAP-R10).
234 lines
11 KiB
Markdown
234 lines
11 KiB
Markdown
# 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.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 are peers; 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.
|