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.
This commit is contained in:
parent
40accbbf3d
commit
0b28ec570e
12 changed files with 156 additions and 35 deletions
36
CHANGELOG.md
36
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:
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -75,3 +75,4 @@ reports:
|
|||
related_workplan:
|
||||
- ITC-WP-0014
|
||||
- ITC-WP-0015
|
||||
- ADHOC-2026-08-15
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue