info-tech-canon/demand/CapabilityProvisionEconomics.md

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:

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.