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

id	type	status	date	consumer	consumer_domain	canon_version	artifacts	related_demand	related_workplan	spawned_demand	spawned_workplan
feedback/2026-08-15-resource-control-cap-restatement	consumer-feedback	reviewed	2026-08-15	resource-control	financials	0.3.0	model/capability	demand/CapabilityProvisionEconomics.md	ITC-WP-0014

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.