tegwick
0b28ec570e
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.
120 lines
4.9 KiB
Markdown
120 lines
4.9 KiB
Markdown
# 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.
|