From 9c7c1e4bdf2a79dfd74aaa5401da97caf48f0869 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 15 Aug 2026 17:54:37 +0200 Subject: [PATCH 1/2] demand: capability provision economics from resource-control MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Inbound demand against ITC-CAP v0.1.0 from a consumer that has completed a full procurement-to-control cycle on a real resource. Three findings. A. typical_resource_classes contradicts the model's own §4.11 ("consumption attaches to a provision, never to an abstract capability") and carries almost no information: 29 of 41 capabilities declare an identical C,S,N,P. B. Quality targets have a supply-side home (ITC-LAND SLOs attach to services) and no demand-side home. CapabilityRequirement is a capability id plus a minimum maturity, so a consumer cannot state RPO, retention, or failure-domain separation before a provider exists — even though ITC-CAP already declares isolation and geographical_separation as data.backup dimensions. C. The resource-class set has no human-effort class, and classifies Intelligence as one more purchased input. Consumer evidence: provider selection inverted on operator hours (Hetzner cheaper on infrastructure, EUR 29.14/month worse overall); a self-managed option rejected on recurring hours rather than price; and a platform repository that delivered effort in hours and explicitly not in EUR. The consumer argues further that machine intelligence is a substitute for human effort rather than an ingredient beside it, and that token efficiency is a primary platform characteristic, so both need native units on a provision. Also records the criterion used to reject splitting ITC-CAP into supply and demand canons: split when the sides disagree about what exists, keep one canon when they agree about what exists and differ only in what they assert about it. Notes honestly that the consumer does not yet measure token consumption; that part of the demand is forward-looking. It also offers the backup case, restated in canon terms, toward ITC-CAP §10 promotion requirement 3. Co-Authored-By: Claude Opus 5 --- demand/CapabilityProvisionEconomics.md | 316 +++++++++++++++++++++++++ 1 file changed, 316 insertions(+) create mode 100644 demand/CapabilityProvisionEconomics.md 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. From b69b048dcbb1b0a42edbd48128401a708978a07f Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 15 Aug 2026 18:19:30 +0200 Subject: [PATCH 2/2] 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. --- CHANGELOG.md | 46 ++++ canon.yaml | 6 +- demand/CapabilityProvisionEconomics.md | 7 +- infospace/agent/briefs/model-capability.md | 1 + infospace/agent/retrieval-index.json | 1 + infospace/agent/retrieval-index.md | 2 +- infospace/agent/retrieval-index.yaml | 1 + .../it-capability-canon/ASSIMILATION.md | 78 +++++++ .../it-capability-canon/open-questions.md | 7 + infospace/indexes/concept-ownership.yaml | 6 +- .../InfoTechCanonCapabilityModel.md | 206 +++++++++++++++--- infospace/models/capability/capabilities.yaml | 118 +++------- infospace/views/by-concept.md | 3 +- ...-WP-0014-capability-model-consolidation.md | 59 ++++- 14 files changed, 410 insertions(+), 131 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2fbc9bb..e857d1d 100644 --- 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) diff --git a/canon.yaml b/canon.yaml index 9e40c2a..9d56b5c 100644 --- 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) diff --git a/demand/CapabilityProvisionEconomics.md b/demand/CapabilityProvisionEconomics.md index 9a73480..b75735a 100644 --- a/demand/CapabilityProvisionEconomics.md +++ b/demand/CapabilityProvisionEconomics.md @@ -1,11 +1,12 @@ # Demand: Capability Provision Economics — requirement expressiveness, resource-class placement, and human/intelligence effort -**Status:** inbound demand (un-reviewed) +**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.1.0 (`model/capability`), canon 0.2.1, status `proposed` +**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` -**Proposed workplan:** findings A and B under `ITC-WP-0014`; finding C likely a new workplan +**Workplan:** `ITC-WP-0014` T08–T10 (findings A, B, and C landed together) +**Decision:** `infospace/assimilation/it-capability-canon/ASSIMILATION.md` --- diff --git a/infospace/agent/briefs/model-capability.md b/infospace/agent/briefs/model-capability.md index 8f704e4..8e11947 100644 --- 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` diff --git a/infospace/agent/retrieval-index.json b/infospace/agent/retrieval-index.json index c7a40ab..990c052 100644 --- 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", diff --git a/infospace/agent/retrieval-index.md b/infospace/agent/retrieval-index.md index a985de8..643deba 100644 --- 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 diff --git a/infospace/agent/retrieval-index.yaml b/infospace/agent/retrieval-index.yaml index 9c136e9..9be0def 100644 --- 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 diff --git a/infospace/assimilation/it-capability-canon/ASSIMILATION.md b/infospace/assimilation/it-capability-canon/ASSIMILATION.md index 8a548d9..9236ce7 100644 --- 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. diff --git a/infospace/assimilation/it-capability-canon/open-questions.md b/infospace/assimilation/it-capability-canon/open-questions.md index 038d52f..bc4e64d 100644 --- 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 diff --git a/infospace/indexes/concept-ownership.yaml b/infospace/indexes/concept-ownership.yaml index ec24ead..c6a41db 100644 --- 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 diff --git a/infospace/models/capability/InfoTechCanonCapabilityModel.md b/infospace/models/capability/InfoTechCanonCapabilityModel.md index 9a904d3..92fc60e 100644 --- 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`. diff --git a/infospace/models/capability/capabilities.yaml b/infospace/models/capability/capabilities.yaml index 231be42..c5c1e1d 100644 --- 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. diff --git a/infospace/views/by-concept.md b/infospace/views/by-concept.md index cf8af26..afdf565 100644 --- 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` | diff --git a/workplans/ITC-WP-0014-capability-model-consolidation.md b/workplans/ITC-WP-0014-capability-model-consolidation.md index 04c4763..878db2d 100644 --- 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.