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:

```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.