# Demand: Capability Provision Economics — requirement expressiveness, resource-class placement, and human/intelligence effort **Status:** accepted (ITC-CAP 0.2.0 / canon 0.3.0) **Date:** 2026-08-15 **Source:** resource-control (consumer), domain `financials` **Target artifact:** `ITC-CAP` v0.2.0 (`model/capability`), canon 0.3.0, status `proposed` **Consumer evidence:** `resource-control` `RESOURCE-WP-0002`, `RESOURCE-WP-0003` **Workplan:** `ITC-WP-0014` T08–T10 (findings A, B, and C landed together) **Decision:** `infospace/assimilation/it-capability-canon/ASSIMILATION.md` **Utility evidence:** `feedback/2026-08-15-resource-control-capability-provision.md` --- ## Demand signal Consumer **resource-control** owns portfolio identity, technical economics, allocation evidence, forecasts, and optimization cases for managed infrastructure. It has just completed a full procurement-to-control cycle against a real resource — provider selection, purchase, credential custody, proven restore and PITR, monthly observation, thresholds, and a decided optimization case. Mapping that completed work onto `ITC-CAP` succeeded well enough to be worth reporting, and failed in three specific places that are worth fixing. **The mapping that worked.** The backup work decomposes onto the catalog without strain: the object store provides `data.object`; CNPG/Barman provides `data.backup` (profile `database`) which `depends_on` it; the credential lane is `security.secrets`; the schedule is `runtime.scheduling`; the restore drill is evidence for both `data.backup` and `operations.recovery`. More significantly, the four `data.backup` evidence hooks — `successful_backup`, `successful_restore_test`, `measured_rpo`, `measured_rto` — match, one for one, the evidence the consumer had already produced before encountering this model. Independent convergence on the same evidence set is strong support for the capability layer as specified. This demand is a request to refine a model that is working, not to replace one that is not. --- ## A note on scope: why this is a refinement and not a canon split The consumer's first instinct on finding the resource-class weakness (finding C) was that supply-side and demand-side perspectives might warrant separate canons bound by an explicit mapping. On analysis that was rejected, and the reasoning is offered here because it may be reusable: > **Split a canon when the two sides disagree about what exists. Keep one canon > when they agree about what exists and differ only in what they assert about > it.** Supply and demand for a capability agree completely about what exists — the capability. They differ in what they assert: a requirement asserts a need, a provision asserts a maturity and a consumption. That is two record types on one spine, which `ITC-CAP` already has, and which `CAP-R2` already enforces. By contrast, `resource-control` and `fin-hub` genuinely disagree about what exists — a "booked cost" is not an object in the former's ontology, a "usage proxy" is not one in the latter's. Those two are correctly two canons with an explicit exchange contract. Splitting `ITC-CAP` would also destroy the property that makes capability ids valuable, and which `CAP-R5` names directly: a durable interface joinable by string equality. Two id spaces plus a mapping replaces a shared key with a translation layer that no test covers and no repository owns. --- ## Finding A — `typical_resource_classes` contradicts §4.11 and has no discriminating power `InfoTechCanonCapabilityModel.md` §4.11 states: > Resource consumption attaches to a provision or implementation, **never to an > abstract capability**. `capabilities.yaml` then carries `typical_resource_classes` on every capability. The `typical_` qualifier is absorbing the contradiction rather than resolving it. It also does no work. Across the 41-capability baseline: | Value | Capabilities | |---|---:| | `C, S, N, P` | 29 | | `C, N, P` | 5 | | `C, N, I, P` | 5 | | `C, S, P` | 2 | Twenty-nine of forty-one entries are identical. As a discriminator the field carries almost no information, while its presence on the abstract capability invites consumers to believe cost structuring happens there. It does not, and §4.11 says so. **Proposed:** move resource-class declaration to `CapabilityProvision`, where the model already says consumption belongs. If a capability-level hint is still wanted for navigation, it should be explicitly non-normative and excluded from any cost derivation. --- ## Finding B — quality targets have a supply-side home and no demand-side home `CapabilityRequirement` (§4.5) is a capability id plus a `minimum_maturity`. §4.9 then routes quality targets elsewhere: > The model names dimensions; **targets and measurement belong to ITC-LAND > service level objectives** and ITC-OBS. ITC-LAND service level objectives attach to *services* — supply-side artifacts. So a consumer expressing a need **before any provider exists** has no canonical place to write a target. This is the asymmetry: the supply side can say what it delivers; the demand side can only say which capability it wants and how mature. The consumer's real backup requirement, as actually decided, was: - capability `data.backup`, profile `database` - RPO ≤ 5 minutes, RTO measured, retention 30 days - **not** placed in the failure domain of the host it protects That last constraint decided the procurement. It has no expressible form today, so it lives in prose in an acceptance-requirements section. `ITC-CAP` already names `isolation` and `geographical_separation` as `data.backup` quality dimensions — the vocabulary exists, but requirements cannot use it. **Proposed:** enrich `CapabilityRequirement` to carry profile selection, quality targets against the capability's own declared dimensions, and failure-domain constraints. Illustratively: ```yaml requires: - capability: data.backup profile: database minimum_maturity: D5 targets: rpo: {value: 5, unit: minutes} rto: {value: 60, unit: minutes} retention: {value: 30, unit: days} geographical_separation: not_in: [provider:host-europe, host:railiance01] ``` This adds no new vocabulary — every dimension named is already declared on the capability. It makes the demand side able to use what the model already defines, and keeps a requirement self-contained rather than dependent on a supply-side SLO artifact that does not yet exist at requirement time. --- ## Finding C — the resource-class set has no human-effort class, and treats intelligence as an ordinary purchased input This is the substantive finding, and the consumer wishes to press it. ### C.1 The set is a taxonomy of purchased infrastructure `C` Compute, `S` Storage, `N` Networking, `I` Intelligence, `P` Platform classify *what a thing is*. For cost and constraint reasoning, two further properties determine behaviour: - **supply** — purchased on a per-unit external market, or drawn from internal capacity; - **capacity behaviour** — elastic (more is purchasable at roughly linear cost) or constrained (a hard ceiling inside the planning horizon). `C`, `S`, `N` are external and elastic. Human effort is internal and capacity-constrained, and has no class at all. `P` — "enabling operational overhead" — is the only plausible home, and it silently absorbs human time into a class described as a resource. That absorption is the defect. ### C.2 Consumer evidence that human effort is decision-relevant, not a rounding line **Provider selection inverted on labour.** For the backup object store, at month-12 base demand: | Option | Infrastructure | Operator time | Total recurring | |---|---:|---:|---:| | Scaleway Standard Multi-AZ | €7.35 | 1.0 h/month | **€67.35** | | Hetzner Object Storage | €6.49 | 1.5 h/month | **€96.49** | Hetzner is cheaper on infrastructure and **€29.14/month worse overall**, entirely on operator hours. A model that classifies only `C/S/N` selects the wrong provider from correct data. **Effort as a capacity ceiling, not a price.** The self-managed alternative (Garage on the incumbent provider's VMs) costs €335.77/month plus 16 hours setup and 4 hours/month recurring. The recurring hours were the binding objection, not the money: founder-hours do not scale with spend inside a planning horizon. This is capacity-constrained behaviour, and the current class set cannot express it. **Effort is frequently known in hours and unknown in currency.** The platform repository owning a shared PostgreSQL service delivered its effort evidence as "6 operator-hours setup, 0.5 hours/month recurring", explicitly stating: *no EUR — resource-control may convert at its own labour rate.* Hours and money are different quantities, measured by different parties, with different owners. Collapsing effort into a currency line at the point of capture loses the more authoritative of the two. The consumer's own schemas converged on this independently: control-cycle records split `infrastructure` / `internal_labor` / `external_labor`, and monthly observations carry `internal_labor_hours` separately from `internal_labor_eur`. ### C.3 Intelligence is not another purchased ingredient `I` exists and is defined as "metered or purchased cognitive or semantic processing capability" — placed alongside compute and storage as one more input bought on a market. The consumer's position is that this misses the property that matters, and that the canon needs vocabulary for it: 1. **Human effort capacity is a first-order business constraint.** How much competent human attention an organisation can apply is a hard limit that shapes what it can attempt at all, independent of its budget. 2. **Machine intelligence substitutes for human effort more flexibly than any prior input.** It is not an ingredient consumed *alongside* labour; it is an increasingly general *stand-in* for it. 3. **Its unit cost is falling steeply**, which moves the substitution frontier continuously. What is uneconomic to attempt this quarter may be routine next. 4. Therefore **efficiency of token use is a primary characteristic of a platform's utility**, not a line item — a productivity framework competing in the market is largely competing on how much delivered work it extracts per token. Items 1–4 are the consumer's strategic position, offered as the rationale for this demand rather than as established canon. The consumer notes honestly that it does **not** currently measure token consumption in its portfolio model — this part of the demand is forward-looking, not evidenced by its own measurements. It is nevertheless already operationally real in this organisation: a per-task token budget policy (soft and hard limits, with an explicit stop-and-decompose rule) governs agent work, and the State Hub already exposes token event recording and token summaries. The concept is being managed with policy and telemetry, and has no canonical home. ### C.4 Proposed The single most valuable change, from which the rest follows: > **A `CapabilityProvision` should record consumption per resource class in that > class's native unit — hours for human effort, tokens for intelligence, GB for > storage — not only in currency.** Currency collapses these into one dimension and destroys exactly the information needed to reason about constraints and substitution. Concretely: 1. **Add a human-effort class.** Suggested `H` — Human Effort, unit `hours`. Whether effort is internal or external is a *sourcing attribute*, not a separate class; the consumer's own model splits internal and external labour as two fields of one kind, which supports this. (Naming is not settled: `L` for Labour reads naturally against `I`, but `H`/`I` carries the human versus machine distinction more directly. The canon should choose.) 2. **Narrow `P`** to purchased platform and enabling services, so it stops silently absorbing human time. 3. **Keep `I`, recharacterised** as the elastic, externally purchased substitute for `H`, with a native unit alongside currency, and with its steeply declining unit cost noted as a modelling assumption rather than a constant. 4. **Declare economic attributes on each class** — `supply: internal | external` and `capacity_behaviour: elastic | constrained` — so a consumer can reason about ceilings, not only prices. 5. **Add an intelligence-efficiency quality dimension**, so token efficiency is describable as a *quality of a provision* and not only as a cost. Suggested `intelligence_intensity`: consumption per unit of capability output. The consumer deliberately does **not** propose a declared `substitutes_for` relation between classes. If `H` and `I` consumption are both recorded on the same provision in native units, substitution becomes *observable* from the time series without the canon having to assert an exchange rate it cannot know. This is the cheaper and more defensible mechanism, and it is the main practical reason to add `H` at all. --- ## Proposed placement - **Finding A** — `capabilities.yaml` catalog schema and `ITC-CAP` §4.11; mechanical, no id changes, fits `ITC-WP-0014` alongside the pending `capability.schema.yaml`. - **Finding B** — `ITC-CAP` §4.5, with a seam to ITC-GOV Purpose/Demand, since a `CapabilityRequirement` is already a typed `DemandSignal`. No new vocabulary. - **Finding C** — `ITC-CAP` §4.11 resource classes, likely touching ITC-LAND and possibly `commerce.metering`. Larger; probably its own workplan. **Avoid:** solving finding C only inside `resource-control`. If the consumer defines a private human-effort and token class set, every other repository reporting provision economics will diverge from it, and the cost question the capability layer exists to make answerable stays unanswerable across the estate. --- ## Success criteria 1. Resource-class declaration sits on `CapabilityProvision`, consistent with §4.11, and any capability-level hint is explicitly non-normative. 2. A `CapabilityRequirement` can express profile, quality targets against the capability's declared dimensions, and failure-domain constraints, without depending on a supply-side SLO artifact. 3. The resource-class set distinguishes human effort from purchased inputs, and each class declares supply and capacity behaviour. 4. A provision can record consumption in native units per class, including hours and tokens, with unknown values representable as unknown rather than zero. 5. Token efficiency is expressible as a quality dimension of a provision. 6. `resource-control` can restate the backup case — requirement, provision, maturity `D4`, four evidence hooks, and consumption — entirely in canon terms. Criterion 6 is offered as a concrete contribution: it would supply the "at least one canon Profile expressing a real capability requirement set with evidence" that `ITC-CAP` §10 lists as promotion requirement 3, using a real provisioned resource with verified restore evidence rather than a worked example. --- ## Non-goals - Splitting `ITC-CAP` into supply-side and demand-side canons. Analysed and rejected above. - A financial ledger, booked-cost semantics, or currency handling. Those belong to `fin-hub` under an existing exchange contract, and the consumer does not originate booked facts. - An organisational cost-accounting or time-tracking standard. The demand is for a class and a unit, not for a timesheet method or a labour rate. - A canonical exchange rate between human effort and intelligence. Deliberately excluded: it should be observed per provision, not asserted by the canon. - Vendor token pricing, model naming, or context-window semantics as canon.