diff --git a/demand/CapabilityProvisionEconomics.md b/demand/CapabilityProvisionEconomics.md new file mode 100644 index 0000000..9a73480 --- /dev/null +++ b/demand/CapabilityProvisionEconomics.md @@ -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.