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.