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.

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.

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

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:
 

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