Canon 0.3.0: capability provision economics (ITC-CAP 0.2.0)

Accept resource-control demand: move resource classes onto provisions, let requirements carry targets and constraints, add human-effort class H with native-unit consumption. Model stays proposed.
demand: capability provision economics from resource-control
2026-08-15 18:19:30 +02:00 · 2026-08-15 17:54:37 +02:00
14 changed files with 723 additions and 128 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -15,6 +15,52 @@ semantics.

 ---

+## 0.3.0 — 2026-08-15
+
+### Changed — Capability provision economics (requirement targets, native-unit consumption, class `H`)
+
+**Change.** The still-proposed Capability Model (`ITC-CAP`) moves from `0.1.0` to
+`0.2.0` in response to consumer demand `demand/CapabilityProvisionEconomics.md`
+(resource-control, a completed procurement-to-control cycle).
+
+- **Contracts** no longer declare `typical_resource_classes`. Resource
+  consumption attaches to a provision only (new CAP-R8), matching the rule §4.11
+  already stated.
+- **CapabilityRequirement** may select a profile, assert intended quality
+  targets against the capability's declared dimensions, and state placement
+  constraints with a closed predicate set (`not_in`, `in`, `equals`, `lte`,
+  `gte`). Measurement remains with ITC-LAND / ITC-OBS (new CAP-R9).
+- **Resource classes** gain `H` (Human Effort, native unit `hour`, default
+  supply `internal`, default capacity `constrained`). `P` is narrowed to
+  purchased platform and enabling services and no longer absorbs human time.
+  `I` is recharacterised as the elastic purchased substitute for `H`, native
+  unit `token`. Every class declares `native_unit`, `supply`, and
+  `capacity_behaviour`; a consumption record may override the last two.
+- **CapabilityConsumption** is a new owned concept: one native-unit row on a
+  provision. Unknown is recorded as `unknown`, never as zero. Currency is not a
+  class. No `substitutes_for` relation and no H↔I exchange rate.
+- Quality dimension `intelligence_intensity` is declared on all five
+  `intelligence.*` capabilities.
+
+**Rationale.** The catalog, evidence hooks, and D-scale independently matched
+the consumer's backup evidence. The three defects were cheapest to fix before
+`capability.schema.yaml` freezes the contract and before the consumer restates
+the real provision. Splitting ITC-CAP into demand-side and supply-side canons
+was considered and rejected: both sides agree about what exists.
+
+**Breaking:** no capability id, anchor, profile (except the new dimension on
+`intelligence.*`), evidence hook, or relationship type changed.
+`typical_resource_classes` is removed from the catalog; it was never a durable
+interface.
+
+**Records.** Decision record in
+`assimilation/it-capability-canon/ASSIMILATION.md`; OQ-5 notes a partial fire;
+`ITC-WP-0014` T08–T10 done.
+
+**Validation.** `make validate` 0 errors / 0 warnings; `make test` 22 passed.
+
+---
+
 ## 0.2.1 — 2026-08-15

 ### Changed — Capability navigation domains split (OQ-2 resolved)
--- a/canon.yaml
+++ b/canon.yaml
@ -1,7 +1,7 @@
 repository: info-tech-canon
 title: InfoTechCanon
 status: service-baseline
-version: 0.2.1
+version: 0.3.0
 description: >
  An evolving, markdown-first canon for building interoperable, adaptable,
  and extensible information-processing systems.
@ -93,6 +93,7 @@ models:
    title: InfoTechCanonCapabilityModel
    path: infospace/models/capability/InfoTechCanonCapabilityModel.md
    status: proposed
+    version: 0.2.0
    catalog: infospace/models/capability/capabilities.yaml
    provenance:
      assimilation: assimilation/it-capability-canon
@ -170,4 +171,5 @@ next_actions:
  - implement ITC-WP-0003 validation and generated views
  - implement ITC-WP-0004 small-saas profile proof
  - explore ITC-WP-0006 PURPOSES model extension
-  - publish ITC-WP-0014 T02 capability.schema.yaml (next ITC-CAP promotion gate)
+  - publish ITC-WP-0014 T02 capability.schema.yaml encoding ITC-CAP 0.2.0 (next ITC-CAP promotion gate)
+  - accept resource-control restatement of the backup provision against ITC-CAP 0.2.0 (demand criterion 6 / promotion requirement 3)
--- a/demand/CapabilityProvisionEconomics.md
+++ b/demand/CapabilityProvisionEconomics.md
@ -0,0 +1,317 @@
+# 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`
+
+---
+
+## 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.
--- a/infospace/agent/briefs/model-capability.md
+++ b/infospace/agent/briefs/model-capability.md
@ -28,6 +28,7 @@ Imports and anchors:
 ## Owned Concepts

 - `Capability`
+- `CapabilityConsumption`
 - `CapabilityContract`
 - `CapabilityDomain`
 - `CapabilityEvidenceHook`
