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.