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 new file mode 100644 index 0000000..b75735a --- /dev/null +++ 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. 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.