--- a/infospace/agent/retrieval-index.json
+++ b/infospace/agent/retrieval-index.json
@ -1097,6 +1097,7 @@
      "kind": "model",
      "owned_concepts": [
        "Capability",
+        "CapabilityConsumption",
        "CapabilityContract",
        "CapabilityDomain",
        "CapabilityEvidenceHook",
--- a/infospace/agent/retrieval-index.md
+++ b/infospace/agent/retrieval-index.md
@ -303,7 +303,7 @@ Items: **65**
 - Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
 - Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model.
 - Imports and anchors: `kernel/itc-core`, `model/governance`, `model/landscape`, `model/observability`, `model/purpose-demand-extension`
- Owned concepts: `Capability`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model`
+- Owned concepts: `Capability`, `CapabilityConsumption`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model`

 ### InfoTechCanon Data Model

--- a/infospace/agent/retrieval-index.yaml
+++ b/infospace/agent/retrieval-index.yaml
@ -673,6 +673,7 @@ items:
    Model.'
  owned_concepts:
  - Capability
+  - CapabilityConsumption
  - CapabilityContract
  - CapabilityDomain
  - CapabilityEvidenceHook
--- a/infospace/assimilation/it-capability-canon/ASSIMILATION.md
+++ b/infospace/assimilation/it-capability-canon/ASSIMILATION.md
@ -178,3 +178,81 @@ touching an id.

 **Review trigger.** If a third capability group emerges that spans both domains,
 revisit whether navigation domains should be replaced by tags.
+
+---
+
+## Decision Record — Capability provision economics (demand 2026-08-15)
+
+**Date:** 2026-08-15 · **Canon version:** 0.3.0 · **Model version:** ITC-CAP 0.2.0
+**Demand:** `demand/CapabilityProvisionEconomics.md` (resource-control)
+
+**Context.** After a completed procurement-to-control cycle, resource-control
+mapped a real backup provision onto ITC-CAP v0.1.0. The catalog, evidence hooks,
+and D-scale worked. Three defects did not: `typical_resource_classes` contradicted
+§4.11 and carried almost no information; a requirement could not express profile,
+quality targets, or failure-domain constraints; the class set had no human-effort
+class and treated Intelligence as one more purchased input, so labour-inverted
+provider selection was inexpressible.
+
+**Decision.** Refine the still-proposed model in place. Do not split ITC-CAP
+into supply-side and demand-side canons. Do not open a separate workplan for
+finding C: the LAND and commerce touches are boundary clarifications, not new
+owning models.
+
+1. **Finding A.** Remove `typical_resource_classes` from every capability
+   contract. Consumption is declared on `CapabilityProvision` only (CAP-R8).
+   No non-normative hint is kept — 29 of 41 entries were identical.
+2. **Finding B.** Enrich `CapabilityRequirement` with optional `profile`,
+   `targets` against declared quality dimensions, and `constraints` with a
+   closed predicate set. Intended targets stay on the requirement; measurement
+   and observed SLOs stay with ITC-LAND / ITC-OBS. No new dimension vocabulary.
+3. **Finding C.** Add class `H` (Human Effort, native unit `hour`, default
+   supply `internal`, default capacity `constrained`). Narrow `P` so it no
+   longer absorbs human time. Recharacterise `I` as the elastic purchased
+   substitute for `H`, native unit `token`. Declare `native_unit`, `supply`,
+   and `capacity_behaviour` on each class; a consumption record may override
+   the last two. Record unknown as `unknown`, never zero. Add quality dimension
+   `intelligence_intensity` on `intelligence.*`. Do not declare
+   `substitutes_for` or an exchange rate.
+
+**Options considered.**
+
+1. *Leave the proposed model unchanged until promotion.* Rejected: the defects
+   are cheapest to fix before `capability.schema.yaml` (ITC-WP-0014 T02) freezes
+   the contract shape, and before a consumer restates a real provision against it.
+2. *Split ITC-CAP into demand-side and supply-side canons.* Rejected by the
+   consumer and accepted here: the two sides agree about what exists. Splitting
+   would replace CAP-R5's joinable id with a translation layer.
+3. *Solve finding C only inside resource-control.* Rejected: a private class set
+   would diverge the moment a second repository reports provision economics.
+4. *Name the new class `L` (Labour).* Rejected: `H`/`I` is the contrast the
+   class set exists to make observable; `L` also collides with Landscape in
+   casual speech.
+5. *Fix A and B now, defer C to a new workplan.* Rejected for this revision:
+   publishing A+B without C would leave the class set still wrong and force an
+   immediate follow-up version. C does not require a LAND or commerce model
+   change.
+
+**Rationale.** The capability layer is working. The demand is a refinement of a
+model that independently converged on the same backup evidence hooks the
+consumer had already produced. Native units preserve constraint and substitution
+information that currency destroys. Observing H/I substitution from a time
+series is cheaper and more defensible than asserting a rate the canon cannot
+know.
+
+**Consequences.**
+
+- Canon `0.3.0` (minor: new concepts and backward-compatible extensions;
+  no capability id changed). ITC-CAP `0.1.0` → `0.2.0`. Status remains
+  `proposed`.
+- New owned concept: `CapabilityConsumption`.
+- New rules: CAP-R8, CAP-R9.
+- `typical_resource_classes` removed from the catalog. Any consumer that read
+  that field must stop; it was never a durable interface.
+- ITC-WP-0014 T02 will encode the refined contract, not the v0.1.0 one.
+- Success criterion 6 of the demand (restate the backup case in canon terms)
+  remains a consumer contribution, now against this shape.
+
+**Review trigger.** First provision that needs a native unit the class table
+cannot host, or a constraint predicate outside `{not_in, in, equals, lte, gte}`.
+A full intelligence domain model remains OQ-5.
--- a/infospace/assimilation/it-capability-canon/open-questions.md
+++ b/infospace/assimilation/it-capability-canon/open-questions.md
@ -41,6 +41,13 @@ if consumers start requiring structural semantics (invoices, entitlements,
 prompts, evaluations). **Review trigger:** the first consumer demand that needs
 structure rather than ability.

+**Partial fire, 2026-08-15.** `demand/CapabilityProvisionEconomics.md` needed
+structure for *consumption of* intelligence (native unit `token`, quality
+dimension `intelligence_intensity`, class `I` as substitute for `H`). That
+structure landed in ITC-CAP 0.2.0 as resource-class and provision semantics, not
+as a new intelligence domain model. Invoices, entitlements, prompts, and
+evaluations still have no owning model. The trigger remains open for those.
+
 ## OQ-6 — How are capability requirements validated against provisions?

 The source sketches a validator (§18) comparing product requirements to provider
--- a/infospace/indexes/concept-ownership.yaml
+++ b/infospace/indexes/concept-ownership.yaml
@ -1,4 +1,4 @@
-concept_count: 106
+concept_count: 107
 concepts:
 - concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
  owner: assimilation/it-capability-canon
@ -160,6 +160,10 @@ concepts:
  owner: model/capability
  path: models/capability/InfoTechCanonCapabilityModel.md
  source: frontmatter.owned_concepts
+- concept: CapabilityConsumption
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
 - concept: CapabilityInclusionRule
  owner: model/capability
  path: models/capability/InfoTechCanonCapabilityModel.md
--- a/infospace/models/capability/InfoTechCanonCapabilityModel.md
+++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md
@ -7,7 +7,7 @@ standard_family: InfoTechCanon
 repository_context: info-tech-canon
 recommended_path: models/capability/InfoTechCanonCapabilityModel.md
 status: proposed
-version: 0.1.0
+version: 0.2.0
 source_version: "0.1"
 source_body: Information Technology Capability Canon (ITCC)
 source_file: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md
@ -45,16 +45,17 @@ owned_concepts:
  - CapabilityQualityDimension
  - CapabilityEvidenceHook
  - CapabilityResourceClass
+  - CapabilityConsumption
  - CapabilityInclusionRule
 created_at: 2026-08-14
-updated_at: 2026-08-14
+updated_at: 2026-08-15
 ---

 # InfoTechCanon Capability Model

 **Short Name:** `ITC-CAP`
 **Document Status:** Proposed (assimilated, not yet promoted)
-**Version:** 0.1.0
+**Version:** 0.2.0
 **Document Type:** InfoTechCanon Domain Model
 **Machine-readable catalog:** `models/capability/capabilities.yaml`
 **Provenance:** adapted from ITCC v0.1 — see `assimilation/it-capability-canon`
@ -88,7 +89,8 @@ Service / provider              ← ITC-LAND
 Technology                      ← ITC-LAND
        │ consumes
        ▼
-Resource classes → cost         ← classification owned here
+Resource classes → native units ← classification owned here
+                                 (currency overlay is not owned here)
 ```

 ---
@ -102,7 +104,9 @@ Resource classes → cost         ← classification owned here
 - capability-to-capability and landscape-to-capability relationships;
 - the provision of a capability by a provider in a context;
 - the maturity scale that applies to a provision;
- the resource classes used to attribute cost to a provision;
+- intended quality targets and placement constraints on a requirement;
+- the resource classes used to classify consumption of a provision;
+- consumption records in each class's native unit;
 - admission rules governing what may become a canonical capability;
 - the canonical capability baseline held in `capabilities.yaml`.

@ -115,7 +119,11 @@ Resource classes → cost         ← classification owned here
 - delivery pipeline semantics — ITC-DEVSECOPS;
 - domain-specific business capabilities (hospital admission, underwriting,
  warehouse picking) — outside InfoTechCanon;
- product features, protocols, and named technologies.
+- product features, protocols, and named technologies;
+- booked cost, currency handling, and ledgers — `fin-hub` under its exchange
+  contract;
+- a canonical exchange rate between human effort and intelligence;
+- timesheet methods or labour rates.

 ---

@ -175,26 +183,53 @@ unchanged (Core §6.5 *Profiles, Not Forks*).
 ## 4.4 CapabilityContract

 The machine-readable definition of a capability: id, name, purpose, anchors,
-profiles, quality dimensions, evidence hooks, relationships, and typical resource
-classes. Contracts live in `capabilities.yaml` and are the single source of
-truth. This document does not restate them.
+profiles, quality dimensions, evidence hooks, and relationships. Contracts live
+in `capabilities.yaml` and are the single source of truth. This document does
+not restate them.
+
+A contract does **not** declare resource classes. Consumption is a property of a
+provision, not of an abstract ability (see §4.11, CAP-R8).

 ## 4.5 CapabilityRequirement

 A statement that a system, product, or consumer purpose needs a capability at a
-minimum maturity:
+minimum maturity. It may also select a profile, assert intended quality targets
+against the capability's declared dimensions, and state placement constraints:

 ```yaml
 requires:
  - capability: identity.authentication
    minimum_maturity: D5
  - capability: data.backup
+    profile: database
    minimum_maturity: D5
+    targets:
+      rpo: {value: 5, unit: minutes}
+      rto: {value: 60, unit: minutes}
+      retention: {value: 30, unit: days}
+    constraints:
+      - dimension: geographical_separation
+        predicate: not_in
+        of:
+          - {kind: host, id: railiance01}
 ```

 A CapabilityRequirement is a **typed `DemandSignal`** (ITC-GOV Purpose and Demand
-extension) carrying a minimum maturity. It does not introduce a parallel
-requirement vocabulary.
+extension). It does not introduce a parallel requirement vocabulary.
+
+Rules:
+
+- `profile`, if present, MUST be a profile declared on that capability.
+- Every key of `targets` MUST be a quality dimension declared on that capability.
+- Every `constraints[].dimension` MUST be a quality dimension declared on that
+  capability.
+- `of` entries are consumer landscape references, not canon identifiers.
+- Closed predicates: `not_in`, `in`, `equals`, `lte`, `gte`.
+
+A target is an *intended* value. It does not create an SLO and does not measure
+anything. Measurement and observed values belong to ITC-LAND service level
+objectives and ITC-OBS (see §4.9). This is what lets a consumer write a need
+before any provider exists.

 ## 4.6 CapabilityProvider

@ -209,12 +244,33 @@ resource consumption all attach here.

 ```yaml
 provision:
-  provider: auth.prod.eu
-  capability: identity.authentication
+  provider: backup.barman.prod
+  capability: data.backup
+  profile: database
  environment: production
-  maturity: D6
+  maturity: D4
+  consumes:
+    - class: S
+      quantity: {value: 50, unit: GB}
+      period: month
+    - class: H
+      quantity: {value: 1.0, unit: hour}
+      period: month
+      supply: internal
+    - class: P
+      quantity: {value: 1, unit: unit}
+      period: month
+      supply: external
+    - class: I
+      quantity: unknown
 ```

+Unknown consumption MUST be recorded as `unknown`, never as zero. Zero means
+"measured and none"; unknown means "not yet measured or not applicable."
+
+A provision MAY override a class's default `supply` and `capacity_behaviour`
+(for example contracted operator time recorded as `H` with `supply: external`).
+
 ## 4.8 CapabilityMaturityLevel

 | Level | State | Meaning |
@ -234,8 +290,21 @@ level (Core §18). It describes a provision, not a document and not a consumer.
 ## 4.9 CapabilityQualityDimension

 A named quality attribute relevant to a capability (`rpo`, `rto`, `assurance`,
-`decision_latency`, `explainability`). The model names dimensions; *targets and
-measurement* belong to ITC-LAND service level objectives and ITC-OBS.
+`decision_latency`, `explainability`, `intelligence_intensity`). The model names
+dimensions.
+
+- **Intended targets** against those dimensions belong on a CapabilityRequirement
+  (§4.5). They are demand assertions.
+- **Measurement and observed values** belong to ITC-LAND service level objectives
+  and ITC-OBS. They are supply observations.
+
+A requirement written before any provider exists therefore does not depend on a
+service-level objective that cannot yet exist.
+
+`intelligence_intensity` is the consumption of class `I` per unit of capability
+output. It is a quality of a provision that consumes Intelligence, not a cost
+line. It is declared on the `intelligence.*` capabilities and may be used on any
+provision that consumes `I`.

 ## 4.10 CapabilityEvidenceHook

@ -245,17 +314,65 @@ telemetry-derived evidence comes from ITC-OBS.

 ## 4.11 CapabilityResourceClass

-| ID | Class | Meaning |
-|---|---|---|
-| `C` | Compute | Generic execution capacity |
-| `S` | Storage | Persistence capacity |
-| `N` | Networking | Information movement |
-| `I` | Intelligence | Metered or purchased cognitive / semantic processing |
-| `P` | Platform | Enabling operational overhead |
+| ID | Class | Native unit | Default supply | Default capacity |
+|---|---|---|---|---|
+| `C` | Compute | `vCPU-hour` | external | elastic |
+| `S` | Storage | `GB` | external | elastic |
+| `N` | Networking | `GB` | external | elastic |
+| `I` | Intelligence | `token` | external | elastic |
+| `H` | Human Effort | `hour` | internal | constrained |
+| `P` | Platform | `unit` | external | elastic |

-Resource consumption attaches to a provision or implementation, never to an
-abstract capability. This is what makes capability-oriented cost questions
-answerable ("what does Authentication cost per tenant?").
+**Supply** is `internal` (drawn from own capacity) or `external` (purchased).
+It is a sourcing attribute of a consumption record, not a separate class.
+Internal versus contracted labour are both `H`.
+
+**Capacity behaviour** is `elastic` (more is purchasable at roughly linear cost
+inside the planning horizon) or `constrained` (a hard ceiling). Human effort
+inside a founder- or team-hour budget is constrained; tokens and object storage
+are elastic.
+
+Class meanings:
+
+- `C` — generic execution capacity.
+- `S` — persistence capacity.
+- `N` — information movement. Native unit is transfer volume.
+- `I` — metered cognitive or semantic processing, treated as the elastic
+  purchased substitute for `H`. Its unit cost is assumed to decline over time;
+  that is a modelling assumption, not a constant the canon asserts a value for.
+- `H` — human attention applied to provide or operate the capability. Native
+  unit is hours. `H` exists so that labour can bind a decision as a ceiling,
+  not only as a price.
+- `P` — purchased platform and enabling services that make other resources
+  usable. `P` does **not** absorb human time.
+
+The letter is `H` (not `L` for labour) so the human / intelligence contrast is
+the one the class set is designed to make observable.
+
+A provision may record a more specific compatible unit (`GPU-hour` under `C`)
+but SHOULD keep the class. Recommended native units for `C` and `P` are weak
+because those classes are heterogeneous; `hour`, `token`, and `GB` are the
+units the class set is required to protect.
+
+Resource consumption attaches to a provision or implementation, **never to an
+abstract capability**. This is what makes capability-oriented questions
+answerable ("what does Authentication consume per tenant, in hours and in
+tokens?").
+
+## 4.12 CapabilityConsumption
+
+One row of a provision's `consumes` list. It records use of a single resource
+class in that class's **native unit**, optionally over a period.
+
+Currency is not a resource class and is not a native unit. A financial overlay
+— converting hours or tokens into money — is performed by the consumer or by
+`fin-hub` under its own exchange contract. Collapsing classes into currency at
+capture time destroys the information needed for constraint and substitution
+reasoning.
+
+The canon does **not** declare a `substitutes_for` relation or an exchange rate
+between classes. If `H` and `I` appear on the same provision in native units,
+substitution is observable from the time series.

 ---

@ -291,6 +408,15 @@ expressed as a CapabilityProfile, not a new Capability.
 **CAP-R7** The Markdown document MUST NOT restate capability definitions held in
 `capabilities.yaml`.

+**CAP-R8** Resource consumption MUST attach to a CapabilityProvision or
+implementation, never to a Capability. A Capability contract MUST NOT carry a
+normative resource-class declaration. A consumption record MUST use the class's
+native unit. Unknown MUST be recorded as `unknown`, never as zero.
+
+**CAP-R9** A CapabilityRequirement `profile`, target key, or constraint dimension
+MUST be declared on the required capability. A target is an intended value, not
+a measurement.
+
 ---

 # 6. Admission Rules
@ -327,18 +453,19 @@ Landscape and consumer to capability:
 | `requires` | A product, workload, service, or consumer purpose requires a capability |
 | `provides` | A provider supplies a capability (creates a provision) |
 | `implements` | A technology realizes all or part of a provider |
-| `consumes` | A provision consumes resource classes |
+| `consumes` | A provision consumes resource classes in native units |

-Traversal from need to cost:
+Traversal from need to consumption:

 ```text
 ConsumerPurpose --requires--> Capability <--provides-- Service
-                                                        │ implements
-                                                        ▼
-                                                   Technology
-                                                        │ consumes
-                                                        ▼
-                                                  C / S / N / I / P
+     │                                                 │ implements
+     │ targets, constraints                            ▼
+     ▼                                            Technology
+CapabilityRequirement                                  │ consumes
+                                                       ▼
+                                              C / S / N / I / H / P
+                                              (native units; unknown allowed)
 ```

 ---
@ -371,7 +498,7 @@ model. This is accepted at `proposed` status and tracked as OQ-5.

 | Model | Boundary |
 |---|---|
-| ITC-LAND | Owns services, technologies, runtime resources, SLOs. ITC-CAP names abilities; ITC-LAND names the things that provide and implement them. `BusinessCapability` / `ProductCapability` in ITC-LAND §11 should resolve to references here. |
+| ITC-LAND | Owns services, technologies, runtime resources, and *observed* SLOs. ITC-CAP names abilities and *intended* requirement targets; ITC-LAND names the things that provide and implement them. `BusinessCapability` / `ProductCapability` in ITC-LAND §11 should resolve to references here. |
 | ITC-GOV | Owns policy, control, evidence, assurance. ITC-CAP names capability evidence *hooks*, not evidence semantics. Capability requirements are typed demand signals from the Purpose and Demand extension. |
 | ITC-ACCESS | Owns subject, principal, permission, grant, decision. `identity.*` capabilities are abilities over those mechanisms. |
 | CARING | Access-governance analysis. May import `identity.*` ids; ITC-CAP takes no position on access-governance analysis. |
@ -410,3 +537,10 @@ Changes made on adoption: `Profile` renamed `CapabilityProfile`; `Provision` mad
 explicit; per-capability `anchors` added; requirements bound to Purpose and
 Demand; the proposed CILM landscape model rejected in favour of ITC-LAND;
 capability definitions moved wholly into the machine-readable catalog.
+
+Version 0.2.0 (canon 0.3.0) refines the proposed model from consumer demand
+`demand/CapabilityProvisionEconomics.md`: resource-class declaration moved off
+the contract onto the provision; requirements gained profile, targets, and
+constraints; class `H` added; `P` narrowed; `I` recharacterised; consumption
+records use native units. See the decision record in
+`assimilation/it-capability-canon/ASSIMILATION.md`.
--- a/infospace/models/capability/capabilities.yaml
+++ b/infospace/models/capability/capabilities.yaml
@ -12,9 +12,9 @@ canon:
  name: InfoTechCanon Capability Model — Capability Catalog
  short_name: ITC-CAP
  artifact_id: model/capability
-  version: 0.1.0
+  version: 0.2.0
  status: proposed
-  canon_version: 0.2.1
+  canon_version: 0.3.0
  purpose: Canonical, implementation-independent catalog of the abilities an information system may require
    or provide.
  normative_document: models/capability/InfoTechCanonCapabilityModel.md
@ -28,23 +28,45 @@ resource_classes:
 - id: C
  name: Compute
  description: Generic execution capacity.
-  note: Consumed by a capability provision, never by an abstract capability.
+  native_unit: vCPU-hour
+  supply: external
+  capacity_behaviour: elastic
+  note: Consumed by a capability provision, never by an abstract capability. Recommended native unit is weak; a provision may record a more specific compatible unit.
 - id: S
  name: Storage
  description: Persistence capacity.
+  native_unit: GB
+  supply: external
+  capacity_behaviour: elastic
  note: Consumed by a capability provision, never by an abstract capability.
 - id: N
  name: Networking
  description: Information movement.
-  note: Consumed by a capability provision, never by an abstract capability.
+  native_unit: GB
+  supply: external
+  capacity_behaviour: elastic
+  note: Consumed by a capability provision, never by an abstract capability. Native unit is transfer volume.
 - id: I
  name: Intelligence
-  description: Metered or purchased cognitive or semantic processing capability.
-  note: Consumed by a capability provision, never by an abstract capability.
+  description: Metered cognitive or semantic processing; the elastic purchased substitute for human effort.
+  native_unit: token
+  supply: external
+  capacity_behaviour: elastic
+  note: Consumed by a capability provision, never by an abstract capability. Unit cost is assumed to decline over time as a modelling assumption, not as a constant. No canonical exchange rate with H.
+- id: H
+  name: Human Effort
+  description: Human attention applied to provide or operate a capability.
+  native_unit: hour
+  supply: internal
+  capacity_behaviour: constrained
+  note: Consumed by a capability provision, never by an abstract capability. Internal versus contracted labour is a supply attribute, not a separate class.
 - id: P
  name: Platform
-  description: Enabling operational overhead that makes other resources usable.
-  note: Consumed by a capability provision, never by an abstract capability.
+  description: Purchased platform and enabling services that make other resources usable. Does not include human time.
+  native_unit: unit
+  supply: external
+  capacity_behaviour: elastic
+  note: Consumed by a capability provision, never by an abstract capability. Recommended native unit is weak. Human time is class H, not P.
 maturity_levels:
 - id: D0
  name: Absent
@ -118,11 +140,6 @@ domains:
    - successful_provisioning
    - successful_deprovisioning
    - ownership_record
-    typical_resource_classes: &id001
-    - C
-    - S
-    - N
-    - P
  - id: identity.authentication
    name: Authentication
    purpose: Establish that an actor controls or legitimately represents an identity.
@ -145,7 +162,6 @@ domains:
    - successful_authentication
    - failure_metrics
    - availability_metrics
-    typical_resource_classes: *id001
  - id: identity.authorization
    name: Authorization
    purpose: Determine whether an actor may perform an action on a resource.
@ -165,7 +181,6 @@ domains:
    - policy_tests
    - authorization_decisions
    - denial_evidence
-    typical_resource_classes: *id001
  - id: identity.federation
    name: Identity Federation
    purpose: Establish and use trust relationships between identity domains.
@ -183,7 +198,6 @@ domains:
    evidence_hooks:
    - federation_configuration
    - successful_federated_login
-    typical_resource_classes: *id001
  - id: identity.organization
    name: Organization & Tenancy
    purpose: Associate identities, resources, policies, and operations with organizational or tenant boundaries.
@ -202,7 +216,6 @@ domains:
    evidence_hooks:
    - tenant_isolation_tests
    - membership_records
-    typical_resource_classes: *id001
 - id: data
  name: Data & State
  navigation_only: true
@ -225,11 +238,6 @@ domains:
    evidence_hooks:
    - durability_tests
    - availability_metrics
-    typical_resource_classes: &id002
-    - C
-    - S
-    - N
-    - P
  - id: data.object
    name: Object Persistence
    purpose: Persist opaque objects, files, blobs, documents, or similar binary or semi-structured objects.
@ -247,7 +255,6 @@ domains:
    evidence_hooks:
    - object_integrity_tests
    - availability_metrics
-    typical_resource_classes: *id002
  - id: data.cache
    name: Caching
    purpose: Maintain temporary or derived state for accelerated access.
@ -266,7 +273,6 @@ domains:
    evidence_hooks:
    - cache_metrics
    - latency_metrics
-    typical_resource_classes: *id002
  - id: data.backup
    name: Backup & Restore
    purpose: Create recoverable copies or recovery points and restore previously valid persisted state
@ -289,7 +295,6 @@ domains:
    - successful_restore_test
    - measured_rpo
    - measured_rto
-    typical_resource_classes: *id002
    depends_on:
    - data.object
    may_use:
@ -315,7 +320,6 @@ domains:
    - retention_policy
    - integrity_verification
    - retrieval_test
-    typical_resource_classes: *id002
  - id: data.search
    name: Search & Retrieval
    purpose: Locate persisted information based on indexed or queryable characteristics.
@ -336,7 +340,6 @@ domains:
    evidence_hooks:
    - search_tests
    - latency_metrics
-    typical_resource_classes: *id002
 - id: integration
  name: Integration & Communication
  navigation_only: true
@ -360,10 +363,6 @@ domains:
    evidence_hooks:
    - contract_tests
    - availability_metrics
-    typical_resource_classes: &id003
-    - C
-    - N
-    - P
  - id: integration.messaging
    name: Messaging & Eventing
    purpose: Exchange asynchronous messages or events between producers and consumers.
@ -383,7 +382,6 @@ domains:
    evidence_hooks:
    - delivery_tests
    - lag_metrics
-    typical_resource_classes: *id003
  - id: integration.exchange
    name: Data Exchange
    purpose: Move datasets, files, or structured information between systems.
@ -403,7 +401,6 @@ domains:
    evidence_hooks:
    - transfer_tests
    - integrity_checks
-    typical_resource_classes: *id003
  - id: integration.notification
    name: Notification
    purpose: Deliver information to human users or external endpoints.
@ -424,7 +421,6 @@ domains:
    evidence_hooks:
    - delivery_receipts
    - failure_metrics
-    typical_resource_classes: *id003
  - id: integration.traffic
    name: Traffic Management
    purpose: Route, balance, control, filter, or shape communication between endpoints.
@ -444,7 +440,6 @@ domains:
    evidence_hooks:
    - routing_tests
    - availability_metrics
-    typical_resource_classes: *id003
 - id: runtime
  name: Runtime & Automation
  navigation_only: true
@ -468,11 +463,6 @@ domains:
    evidence_hooks:
    - execution_tests
    - capacity_metrics
-    typical_resource_classes: &id004
-    - C
-    - S
-    - N
-    - P
  - id: runtime.configuration
    name: Configuration
    purpose: Supply controlled runtime configuration to software and services.
@ -492,7 +482,6 @@ domains:
    evidence_hooks:
    - configuration_history
    - propagation_tests
-    typical_resource_classes: *id004
  - id: runtime.scheduling
    name: Scheduling
    purpose: Initiate activities according to time, delay, calendar, or recurrence.
@ -510,7 +499,6 @@ domains:
    - timezone_support
    evidence_hooks:
    - schedule_execution_records
-    typical_resource_classes: *id004
  - id: runtime.workflow
    name: Workflow Orchestration
    purpose: Coordinate multi-step activities, state transitions, dependencies, retries, and completion.
@ -529,7 +517,6 @@ domains:
    evidence_hooks:
    - workflow_completion_records
    - recovery_tests
-    typical_resource_classes: *id004
    may_use:
    - integration.messaging
    - runtime.scheduling
@ -553,7 +540,6 @@ domains:
    evidence_hooks:
    - deployment_records
    - rollback_test
-    typical_resource_classes: *id004
 - id: operations
  name: Operations & Assurance
  navigation_only: true
@ -578,11 +564,6 @@ domains:
    evidence_hooks:
    - telemetry_coverage
    - dashboard_or_query_evidence
-    typical_resource_classes: &id005
-    - C
-    - S
-    - N
-    - P
  - id: operations.alerting
    name: Alerting
    purpose: Detect relevant conditions and surface them to humans or automation.
@ -601,7 +582,6 @@ domains:
    evidence_hooks:
    - alert_tests
    - incident_linkage
-    typical_resource_classes: *id005
    may_use:
    - operations.observability
    - integration.notification
@ -623,7 +603,6 @@ domains:
    evidence_hooks:
    - audit_records
    - integrity_verification
-    typical_resource_classes: *id005
  - id: operations.recovery
    name: Service Recovery
    purpose: Restore an operational service after failure or degradation.
@ -642,7 +621,6 @@ domains:
    evidence_hooks:
    - recovery_tests
    - incident_recovery_records
-    typical_resource_classes: *id005
    may_use:
    - data.backup
    - operations.observability
@ -663,7 +641,6 @@ domains:
    evidence_hooks:
    - continuity_tests
    - availability_metrics
-    typical_resource_classes: *id005
 - id: security
  name: Security
  navigation_only: true
@ -686,11 +663,6 @@ domains:
    evidence_hooks:
    - rotation_records
    - access_audit
-    typical_resource_classes: &id006
-    - C
-    - S
-    - N
-    - P
  - id: security.keys
    name: Key & Certificate Management
    purpose: Create, protect, distribute, rotate, validate, and revoke cryptographic keys and certificates.
@ -709,7 +681,6 @@ domains:
    evidence_hooks:
    - certificate_inventory
    - rotation_records
-    typical_resource_classes: *id006
  - id: security.policy
    name: Policy Management & Enforcement
    purpose: Define, distribute, evaluate, and enforce machine-interpretable policies.
@ -729,7 +700,6 @@ domains:
    evidence_hooks:
    - policy_tests
    - decision_records
-    typical_resource_classes: *id006
  - id: security.vulnerability
    name: Vulnerability Management
    purpose: Identify, assess, prioritize, remediate, mitigate, and track exploitable weaknesses.
@ -749,7 +719,6 @@ domains:
    evidence_hooks:
    - scan_results
    - remediation_records
-    typical_resource_classes: *id006
 - id: governance
  name: Governance
  navigation_only: true
@ -772,10 +741,6 @@ domains:
    evidence_hooks:
    - evidence_records
    - assessment_links
-    typical_resource_classes: &id007
-    - C
-    - S
-    - P
  - id: governance.lifecycle
    name: Information Lifecycle Governance
    purpose: Apply rules governing information retention, handling, deletion, preservation, and lifecycle
@ -796,7 +761,6 @@ domains:
    - lifecycle_policy
    - deletion_records
    - retention_evidence
-    typical_resource_classes: *id007
 - id: commerce
  name: Commerce
  navigation_only: true
@ -818,11 +782,6 @@ domains:
    evidence_hooks:
    - meter_records
    - reconciliation
-    typical_resource_classes: &id008
-    - C
-    - S
-    - N
-    - P
    anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5.
  - id: commerce.billing
    name: Billing
@ -841,7 +800,6 @@ domains:
    evidence_hooks:
    - invoice_tests
    - billing_reconciliation
-    typical_resource_classes: *id008
    may_use:
    - commerce.metering
    - commerce.entitlement
@ -865,7 +823,6 @@ domains:
    evidence_hooks:
    - payment_records
    - settlement_reconciliation
-    typical_resource_classes: *id008
    may_use:
    - identity.authentication
    - operations.audit
@ -889,7 +846,6 @@ domains:
    evidence_hooks:
    - entitlement_tests
    - decision_records
-    typical_resource_classes: *id008
    may_use:
    - identity.authorization
 - id: intelligence
@ -912,14 +868,10 @@ domains:
    - latency
    - cost
    - safety
+    - intelligence_intensity
    evidence_hooks:
    - evaluation_results
    - latency_metrics
-    typical_resource_classes: &id009
-    - C
-    - N
-    - I
-    - P
    anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5.
  - id: intelligence.extraction
    name: Extraction & Classification
@ -936,10 +888,10 @@ domains:
    - recall
    - precision
    - latency
+    - intelligence_intensity
    evidence_hooks:
    - evaluation_results
    - golden_set_tests
-    typical_resource_classes: *id009
    anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5.
  - id: intelligence.embedding
    name: Semantic Representation
@ -954,10 +906,10 @@ domains:
    - semantic_quality
    - latency
    - cost
+    - intelligence_intensity
    evidence_hooks:
    - retrieval_benchmarks
    - latency_metrics
-    typical_resource_classes: *id009
    anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5.
  - id: intelligence.retrieval
    name: Semantic Retrieval & Ranking
@ -974,9 +926,9 @@ domains:
    - precision
    - ranking_quality
    - latency
+    - intelligence_intensity
    evidence_hooks:
    - retrieval_benchmarks
-    typical_resource_classes: *id009
    may_use:
    - intelligence.embedding
    - data.search
@ -995,10 +947,10 @@ domains:
    - latency
    - cost
    - explainability
+    - intelligence_intensity
    evidence_hooks:
    - task_evaluations
    - decision_records
-    typical_resource_classes: *id009
    may_use:
    - intelligence.retrieval
    anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5.
--- a/infospace/views/by-concept.md
+++ b/infospace/views/by-concept.md
@ -2,7 +2,7 @@

 # By Concept

-Concept count: **106**
+Concept count: **107**

 | Concept | Owner | Source |
 | --- | --- | --- |
@ -46,6 +46,7 @@ Concept count: **106**
 | CapabilityQualityDimension | `model/capability` | `frontmatter.owned_concepts` |
 | CapabilityEvidenceHook | `model/capability` | `frontmatter.owned_concepts` |
 | CapabilityResourceClass | `model/capability` | `frontmatter.owned_concepts` |
+| CapabilityConsumption | `model/capability` | `frontmatter.owned_concepts` |
 | CapabilityInclusionRule | `model/capability` | `frontmatter.owned_concepts` |
 | InfoTechCanon Data Model | `model/data` | `artifact_title` |
 | InfoTechCanon DevSecOps Model | `model/devsecops` | `artifact_title` |
--- a/workplans/ITC-WP-0014-capability-model-consolidation.md
+++ b/workplans/ITC-WP-0014-capability-model-consolidation.md
@ -18,6 +18,7 @@ spec_refs:
  - infospace/assimilation/it-capability-canon/proposed-changes.md
  - infospace/assimilation/it-capability-canon/open-questions.md
  - infospace/models/capability/InfoTechCanonCapabilityModel.md
+  - demand/CapabilityProvisionEconomics.md
 state_hub_workstream_id: "18cccc77-5aef-48f2-91d6-124bd439285a"
 ---

@ -32,8 +33,11 @@ closing the items the ITCC v0.1 assimilation deliberately deferred.

 Canon version 0.2.0 adopted the capability vocabulary under disposition `adapt`.
 The model is registered, validated, and anchored, but it has no schema, no formal
-mapping artifacts, no profile exercising it, and one unresolved identifier
-question that is blocking because capability ids are durable interfaces.
+mapping artifacts, and no profile exercising it. OQ-2 is resolved (canon 0.2.1).
+Consumer demand `CapabilityProvisionEconomics` (resource-control) refined the
+still-proposed model in canon 0.3.0 / ITC-CAP 0.2.0: requirement targets,
+provision-side consumption, and the H/I/P class set. T02 must encode that
+refined contract, not the v0.1.0 one.

 ## Tasks

@ -66,6 +70,10 @@ state_hub_task_id: "1ed8d07a-34ee-4ad4-8e4a-03a513c14836"

 Add the capability contract schema under `infospace/schemas/`, register it in
 `infospace/infospace.yaml`, and validate `capabilities.yaml` against it.
+Encode ITC-CAP 0.2.0: no `typical_resource_classes` on contracts; resource
+classes carry `native_unit`, `supply`, and `capacity_behaviour`; requirement
+and provision record shapes live in the model prose until a companion
+requirement/provision schema is justified.

 ### T03 — Formal mapping artifacts for each anchor

@ -135,11 +143,54 @@ state_hub_task_id: "455690e3-c39a-4926-a13b-a179b134b2a4"
 Promote the model from `proposed` to `draft` or `release-candidate`, bump the
 canon version, and write the `CHANGELOG.md` entry.

+### T08 — Finding A: move resource-class declaration off the contract
+
+```task
+id: ITC-WP-0014-T08
+status: done
+priority: high
+```
+
+Remove `typical_resource_classes` from every capability contract so §4.11 and
+the catalog agree. Consumption is declared on `CapabilityProvision` only.
+
+**Done 2026-08-15 (canon 0.3.0 / ITC-CAP 0.2.0).**
+
+### T09 — Finding B: demand-side targets and constraints
+
+```task
+id: ITC-WP-0014-T09
+status: done
+priority: high
+```
+
+Enrich `CapabilityRequirement` with profile, quality targets against declared
+dimensions, and placement constraints. Keep measurement on ITC-LAND / ITC-OBS.
+
+**Done 2026-08-15 (canon 0.3.0 / ITC-CAP 0.2.0).**
+
+### T10 — Finding C: human effort, native units, intelligence as substitute
+
+```task
+id: ITC-WP-0014-T10
+status: done
+priority: high
+```
+
+Add class `H`, narrow `P`, recharacterise `I`, declare native units and
+supply/capacity defaults, record consumption in native units, add
+`intelligence_intensity`. No `substitutes_for`, no exchange rate.
+
+**Done 2026-08-15 (canon 0.3.0 / ITC-CAP 0.2.0).** Landed here rather than as a
+new workplan: no LAND or commerce owning-model change was required.
+
 ## Out of scope

- New domain models for `commerce.*` / `intelligence.*` (OQ-5) — needs a real
-  consumer demand first.
+- New domain models for `commerce.*` / `intelligence.*` (OQ-5) — the 2026-08-15
+  demand needed consumption structure, which landed in ITC-CAP; invoices,
+  entitlements, prompts, and evaluations still have no owning model.
 - Canon-wide intended/declared/applied/observed/assessed state qualifiers (OQ-3)
  — kernel-level pressure, not a capability-model decision.
 - CARING importing `identity.*` ids — touches a release-candidate standard and
  needs its own review.
+- Booked cost, currency handling, labour rates, or an H↔I exchange rate.