info-tech-canon/demand/ProvisionRelationships.md

Demand: Provision-to-provision relationships — which provision satisfies a dependency

Status: accepted (canon 0.5.0 / ITC-CAP 0.4.0) Date: 2026-08-15 Source: resource-control (consumer), domain financials 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 Workplan: ADHOC-2026-08-15 T03

---

Demand signal

ITC-CAP §7 declares relationships at two levels:

• capability to capability — depends_on, may_use, composes;
• landscape or consumer to capability — requires, provides, implements, consumes.

There is no relationship between provisions. The catalog can say that data.backup depends_on data.object, but a provision cannot say which provision of data.object satisfies that dependency for it.

That matters because the dependency is where the operational and economic facts live. data.backup depends_on data.object is a statement about abilities. "This backup provision depends on the Scaleway bucket in nl-ams, and would be a different risk and a different cost against a different one" is a statement about the world, and it is the one a consumer needs.

How the gap surfaced

info-tech-canon found it while reviewing the consumer's restatement, and named it precisely:

The P row for credential custody is the wrong kind. P is purchased platform. What you needed is a provision naming that it uses security.secrets / depends on another provision. depends_on_provision is the right idea for the object-store layering; stuffing secrets into consumes:P is the leftover.

That is an accurate diagnosis of a consumer error. The backup provision uses security.secrets — an OpenBao ClusterSecretStore and a synced ExternalSecret — and the consumer recorded it as one unit of class P consumption. Nothing is purchased there. Using another capability is not consuming platform capacity, and the record said it was because the model offered no other place to put it.

The consumer has removed that row. The relationship is currently held in a field marked explicitly as not canon, pending this demand.

Why it will recur

The mis-recording is the predictable result of the gap, not a one-off slip. Any provision that uses another capability without buying capacity — secrets, scheduling, observability, identity — has the same problem, and consumes is the only structured list available. Left unaddressed, P slowly becomes a dumping ground for "depends on something", and the class that finding C just narrowed to purchased platform services widens again by usage.

---

Proposed shape

A provision may declare which provisions it relies on:

provision:
  provider: backup.barman.prod
  capability: data.backup
  uses_provisions:
    - capability: data.object
      provider: object.scaleway.nl-ams
      relation: depends_on
    - capability: security.secrets
      provider: openbao.reef-railiance
      relation: uses

• relation reuses the existing capability-to-capability vocabulary — depends_on and may_use (or uses as its provision-level spelling). No new relationship semantics are introduced.
• A depends_on entry SHOULD correspond to a depends_on declared between the two capabilities in the catalog; a may_use/uses entry SHOULD correspond to a declared may_use. This makes the provision graph checkable against the capability graph rather than free-form.
• Naming the provider makes maturity traversable: a provision cannot honestly claim reliability above that of a provision it depends on, which is a rule the canon may or may not want to state.

What it is not

It is not consumption. consumes records resource classes drawn in native units; uses_provisions records which other provision supplies an ability. The distinction is exactly the one that CAP-R8 and finding C established for classes, applied one level up.

---

Success criteria

1. A provision can name the provisions it depends on or uses, with a relation drawn from the existing capability-to-capability vocabulary.
2. The provision graph is checkable against the capability graph.
3. Using another capability is expressible without a consumption row, so P stays purchased platform capacity.
4. resource-control can drop the proposed_extensions marker from data/capability/platform-audit-storage.json and record both the object-store dependency and the secrets usage in canon terms.

---

Non-goals

• Provider or service identity semantics — ITC-LAND owns those; this names them by reference.
• A deployment or topology model.
• Automatic maturity derivation across a dependency chain. Whether a provision's maturity is capped by its dependencies is a separate question, raised here only because this relationship is what would make it askable.