info-tech-canon/feedback/2026-08-15-resource-control-capability-provision.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-capability-provision	consumer-feedback	acted-on	2026-08-15	resource-control	financials	0.2.1	model/capability	demand/CapabilityProvisionEconomics.md	ITC-WP-0014	demand/CapabilityProvisionEconomics.md	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.