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