demand: capability provision economics from resource-control
Inbound demand against ITC-CAP v0.1.0 from a consumer that has completed a full
procurement-to-control cycle on a real resource. Three findings.
A. typical_resource_classes contradicts the model's own §4.11 ("consumption
attaches to a provision, never to an abstract capability") and carries almost
no information: 29 of 41 capabilities declare an identical C,S,N,P.
B. Quality targets have a supply-side home (ITC-LAND SLOs attach to services) and
no demand-side home. CapabilityRequirement is a capability id plus a minimum
maturity, so a consumer cannot state RPO, retention, or failure-domain
separation before a provider exists — even though ITC-CAP already declares
isolation and geographical_separation as data.backup dimensions.
C. The resource-class set has no human-effort class, and classifies Intelligence
as one more purchased input. Consumer evidence: provider selection inverted on
operator hours (Hetzner cheaper on infrastructure, EUR 29.14/month worse
overall); a self-managed option rejected on recurring hours rather than price;
and a platform repository that delivered effort in hours and explicitly not in
EUR. The consumer argues further that machine intelligence is a substitute for
human effort rather than an ingredient beside it, and that token efficiency is
a primary platform characteristic, so both need native units on a provision.
Also records the criterion used to reject splitting ITC-CAP into supply and
demand canons: split when the sides disagree about what exists, keep one canon
when they agree about what exists and differ only in what they assert about it.
Notes honestly that the consumer does not yet measure token consumption; that
part of the demand is forward-looking. It also offers the backup case, restated
in canon terms, toward ITC-CAP §10 promotion requirement 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
0694af1250
commit
9c7c1e4bdf
1 changed files with 316 additions and 0 deletions
316
demand/CapabilityProvisionEconomics.md
Normal file
316
demand/CapabilityProvisionEconomics.md
Normal file
|
|
@ -0,0 +1,316 @@
|
|||
# Demand: Capability Provision Economics — requirement expressiveness, resource-class placement, and human/intelligence effort
|
||||
|
||||
**Status:** inbound demand (un-reviewed)
|
||||
**Date:** 2026-08-15
|
||||
**Source:** resource-control (consumer), domain `financials`
|
||||
**Target artifact:** `ITC-CAP` v0.1.0 (`model/capability`), canon 0.2.1, status `proposed`
|
||||
**Consumer evidence:** `resource-control` `RESOURCE-WP-0002`, `RESOURCE-WP-0003`
|
||||
**Proposed workplan:** findings A and B under `ITC-WP-0014`; finding C likely a new workplan
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue