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.

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.

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