Canon 0.3.0: capability provision economics (ITC-CAP 0.2.0)
Accept resource-control demand: move resource classes onto provisions, let requirements carry targets and constraints, add human-effort class H with native-unit consumption. Model stays proposed.
This commit is contained in:
parent
9c7c1e4bdf
commit
b69b048dcb
14 changed files with 410 additions and 131 deletions
46
CHANGELOG.md
46
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)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ Imports and anchors:
|
|||
## Owned Concepts
|
||||
|
||||
- `Capability`
|
||||
- `CapabilityConsumption`
|
||||
- `CapabilityContract`
|
||||
- `CapabilityDomain`
|
||||
- `CapabilityEvidenceHook`
|
||||
|
|
|
|||
|
|
@ -1097,6 +1097,7 @@
|
|||
"kind": "model",
|
||||
"owned_concepts": [
|
||||
"Capability",
|
||||
"CapabilityConsumption",
|
||||
"CapabilityContract",
|
||||
"CapabilityDomain",
|
||||
"CapabilityEvidenceHook",
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -673,6 +673,7 @@ items:
|
|||
Model.'
|
||||
owned_concepts:
|
||||
- Capability
|
||||
- CapabilityConsumption
|
||||
- CapabilityContract
|
||||
- CapabilityDomain
|
||||
- CapabilityEvidenceHook
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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` |
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue