diff --git a/CHANGELOG.md b/CHANGELOG.md index e857d1d..2fbc9bb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,52 +15,6 @@ 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 9d56b5c..9e40c2a 100644 --- a/canon.yaml +++ b/canon.yaml @@ -1,7 +1,7 @@ repository: info-tech-canon title: InfoTechCanon status: service-baseline -version: 0.3.0 +version: 0.2.1 description: > An evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. @@ -93,7 +93,6 @@ 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 @@ -171,5 +170,4 @@ 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 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) + - publish ITC-WP-0014 T02 capability.schema.yaml (next ITC-CAP promotion gate) diff --git a/demand/CapabilityProvisionEconomics.md b/demand/CapabilityProvisionEconomics.md deleted file mode 100644 index b75735a..0000000 --- a/demand/CapabilityProvisionEconomics.md +++ /dev/null @@ -1,317 +0,0 @@ -# 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 8e11947..8f704e4 100644 --- a/infospace/agent/briefs/model-capability.md +++ b/infospace/agent/briefs/model-capability.md @@ -28,7 +28,6 @@ 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 990c052..c7a40ab 100644 --- a/infospace/agent/retrieval-index.json +++ b/infospace/agent/retrieval-index.json @@ -1097,7 +1097,6 @@ "kind": "model", "owned_concepts": [ "Capability", - "CapabilityConsumption", "CapabilityContract", "CapabilityDomain", "CapabilityEvidenceHook", diff --git a/infospace/agent/retrieval-index.md b/infospace/agent/retrieval-index.md index 643deba..a985de8 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`, `CapabilityConsumption`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model` +- Owned concepts: `Capability`, `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 9be0def..9c136e9 100644 --- a/infospace/agent/retrieval-index.yaml +++ b/infospace/agent/retrieval-index.yaml @@ -673,7 +673,6 @@ 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 9236ce7..8a548d9 100644 --- a/infospace/assimilation/it-capability-canon/ASSIMILATION.md +++ b/infospace/assimilation/it-capability-canon/ASSIMILATION.md @@ -178,81 +178,3 @@ 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 bc4e64d..038d52f 100644 --- a/infospace/assimilation/it-capability-canon/open-questions.md +++ b/infospace/assimilation/it-capability-canon/open-questions.md @@ -41,13 +41,6 @@ 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 c6a41db..ec24ead 100644 --- a/infospace/indexes/concept-ownership.yaml +++ b/infospace/indexes/concept-ownership.yaml @@ -1,4 +1,4 @@ -concept_count: 107 +concept_count: 106 concepts: - concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1" owner: assimilation/it-capability-canon @@ -160,10 +160,6 @@ 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 92fc60e..9a904d3 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.2.0 +version: 0.1.0 source_version: "0.1" source_body: Information Technology Capability Canon (ITCC) source_file: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md @@ -45,17 +45,16 @@ owned_concepts: - CapabilityQualityDimension - CapabilityEvidenceHook - CapabilityResourceClass - - CapabilityConsumption - CapabilityInclusionRule created_at: 2026-08-14 -updated_at: 2026-08-15 +updated_at: 2026-08-14 --- # InfoTechCanon Capability Model **Short Name:** `ITC-CAP` **Document Status:** Proposed (assimilated, not yet promoted) -**Version:** 0.2.0 +**Version:** 0.1.0 **Document Type:** InfoTechCanon Domain Model **Machine-readable catalog:** `models/capability/capabilities.yaml` **Provenance:** adapted from ITCC v0.1 — see `assimilation/it-capability-canon` @@ -89,8 +88,7 @@ Service / provider ← ITC-LAND Technology ← ITC-LAND │ consumes ▼ -Resource classes → native units ← classification owned here - (currency overlay is not owned here) +Resource classes → cost ← classification owned here ``` --- @@ -104,9 +102,7 @@ Resource classes → native units ← 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; -- 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; +- the resource classes used to attribute cost to a provision; - admission rules governing what may become a canonical capability; - the canonical capability baseline held in `capabilities.yaml`. @@ -119,11 +115,7 @@ Resource classes → native units ← 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; -- 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. +- product features, protocols, and named technologies. --- @@ -183,53 +175,26 @@ 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, 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). +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. ## 4.5 CapabilityRequirement A statement that a system, product, or consumer purpose needs a capability at a -minimum maturity. It may also select a profile, assert intended quality targets -against the capability's declared dimensions, and state placement constraints: +minimum maturity: ```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). 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. +extension) carrying a minimum maturity. It does not introduce a parallel +requirement vocabulary. ## 4.6 CapabilityProvider @@ -244,33 +209,12 @@ resource consumption all attach here. ```yaml provision: - provider: backup.barman.prod - capability: data.backup - profile: database + provider: auth.prod.eu + capability: identity.authentication environment: production - 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 + maturity: D6 ``` -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 | @@ -290,21 +234,8 @@ 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`, `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`. +`decision_latency`, `explainability`). The model names dimensions; *targets and +measurement* belong to ITC-LAND service level objectives and ITC-OBS. ## 4.10 CapabilityEvidenceHook @@ -314,65 +245,17 @@ telemetry-derived evidence comes from ITC-OBS. ## 4.11 CapabilityResourceClass -| 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 | +| 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 | -**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. +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?"). --- @@ -408,15 +291,6 @@ 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 @@ -453,19 +327,18 @@ 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 in native units | +| `consumes` | A provision consumes resource classes | -Traversal from need to consumption: +Traversal from need to cost: ```text ConsumerPurpose --requires--> Capability <--provides-- Service - │ │ implements - │ targets, constraints ▼ - ▼ Technology -CapabilityRequirement │ consumes - ▼ - C / S / N / I / H / P - (native units; unknown allowed) + │ implements + ▼ + Technology + │ consumes + ▼ + C / S / N / I / P ``` --- @@ -498,7 +371,7 @@ model. This is accepted at `proposed` status and tracked as OQ-5. | Model | Boundary | |---|---| -| 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-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-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. | @@ -537,10 +410,3 @@ 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 c5c1e1d..231be42 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.2.0 + version: 0.1.0 status: proposed - canon_version: 0.3.0 + canon_version: 0.2.1 purpose: Canonical, implementation-independent catalog of the abilities an information system may require or provide. normative_document: models/capability/InfoTechCanonCapabilityModel.md @@ -28,45 +28,23 @@ resource_classes: - id: C name: Compute description: Generic execution capacity. - 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. + note: Consumed by a capability provision, never by an abstract capability. - 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. - native_unit: GB - supply: external - capacity_behaviour: elastic - note: Consumed by a capability provision, never by an abstract capability. Native unit is transfer volume. + note: Consumed by a capability provision, never by an abstract capability. - id: I name: Intelligence - 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. + description: Metered or purchased cognitive or semantic processing capability. + note: Consumed by a capability provision, never by an abstract capability. - id: P name: Platform - 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. + description: Enabling operational overhead that makes other resources usable. + note: Consumed by a capability provision, never by an abstract capability. maturity_levels: - id: D0 name: Absent @@ -140,6 +118,11 @@ 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. @@ -162,6 +145,7 @@ 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. @@ -181,6 +165,7 @@ 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. @@ -198,6 +183,7 @@ 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. @@ -216,6 +202,7 @@ domains: evidence_hooks: - tenant_isolation_tests - membership_records + typical_resource_classes: *id001 - id: data name: Data & State navigation_only: true @@ -238,6 +225,11 @@ 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. @@ -255,6 +247,7 @@ 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. @@ -273,6 +266,7 @@ 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 @@ -295,6 +289,7 @@ domains: - successful_restore_test - measured_rpo - measured_rto + typical_resource_classes: *id002 depends_on: - data.object may_use: @@ -320,6 +315,7 @@ 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. @@ -340,6 +336,7 @@ domains: evidence_hooks: - search_tests - latency_metrics + typical_resource_classes: *id002 - id: integration name: Integration & Communication navigation_only: true @@ -363,6 +360,10 @@ 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. @@ -382,6 +383,7 @@ 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. @@ -401,6 +403,7 @@ 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. @@ -421,6 +424,7 @@ 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. @@ -440,6 +444,7 @@ domains: evidence_hooks: - routing_tests - availability_metrics + typical_resource_classes: *id003 - id: runtime name: Runtime & Automation navigation_only: true @@ -463,6 +468,11 @@ 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. @@ -482,6 +492,7 @@ 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. @@ -499,6 +510,7 @@ 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. @@ -517,6 +529,7 @@ domains: evidence_hooks: - workflow_completion_records - recovery_tests + typical_resource_classes: *id004 may_use: - integration.messaging - runtime.scheduling @@ -540,6 +553,7 @@ domains: evidence_hooks: - deployment_records - rollback_test + typical_resource_classes: *id004 - id: operations name: Operations & Assurance navigation_only: true @@ -564,6 +578,11 @@ 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. @@ -582,6 +601,7 @@ domains: evidence_hooks: - alert_tests - incident_linkage + typical_resource_classes: *id005 may_use: - operations.observability - integration.notification @@ -603,6 +623,7 @@ 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. @@ -621,6 +642,7 @@ domains: evidence_hooks: - recovery_tests - incident_recovery_records + typical_resource_classes: *id005 may_use: - data.backup - operations.observability @@ -641,6 +663,7 @@ domains: evidence_hooks: - continuity_tests - availability_metrics + typical_resource_classes: *id005 - id: security name: Security navigation_only: true @@ -663,6 +686,11 @@ 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. @@ -681,6 +709,7 @@ 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. @@ -700,6 +729,7 @@ 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. @@ -719,6 +749,7 @@ domains: evidence_hooks: - scan_results - remediation_records + typical_resource_classes: *id006 - id: governance name: Governance navigation_only: true @@ -741,6 +772,10 @@ 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 @@ -761,6 +796,7 @@ domains: - lifecycle_policy - deletion_records - retention_evidence + typical_resource_classes: *id007 - id: commerce name: Commerce navigation_only: true @@ -782,6 +818,11 @@ 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 @@ -800,6 +841,7 @@ domains: evidence_hooks: - invoice_tests - billing_reconciliation + typical_resource_classes: *id008 may_use: - commerce.metering - commerce.entitlement @@ -823,6 +865,7 @@ domains: evidence_hooks: - payment_records - settlement_reconciliation + typical_resource_classes: *id008 may_use: - identity.authentication - operations.audit @@ -846,6 +889,7 @@ domains: evidence_hooks: - entitlement_tests - decision_records + typical_resource_classes: *id008 may_use: - identity.authorization - id: intelligence @@ -868,10 +912,14 @@ 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 @@ -888,10 +936,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 @@ -906,10 +954,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 @@ -926,9 +974,9 @@ domains: - precision - ranking_quality - latency - - intelligence_intensity evidence_hooks: - retrieval_benchmarks + typical_resource_classes: *id009 may_use: - intelligence.embedding - data.search @@ -947,10 +995,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 afdf565..cf8af26 100644 --- a/infospace/views/by-concept.md +++ b/infospace/views/by-concept.md @@ -2,7 +2,7 @@ # By Concept -Concept count: **107** +Concept count: **106** | Concept | Owner | Source | | --- | --- | --- | @@ -46,7 +46,6 @@ Concept count: **107** | 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 878db2d..04c4763 100644 --- a/workplans/ITC-WP-0014-capability-model-consolidation.md +++ b/workplans/ITC-WP-0014-capability-model-consolidation.md @@ -18,7 +18,6 @@ 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" --- @@ -33,11 +32,8 @@ 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, 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. +mapping artifacts, no profile exercising it, and one unresolved identifier +question that is blocking because capability ids are durable interfaces. ## Tasks @@ -70,10 +66,6 @@ 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 @@ -143,54 +135,11 @@ 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) — the 2026-08-15 - demand needed consumption structure, which landed in ITC-CAP; invoices, - entitlements, prompts, and evaluations still have no owning model. +- New domain models for `commerce.*` / `intelligence.*` (OQ-5) — needs a real + consumer demand first. - 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.