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