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.
2026-08-15 18:19:30 +02:00 · 2026-08-15 18:19:30 +02:00 · b69b048dcb
commit b69b048dcb
parent 9c7c1e4bdf
14 changed files with 410 additions and 131 deletions
--- 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`.