feedback: resource-control ITC-CAP 0.2.0 restatement of platform-audit-storage

Consumer criterion 6 is met in their repo. Record PurposeFit evidence here;
do not copy operational facts.

feedback/2026-08-15-resource-control-cap-restatement.md

@@ -0,0 +1,121 @@
+---
+id: feedback/2026-08-15-resource-control-cap-restatement
+type: consumer-feedback
+status: reviewed
+date: "2026-08-15"
+consumer: resource-control
+consumer_domain: financials
+canon_version: "0.3.0"
+artifacts:
+  - model/capability
+related_demand:
+  - demand/CapabilityProvisionEconomics.md
+related_workplan:
+  - ITC-WP-0014
+spawned_demand: []
+spawned_workplan: []
+---
+
+# Feedback: ITC-CAP 0.2.0 restatement of platform-audit-storage
+
+**Consumer:** resource-control
+**Canon version used:** 0.3.0 / ITC-CAP 0.2.0
+**Artifacts exercised:** `model/capability` (`data.backup`, `data.object`,
+requirement targets/constraints, native-unit consumption, D-scale, evidence
+hooks)
+**Related demand:** `demand/CapabilityProvisionEconomics.md` (criterion 6)
+**Source record:** `resource-control` `data/capability/platform-audit-storage.json`
+(commit `13c2b82`). Validator reads this catalog live; 44 capability/basis
+tests pass; `make capability` reports the review below.
+
+Steward-written from the consumer's restatement and the review output of
+`tools/capability.py` against this repo's `capabilities.yaml`. Operational
+facts stay in resource-control; this file is PurposeFit evidence only.
+
+---
+
+## Consumer purpose
+
+Restate a real backup procurement — requirement, two provisions, maturity,
+four evidence hooks, and consumption — entirely in ITC-CAP 0.2.0 terms, so
+the canon has a joinable proof rather than a worked example.
+
+## Hits
+
+- **CAP-R9 requirement shape.** `data.backup` / profile `database` /
+  `minimum_maturity: D5` / targets `rpo` 5 min, `rto` 60 min, `retention`
+  30 days / constraint `geographical_separation not_in [host:railiance01,
+  provider:host-europe]`. The consumer calls the constraint "the single most
+  useful thing you added for us." It was prose before 0.2.0; it is now a
+  closed, catalog-checked assertion.
+- **Two provisions on one spine.** `resource:platform:audit-storage` provides
+  `data.object`; CNPG/Barman provides `data.backup` and depends on it. The
+  layering existed in their resource records and had no name.
+- **D-scale used honestly.** Requirement asks D5; provision is D4;
+  review status `below_requirement`. Reliability is declared in thresholds
+  and rests on one backup (48 s), one full restore (65 s, 30=30 rows), one
+  PITR (65 s), ~four hours of operation; `wal_archive_gap_minutes` is
+  declared and not emitted. The scale did the work it was designed for.
+- **Evidence hooks, complete on backup, incomplete on object.** All four
+  `data.backup` hooks are `measured` and point at the T05 evidence file.
+  `data.object` satisfies neither `object_integrity_tests` nor
+  `availability_metrics`; they report that rather than borrow the restore
+  drill.
+- **Unknown versus zero.** `H` on the backup provision is `unknown` (effort
+  was spent, no time record). `I` is `unknown` on both. `N` restore egress
+  is `unknown`. Storage is `measured` 0.0066 GB (8 objects, 6 604 031 B).
+  The old model would have silently dropped the unknowns.
+- **Live catalog join.** No catalog copy. Drift in either repo fails their
+  suite. This is CAP-R5 working as an interface.
+
+Review (abridged): `data.backup` below_requirement D5←D4, evidence complete;
+`data.object` evidence incomplete; alternatives grade `indicative`
+(evidenced_ratio 0.25).
+
+## Friction
+
+- **Class `P` used as a stand-in for another capability.** The backup
+  provision records credential custody as `P` / 1 unit / `supply: internal`,
+  with a note that `security.secrets` is a separate capability. `P` is
+  purchased platform, not "a capability this provision also uses." They
+  invented `depends_on_provision` for the object-store layering (right idea)
+  and then stuffed secrets into a resource-class row (wrong kind). The model
+  names capability-to-capability `depends_on` / `may_use`, but a *provision*
+  has no first-class way to name another provision or capability it consumes
+  except by overloading `consumes`.
+- **`typical_resource_classes` already gone.** Consumer notes we were right
+  to keep no hint, and right not to split finding C into its own workplan.
+
+## Gaps
+
+- **Evidence basis on a quantity.** Every value in their record carries an
+  ordered basis (`invoiced > measured > quoted > derived > projected >
+  estimated > assumed > unknown`), with "weakest input wins" on derivation.
+  It immediately graded their own Scaleway-over-Hetzner decision
+  `indicative`: the €29.14/month figure is assumed labour, not a
+  measurement. They have not filed this as demand. It sits naturally on
+  `CapabilityConsumption` but is broader than CAP — likely an ITC-GOV
+  Evidence concept that CAP imports. Same divergence argument as finding C.
+- **Provision-to-provision dependency.** `depends_on_provision` is their
+  local field. The catalog graph is capability-to-capability. A provision
+  record has no canon field for the binding they needed.
+
+## Drop candidates
+
+None.
+
+## Steward notes
+
+- Status `reviewed`. Demand criterion 6 is met *in the consumer repo*.
+  ITC-CAP §10 promotion requirement 3 still asks for a *canon Profile*.
+  This record is stronger evidence than a worked example and should count
+  toward promotion; whether that means revising §10.3 or adding a thin
+  in-repo example that cites the join (not the operational facts) is an
+  open steward decision.
+- Do not copy `platform-audit-storage.json` into this repository. The
+  catalog stays here; the provisioned facts stay there; the join is the id.
+- Evidence-basis: do not adopt from this report alone. Invite the demand
+  with the closed vocabulary and propagation rule, and decide ownership
+  (GOV Evidence vs CAP-only) when it arrives.
+- Provision dependency: note as pressure on ITC-CAP / T02 schema. Do not
+  invent the field until a demand or T02 needs it.

feedback/index.yaml

@@ -42,3 +42,33 @@ reports:
     related_workplan:
       - ITC-WP-0014
     spawned_canon_version: "0.3.0"
+  - id: feedback/2026-08-15-resource-control-cap-restatement
+    path: feedback/2026-08-15-resource-control-cap-restatement.md
+    date: "2026-08-15"
+    consumer: resource-control
+    consumer_domain: financials
+    status: reviewed
+    canon_version: "0.3.0"
+    artifacts:
+      - model/capability
+    hits:
+      - CapabilityRequirement
+      - geographical_separation
+      - data.backup
+      - data.object
+      - CapabilityMaturityLevel
+      - CapabilityEvidenceHook
+      - CapabilityConsumption
+      - CAP-R5
+      - CAP-R9
+    friction:
+      - CapabilityResourceClass P overloaded as capability dependency
+      - missing provision-to-provision depends_on
+    gaps:
+      - evidence basis on a quantity
+      - provision-to-provision dependency
+    drop_candidates: []
+    related_demand:
+      - demand/CapabilityProvisionEconomics.md
+    related_workplan:
+      - ITC-WP-0014