demand: evidence basis (ITC-GOV) and provision relationships (ITC-CAP)

Both requested by info-tech-canon in reply to the ITC-CAP restatement.

EvidenceBasis.md — proposed owner ITC-GOV, imported by CapabilityConsumption.
ITC-GOV §11.34 defines Evidence as an artifact kind; nothing says how a quantity
was obtained, so nothing bounds how far a conclusion computed from it may be
trusted. Closed scale invoiced/measured/quoted/derived/projected/estimated/
assumed/unknown; a derived value resolves to the weakest of its inputs; unknown
carries no quantity and names its owner; proxy_for orthogonal to strength;
decision grades tied to existing Assertion semantics. Strength is a tier, not a
total order — invoiced and measured are peers, which the consumer's first
implementation got wrong and has corrected. invoiced names a fin-hub fact
without originating one, per info-tech-canon's instruction. Placed in GOV rather
than CAP because the consumer already wants it on actuals and thresholds.

ProvisionRelationships.md — ITC-CAP §4.7/§7. A provision cannot say which
provision satisfies a dependency the catalog declares between capabilities. The
consumer recorded "uses security.secrets" as one unit of class P consumption,
which info-tech-canon correctly identified as the wrong kind. That is the
predictable result of the gap: consumes is the only structured list available,
so P drifts back into a dumping ground for "depends on something" and undoes the
narrowing finding C just achieved. Proposes uses_provisions reusing the existing
depends_on / may_use vocabulary, checkable against the capability graph.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

demand/ProvisionRelationships.md

@@ -0,0 +1,120 @@
+# Demand: Provision-to-provision relationships — which provision satisfies a dependency
+
+**Status:** inbound demand (un-reviewed)
+**Date:** 2026-08-15
+**Source:** resource-control (consumer), domain `financials`
+**Proposed owner:** `ITC-CAP` (§4.7 CapabilityProvision, §7 Relationships)
+**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`
+**Proposed workplan:** `ITC-WP-0014` follow-on
+
+---
+
+## 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.