114 lines
5 KiB
Markdown
114 lines
5 KiB
Markdown
|
---
|
|||
|
|
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.
|