tegwick
686bfb5a9d
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.
113 lines
5 KiB
Markdown
113 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.
|