coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/feedback/2026-08-15-resource-control-cap-restatement.md
tegwick 0b28ec570e
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Canon 0.5.0: uses_provisions so P stays purchased platform 
A provision can name which other provision satisfies a catalog
dependency. Relation vocabulary is depends_on / may_use only.
Quoted sits below the invoiced/measured peer pair for propagation.
2026-08-15 19:23:44 +02:00

5.5 KiB
Raw Blame History

id type status date consumer consumer_domain canon_version artifacts related_demand related_workplan spawned_demand spawned_workplan
feedback/2026-08-15-resource-control-cap-restatement consumer-feedback acted-on 2026-08-15 resource-control financials 0.3.0
model/capability
demand/CapabilityProvisionEconomics.md
demand/EvidenceBasis.md
ITC-WP-0014
ITC-WP-0015
demand/EvidenceBasis.md
ITC-WP-0015
ADHOC-2026-08-15

Feedback: ITC-CAP 0.2.0 restatement of platform-audit-storage

Consumer: resource-control Canon version used: 0.3.0 / ITC-CAP 0.2.0 Artifacts exercised: model/capability (data.backup, data.object, requirement targets/constraints, native-unit consumption, D-scale, evidence hooks) Related demand: demand/CapabilityProvisionEconomics.md (criterion 6) Source record: resource-control data/capability/platform-audit-storage.json (commit 13c2b82). Validator reads this catalog live; 44 capability/basis tests pass; make capability reports the review below.

Steward-written from the consumer's restatement and the review output of tools/capability.py against this repo's capabilities.yaml. Operational facts stay in resource-control; this file is PurposeFit evidence only.

Consumer purpose

Restate a real backup procurement — requirement, two provisions, maturity, four evidence hooks, and consumption — entirely in ITC-CAP 0.2.0 terms, so the canon has a joinable proof rather than a worked example.

Hits

  • CAP-R9 requirement shape. data.backup / profile database / minimum_maturity: D5 / targets rpo 5 min, rto 60 min, retention 30 days / constraint geographical_separation not_in [host:railiance01, provider:host-europe]. The consumer calls the constraint "the single most useful thing you added for us." It was prose before 0.2.0; it is now a closed, catalog-checked assertion.
  • Two provisions on one spine. resource:platform:audit-storage provides data.object; CNPG/Barman provides data.backup and depends on it. The layering existed in their resource records and had no name.
  • D-scale used honestly. Requirement asks D5; provision is D4; review status below_requirement. Reliability is declared in thresholds and rests on one backup (48 s), one full restore (65 s, 30=30 rows), one PITR (65 s), ~four hours of operation; wal_archive_gap_minutes is declared and not emitted. The scale did the work it was designed for.
  • Evidence hooks, complete on backup, incomplete on object. All four data.backup hooks are measured and point at the T05 evidence file. data.object satisfies neither object_integrity_tests nor availability_metrics; they report that rather than borrow the restore drill.
  • Unknown versus zero. H on the backup provision is unknown (effort was spent, no time record). I is unknown on both. N restore egress is unknown. Storage is measured 0.0066 GB (8 objects, 6 604 031 B). The old model would have silently dropped the unknowns.
  • Live catalog join. No catalog copy. Drift in either repo fails their suite. This is CAP-R5 working as an interface.

Review (abridged): data.backup below_requirement D5←D4, evidence complete; data.object evidence incomplete; alternatives grade indicative (evidenced_ratio 0.25).

Friction

  • Class P used as a stand-in for another capability. The backup provision records credential custody as P / 1 unit / supply: internal, with a note that security.secrets is a separate capability. P is purchased platform, not "a capability this provision also uses." They invented depends_on_provision for the object-store layering (right idea) and then stuffed secrets into a resource-class row (wrong kind). The model names capability-to-capability depends_on / may_use, but a provision has no first-class way to name another provision or capability it consumes except by overloading consumes.
  • typical_resource_classes already gone. Consumer notes we were right to keep no hint, and right not to split finding C into its own workplan.

Gaps

  • Evidence basis on a quantity. Every value in their record carries an ordered basis (invoiced > measured > quoted > derived > projected > estimated > assumed > unknown), with "weakest input wins" on derivation. It immediately graded their own Scaleway-over-Hetzner decision indicative: the €29.14/month figure is assumed labour, not a measurement. They have not filed this as demand. It sits naturally on CapabilityConsumption but is broader than CAP — likely an ITC-GOV Evidence concept that CAP imports. Same divergence argument as finding C.
  • Provision-to-provision dependency. depends_on_provision is their local field. The catalog graph is capability-to-capability. A provision record has no canon field for the binding they needed.

Drop candidates

None.

Steward notes

  • Status acted-on. Demand criterion 6 is met in the consumer repo. ITC-CAP §10.3 was revised in canon 0.4.0: this record is the joinable promotion proof (ITC-WP-0014 T11). Operational facts stay in resource-control.
  • Evidence-basis accepted as demand/EvidenceBasis.md and published as ITC-GOV EvidenceBasis / CAP-R10 (ITC-WP-0015, canon 0.4.0).
  • Provision-to-provision dependency accepted as demand/ProvisionRelationships.md and published as uses_provisions / CAP-R11 (ADHOC-2026-08-15 T03, canon 0.5.0). Canon spelling is may_use, not uses. Maturity is not capped across the dependency.