Add feedback/ for consumer reports on canon-concept utility

A third front door next to incoming/ and demand/: longitudinal PurposeFit
evidence, not a change request and not a canon artifact. Seeded with the
resource-control backup-cycle mapping.

feedback/2026-08-15-resource-control-capability-provision.md

@@ -0,0 +1,113 @@
+---
+id: feedback/2026-08-15-resource-control-capability-provision
+type: consumer-feedback
+status: acted-on
+date: "2026-08-15"
+consumer: resource-control
+consumer_domain: financials
+canon_version: "0.2.1"
+artifacts:
+  - model/capability
+related_demand:
+  - demand/CapabilityProvisionEconomics.md
+related_workplan:
+  - ITC-WP-0014
+spawned_demand:
+  - demand/CapabilityProvisionEconomics.md
+spawned_workplan:
+  - ITC-WP-0014
+---
+
+# Feedback: ITC-CAP on a completed backup procurement cycle
+
+**Consumer:** resource-control (domain `financials`)
+**Canon version used:** 0.2.1 / ITC-CAP 0.1.0
+**Artifacts exercised:** `model/capability` (`data.backup`, `data.object`,
+`security.secrets`, `runtime.scheduling`, `operations.recovery`, D-scale,
+resource classes)
+**Related demand:** `demand/CapabilityProvisionEconomics.md`
+
+Steward-written from the consumer's inbound demand and State Hub message of
+2026-08-15. The consumer completed RESOURCE-WP-0002 — provider selection,
+purchase, credential custody, proven restore and PITR, monthly observation,
+thresholds, and a decided optimization case — then mapped that work onto
+ITC-CAP. This report extracts the *utility* evidence. The three defects are
+demand, already accepted in canon 0.3.0.
+
+---
+
+## Consumer purpose
+
+Own portfolio identity, technical economics, allocation evidence, forecasts,
+and optimization cases for managed infrastructure. For this cycle: select and
+control a real backup resource, and say in canon terms what was required,
+what was provided, how mature it is, and what it consumes.
+
+## Hits
+
+- **`data.backup` catalog entry and its graph.** The work decomposes without
+  strain: object store provides `data.object`; CNPG/Barman provides
+  `data.backup` (profile `database`) which `depends_on` it; credentials are
+  `security.secrets`; schedule is `runtime.scheduling`; the restore drill is
+  evidence for both `data.backup` and `operations.recovery`.
+- **Evidence hooks on `data.backup`.** `successful_backup`,
+  `successful_restore_test`, `measured_rpo`, `measured_rto` matched, one for
+  one, evidence the consumer had already produced before encountering the
+  model. Independent convergence. First backup 48s; full restore 65s with
+  equal row counts; PITR 65s; measured RPO about 2s against a 5-minute
+  `archive_timeout`.
+- **D0–D7 provision maturity.** The consumer assessed their own provision as
+  **D4, not D5**: reliability is declared in thresholds but rests on one
+  backup and four hours of evidence. The scale produced an honest answer
+  instead of a flattering one.
+- **CAP-R2 / CAP-R5 as a design criterion.** The consumer considered splitting
+  ITC-CAP into supply-side and demand-side canons and rejected it: both sides
+  agree about what exists, so two record types on one spine are enough, and
+  splitting would destroy joinable ids. That reasoning is reusable.
+
+## Friction
+
+- **`typical_resource_classes` on the contract.** Contradicted §4.11 and
+  carried almost no information (29 of 41 entries identical). Invited cost
+  structuring on the abstract capability. Filed as demand finding A; removed
+  in ITC-CAP 0.2.0 / canon 0.3.0.
+- **`CapabilityRequirement` was id + `minimum_maturity` only.** The real
+  backup need was profile `database`, RPO ≤ 5 min, retention 30 days, and
+  *not* in the failure domain of the protected host. `isolation` and
+  `geographical_separation` were already named dimensions; the requirement
+  could not use them. Filed as demand finding B; requirement shape enriched
+  in ITC-CAP 0.2.0.
+- **Resource-class set had no human-effort class.** Provider selection
+  inverted on labour (Hetzner cheaper on infrastructure, worse overall by
+  €29.14/month on operator hours). Self-managed option failed on a 4 h/month
+  ceiling, not on money. Hours were often known when currency was not.
+  Intelligence was modelled as one more purchased input. Filed as demand
+  finding C; class `H`, native units, and `I` as substitute landed in
+  ITC-CAP 0.2.0.
+
+## Gaps
+
+The three findings above. No further unnamed concept was claimed. Token
+efficiency was offered as forward-looking rationale (the consumer does not
+yet measure tokens in its portfolio model); `intelligence_intensity` was
+added as a quality dimension so the gap has a home when they do.
+
+## Drop candidates
+
+None claimed. Removing `typical_resource_classes` was a field deletion, not
+a concept retirement. The consumer did not propose dropping any capability
+id.
+
+## Steward notes
+
+- Status `acted-on`: findings A–C accepted and published in canon 0.3.0.
+  Decision record in `infospace/assimilation/it-capability-canon/ASSIMILATION.md`.
+- This report is evidence that ITC-CAP's catalog, evidence hooks, and D-scale
+  already have a real consumer. That is relevant to §10 promotion
+  requirement 3; the consumer has offered to restate the backup case entirely
+  in the 0.2.0 shape (requirement, provision, D4, four hooks, native-unit
+  consumption).
+- Do not generalize from one cycle to "the other 35 capabilities are unused."
+  This cycle only exercised backup-adjacent ids.
+- Do not treat this file as the work item. Changes go through the demand and
+  ITC-WP-0014.