# 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:

```yaml
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.