From 0b28ec570e6b18e7ab538c772f86f100465b1155 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 15 Aug 2026 19:23:44 +0200 Subject: [PATCH] Canon 0.5.0: uses_provisions so P stays purchased platform A provision can name which other provision satisfies a catalog dependency. Relation vocabulary is depends_on / may_use only. Quoted sits below the invoiced/measured peer pair for propagation. --- CHANGELOG.md | 36 ++++++++++- canon.yaml | 6 +- demand/ProvisionRelationships.md | 6 +- ...-08-15-resource-control-cap-restatement.md | 7 ++- feedback/index.yaml | 1 + .../InfoTechCanonCapabilityModel.md | 61 +++++++++++++++++-- infospace/models/capability/capabilities.yaml | 5 +- .../InfoTechCanonGovernanceModel.md | 5 +- .../models/governance/evidence-basis.yaml | 32 +++++++--- workplans/ADHOC-2026-08-15.md | 20 +++++- ...-WP-0014-capability-model-consolidation.md | 9 +-- workplans/index.yaml | 3 +- 12 files changed, 156 insertions(+), 35 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index f8ea30f..82cbdb4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,38 @@ semantics. --- +## 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. + +**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 @@ -41,8 +73,8 @@ joinable provision that already fails or passes against this catalog. **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 +(`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: diff --git a/canon.yaml b/canon.yaml index ce8ff61..11331c2 100644 --- a/canon.yaml +++ b/canon.yaml @@ -1,7 +1,7 @@ repository: info-tech-canon title: InfoTechCanon status: service-baseline -version: 0.4.0 +version: 0.5.0 description: > An evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. @@ -93,7 +93,7 @@ models: title: InfoTechCanonCapabilityModel path: infospace/models/capability/InfoTechCanonCapabilityModel.md status: proposed - version: 0.3.0 + version: 0.4.0 catalog: infospace/models/capability/capabilities.yaml provenance: assimilation: assimilation/it-capability-canon @@ -181,4 +181,4 @@ next_actions: - implement ITC-WP-0003 validation and generated views - implement ITC-WP-0004 small-saas profile proof - explore ITC-WP-0006 PURPOSES model extension - - publish ITC-WP-0014 T02 capability.schema.yaml encoding ITC-CAP 0.3.0 (next ITC-CAP promotion gate; §10.3 met by resource-control join) + - publish ITC-WP-0014 T02 capability.schema.yaml encoding ITC-CAP 0.4.0 (next ITC-CAP promotion gate; §10.3 met; uses_provisions and CAP-R10/R11 in the contract) diff --git a/demand/ProvisionRelationships.md b/demand/ProvisionRelationships.md index 0199986..8167840 100644 --- a/demand/ProvisionRelationships.md +++ b/demand/ProvisionRelationships.md @@ -1,12 +1,12 @@ # Demand: Provision-to-provision relationships — which provision satisfies a dependency -**Status:** inbound demand (un-reviewed) +**Status:** accepted (canon 0.5.0 / ITC-CAP 0.4.0) **Date:** 2026-08-15 **Source:** resource-control (consumer), domain `financials` -**Proposed owner:** `ITC-CAP` (§4.7 CapabilityProvision, §7 Relationships) +**Owner:** `ITC-CAP` (§4.7 CapabilityProvision, §7 Relationships, CAP-R11) **Requested by:** info-tech-canon, in reply to the ITC-CAP restatement, 2026-08-15 **Consumer evidence:** `resource-control/data/capability/platform-audit-storage.json` -**Proposed workplan:** `ITC-WP-0014` follow-on +**Workplan:** `ADHOC-2026-08-15` T03 --- diff --git a/feedback/2026-08-15-resource-control-cap-restatement.md b/feedback/2026-08-15-resource-control-cap-restatement.md index 5991a44..43fbded 100644 --- a/feedback/2026-08-15-resource-control-cap-restatement.md +++ b/feedback/2026-08-15-resource-control-cap-restatement.md @@ -18,6 +18,7 @@ spawned_demand: - demand/EvidenceBasis.md spawned_workplan: - ITC-WP-0015 + - ADHOC-2026-08-15 --- # Feedback: ITC-CAP 0.2.0 restatement of platform-audit-storage @@ -116,5 +117,7 @@ None. resource-control. - Evidence-basis accepted as `demand/EvidenceBasis.md` and published as ITC-GOV `EvidenceBasis` / CAP-R10 (ITC-WP-0015, canon 0.4.0). -- Provision-to-provision dependency remains a note, not a field. Do not - invent it until a demand or T02 needs it. +- Provision-to-provision dependency accepted as + `demand/ProvisionRelationships.md` and published as `uses_provisions` + / CAP-R11 (ADHOC-2026-08-15 T03, canon 0.5.0). Canon spelling is + `may_use`, not `uses`. Maturity is not capped across the dependency. diff --git a/feedback/index.yaml b/feedback/index.yaml index 2b1ce31..5b49526 100644 --- a/feedback/index.yaml +++ b/feedback/index.yaml @@ -75,3 +75,4 @@ reports: related_workplan: - ITC-WP-0014 - ITC-WP-0015 + - ADHOC-2026-08-15 diff --git a/infospace/models/capability/InfoTechCanonCapabilityModel.md b/infospace/models/capability/InfoTechCanonCapabilityModel.md index bdf31f2..333e34e 100644 --- a/infospace/models/capability/InfoTechCanonCapabilityModel.md +++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md @@ -7,7 +7,7 @@ standard_family: InfoTechCanon repository_context: info-tech-canon recommended_path: models/capability/InfoTechCanonCapabilityModel.md status: proposed -version: 0.3.0 +version: 0.4.0 source_version: "0.1" source_body: Information Technology Capability Canon (ITCC) source_file: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md @@ -55,7 +55,7 @@ updated_at: 2026-08-15 **Short Name:** `ITC-CAP` **Document Status:** Proposed (assimilated, not yet promoted) -**Version:** 0.3.0 +**Version:** 0.4.0 **Document Type:** InfoTechCanon Domain Model **Machine-readable catalog:** `models/capability/capabilities.yaml` **Provenance:** adapted from ITCC v0.1 — see `assimilation/it-capability-canon` @@ -249,6 +249,13 @@ provision: profile: database environment: production maturity: D4 + uses_provisions: + - capability: data.object + provider: object.scaleway.nl-ams + relation: depends_on + - capability: security.secrets + provider: openbao.reef-railiance + relation: may_use consumes: - class: S quantity: {value: 50, unit: GB} @@ -280,6 +287,32 @@ MUST NOT carry a quantity. A row with any other basis MUST carry a quantity. A provision MAY override a class's default `supply` and `capacity_behaviour` (for example contracted operator time recorded as `H` with `supply: external`). +A provision MAY name the provisions it relies on under `uses_provisions`. +That list is not consumption. `consumes` records resource classes in native +units; `uses_provisions` records which other provision supplies an ability. + +```yaml +uses_provisions: + - capability: data.object # catalog id + provider: object.scaleway.nl-ams # consumer landscape reference + relation: depends_on # or may_use +``` + +Rules: + +- `capability` MUST be a catalog id. +- `provider` is a consumer landscape reference, not a canon identifier + (ITC-LAND owns provider identity). +- `relation` MUST be `depends_on` or `may_use` — the same vocabulary as + capability-to-capability relationships. There is no third spelling + (`uses` is `may_use`). +- A `depends_on` entry MUST match a `depends_on` declared between those + two capabilities in the catalog. +- A `may_use` entry SHOULD match a catalog `may_use`. A specific + provision MAY record a use the abstract capability does not declare. +- The list does not cap maturity. Whether a provision's maturity is + bounded by what it depends on is a separate question. + ## 4.8 CapabilityMaturityLevel | Level | State | Meaning | @@ -437,6 +470,12 @@ weakest *tier* among those inputs (ITC-GOV). Members of the same tier do not rank against each other. Evidence items on a provision SHOULD declare a basis on the same scale. +**CAP-R11** A provision that relies on another provision MUST record that +fact under `uses_provisions`, not as a `consumes` row. `relation` MUST be +`depends_on` or `may_use`. A `depends_on` entry MUST be declared between +those capabilities in the catalog. Using another capability is not +consuming class `P`. + --- # 6. Admission Rules @@ -475,6 +514,13 @@ Landscape and consumer to capability: | `implements` | A technology realizes all or part of a provider | | `consumes` | A provision consumes resource classes in native units | +Provision to provision (`uses_provisions`): + +| Type | Meaning | +|---|---| +| `depends_on` | This provision requires that provision to operate; the pair MUST be a catalog `depends_on` | +| `may_use` | This provision uses that provision without a catalog-hard dependency | + Traversal from need to consumption: ```text @@ -544,8 +590,9 @@ This model enters the canon at status `proposed`. Promotion requires: - a canon Profile containing such a set, or - a consumer record that validates against the live catalog (capability ids, profiles, quality dimensions, evidence hooks, resource classes, - native units, and constraint predicates) and is cited from this - repository as PurposeFit evidence under `feedback/`. + native units, constraint predicates, and `uses_provisions` relations) + and is cited from this repository as PurposeFit evidence under + `feedback/`. Operational facts stay in the consumer repo. The join is the capability id (CAP-R5). A fictional in-repo example is a weaker proof than a @@ -582,3 +629,9 @@ records use native units. See the decision record in Version 0.3.0 (canon 0.4.0) accepts a consumer record that validates against the live catalog as a promotion proof (§10.3), and requires EvidenceBasis on every consumption row (CAP-R10). EvidenceBasis is owned by ITC-GOV. + +Version 0.4.0 (canon 0.5.0) adds `uses_provisions` so a provision can name +which other provision satisfies a catalog dependency (CAP-R11). Using +another capability is not consuming class `P`. `data.backup` gains catalog +`may_use: security.secrets` from consumer evidence. Maturity is not capped +across the dependency. diff --git a/infospace/models/capability/capabilities.yaml b/infospace/models/capability/capabilities.yaml index 8850edf..fbb6f55 100644 --- a/infospace/models/capability/capabilities.yaml +++ b/infospace/models/capability/capabilities.yaml @@ -12,9 +12,9 @@ canon: name: InfoTechCanon Capability Model — Capability Catalog short_name: ITC-CAP artifact_id: model/capability - version: 0.3.0 + version: 0.4.0 status: proposed - canon_version: 0.4.0 + canon_version: 0.5.0 purpose: Canonical, implementation-independent catalog of the abilities an information system may require or provide. normative_document: models/capability/InfoTechCanonCapabilityModel.md @@ -300,6 +300,7 @@ domains: may_use: - runtime.scheduling - operations.observability + - security.secrets - id: data.archive name: Archive & Retention purpose: Preserve information for long-term retention under defined lifecycle, integrity, and retrieval diff --git a/infospace/models/governance/InfoTechCanonGovernanceModel.md b/infospace/models/governance/InfoTechCanonGovernanceModel.md index 046947e..ee572b1 100644 --- a/infospace/models/governance/InfoTechCanonGovernanceModel.md +++ b/infospace/models/governance/InfoTechCanonGovernanceModel.md @@ -1078,8 +1078,9 @@ assumed hourly rate are both numbers; they are not both knowledge. The closed vocabulary is held in `models/governance/evidence-basis.yaml` and is not restated as a second list here. Strength is a **tier**, not a total -order: `invoiced` and `measured` are peers. `invoiced`, `measured`, and -`quoted` are **evidenced**. Everything below that tier is inference. +order: `invoiced` and `measured` are peers (`observed`). `quoted` sits +below that pair for propagation and still counts as **evidenced** for +decision grades. Everything below `quoted` is inference. Normative rules: diff --git a/infospace/models/governance/evidence-basis.yaml b/infospace/models/governance/evidence-basis.yaml index ddad5ec..b6201a9 100644 --- a/infospace/models/governance/evidence-basis.yaml +++ b/infospace/models/governance/evidence-basis.yaml @@ -52,24 +52,35 @@ bases: description: No value exists. MUST NOT carry a quantity. MUST name the gap and its owner. # Strongest to weakest. Members of one tier are peers: weakest() among only -# invoiced and measured MUST NOT imply a ranking. +# invoiced and measured MUST NOT imply a ranking. quoted is evidenced for +# decision grades but sits below that peer pair for propagation. tiers: - - id: evidenced + - id: observed rank: 0 - members: [invoiced, measured, quoted] - note: invoiced and measured are peers. quoted is evidenced for grading but - does not outrank or sit below a measurement of a different quantity. - - id: projected + members: [invoiced, measured] + evidenced: true + note: peers. An invoice is authoritative for a payment; a measurement is + authoritative for a quantity. Neither outranks the other. + - id: quoted rank: 1 - members: [projected] - - id: judgement + members: [quoted] + evidenced: true + note: stated by a counterparty. Weaker than observed for propagation; + still evidenced for decision grades. + - id: projected rank: 2 + members: [projected] + evidenced: false + - id: judgement + rank: 3 members: [estimated, assumed] + evidenced: false note: both yield decision grade indicative; they are not ranked against each other. - id: unknown - rank: 3 + rank: 4 members: [unknown] + evidenced: false rules: - id: weakest-input-wins statement: A derived value is only as strong as its weakest input, compared @@ -96,7 +107,8 @@ qualifiers: basis. A value may be measured and still be a single noisy sample. decision_grades: - id: evidenced - when: Every load-bearing value resolves to the evidenced tier. + when: Every load-bearing value resolves to an evidenced tier + (observed or quoted). - id: projected when: The weakest resolved tier is projected. - id: indicative diff --git a/workplans/ADHOC-2026-08-15.md b/workplans/ADHOC-2026-08-15.md index 7fda1a7..b5843dd 100644 --- a/workplans/ADHOC-2026-08-15.md +++ b/workplans/ADHOC-2026-08-15.md @@ -1,7 +1,7 @@ --- id: ADHOC-2026-08-15 type: workplan -title: "Ad hoc: consumer feedback directory" +title: "Ad hoc: feedback directory and provision relationships" domain: infotech topic_slug: canon repo: info-tech-canon @@ -13,6 +13,7 @@ owner: grok spec_refs: - feedback/README.md - demand/CapabilityProvisionEconomics.md + - demand/ProvisionRelationships.md state_hub_workstream_id: "dd403bf7-b84d-49af-b914-fb5b0bd1b88a" --- @@ -22,7 +23,9 @@ state_hub_workstream_id: "dd403bf7-b84d-49af-b914-fb5b0bd1b88a" Give the canon a durable place to collect consumer reports on whether existing concepts hit, friction, gap, or are drop candidates — without -collapsing that evidence into `demand/` or `incoming/`. +collapsing that evidence into `demand/` or `incoming/`. Land the +provision-to-provision relationship the resource-control restatement +needed, so class `P` does not become a dumping ground again. ## Tasks @@ -51,3 +54,16 @@ state_hub_task_id: "95599215-b461-4893-8736-d249030bef34" Write `feedback/2026-08-15-resource-control-capability-provision.md` from the 2026-08-15 backup-cycle mapping. Hits stay here; the three defects remain `demand/CapabilityProvisionEconomics.md`. + +### T03 — Provision-to-provision relationships + +```task +id: ADHOC-2026-08-15-T03 +status: done +priority: high +``` + +Accept `demand/ProvisionRelationships.md`. Add `uses_provisions` on +`CapabilityProvision` with `depends_on` / `may_use` only (CAP-R11). Add +`security.secrets` to `data.backup` `may_use`. Do not cap maturity across +the dependency. Canon 0.5.0 / ITC-CAP 0.4.0. diff --git a/workplans/ITC-WP-0014-capability-model-consolidation.md b/workplans/ITC-WP-0014-capability-model-consolidation.md index ae34905..15a6f6e 100644 --- a/workplans/ITC-WP-0014-capability-model-consolidation.md +++ b/workplans/ITC-WP-0014-capability-model-consolidation.md @@ -70,11 +70,12 @@ state_hub_task_id: "1ed8d07a-34ee-4ad4-8e4a-03a513c14836" Add the capability contract schema under `infospace/schemas/`, register it in `infospace/infospace.yaml`, and validate `capabilities.yaml` against it. -Encode ITC-CAP 0.3.0: no `typical_resource_classes` on contracts; resource +Encode ITC-CAP 0.4.0: no `typical_resource_classes` on contracts; resource classes carry `native_unit`, `supply`, and `capacity_behaviour`; consumption -rows require EvidenceBasis (CAP-R10); requirement and provision record -shapes live in the model prose until a companion requirement/provision -schema is justified. §10.3 is already met by the resource-control join. +rows require EvidenceBasis (CAP-R10); provisions may declare +`uses_provisions` (CAP-R11); requirement and provision record shapes live +in the model prose until a companion requirement/provision schema is +justified. §10.3 is already met by the resource-control join. ### T03 — Formal mapping artifacts for each anchor diff --git a/workplans/index.yaml b/workplans/index.yaml index 64fdc70..750d0ef 100644 --- a/workplans/index.yaml +++ b/workplans/index.yaml @@ -209,7 +209,7 @@ workplans: - capability requirement/provision validation surface - id: ADHOC-2026-08-15 - title: "Ad hoc: consumer feedback directory" + title: "Ad hoc: feedback directory and provision relationships" status: finished priority: low path: workplans/ADHOC-2026-08-15.md @@ -217,6 +217,7 @@ workplans: produces: - feedback/ - first consumer utility report (resource-control / ITC-CAP) + - uses_provisions on CapabilityProvision (CAP-R11) - id: ITC-WP-0015 title: Evidence Basis catalog (Governance extension)