From 28d5824362072d36c33eaf3b175d0df57ae9fe6c Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 14 Aug 2026 20:54:32 +0200 Subject: [PATCH] Assimilate ITCC v0.1 as Capability Model; canon 0.2.0 Define the intake and assimilation practice (incoming/ drop zone -> frozen source snapshot -> Minimal Assimilation Profile -> disposition gate -> canon transformation -> versioned change notes) and run it on the first inputs. - infospace/assimilation/intake-and-assimilation-practice.md, incoming/README.md - assimilation/it-capability-canon: frozen source, comparison matrix, 26 mappings, 8 proposed changes, 7 open questions, decision record (adapt) - new model ITC-CAP with 41-capability machine-readable catalog, anchored to owning canon models; CILM rejected, Profile renamed, Provision made explicit - registered in canon.yaml / artifacts index / infospace.yaml; regenerated briefs, indexes, views; canon version 0.1.0-scaffold -> 0.2.0 + CHANGELOG - ITC-WP-0014 for promotion work; ITC-WP-0013 added to the workplan registry make validate: ok (65 artifacts, 0 errors/warnings). make test: 22 passed. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 101 ++ canon.yaml | 27 +- incoming/README.md | 24 + infospace/agent/briefs/model-capability.md | 46 + infospace/agent/global-agent-brief.md | 4 +- infospace/agent/retrieval-index.json | 119 +- infospace/agent/retrieval-index.md | 42 +- infospace/agent/retrieval-index.yaml | 84 +- infospace/artifacts/index.yaml | 52 + infospace/assimilation/README.md | 26 + .../intake-and-assimilation-practice.md | 207 +++ .../it-capability-canon/ASSIMILATION.md | 138 ++ .../it-capability-canon/assimilation.yaml | 44 + .../it-capability-canon/comparison-matrix.md | 68 + .../extracted-concepts.yaml | 107 ++ .../it-capability-canon/mappings.yaml | 181 +++ .../it-capability-canon/open-questions.md | 56 + .../it-capability-canon/proposed-changes.md | 125 ++ .../it-capability-canon/source-summary.md | 99 ++ .../source/ITCapabilityCanonV0.1.md | 1154 +++++++++++++++++ .../source/capabilities.yaml | 787 +++++++++++ infospace/indexes/artifact-tree.yaml | 44 +- infospace/indexes/concept-ownership.yaml | 66 +- infospace/indexes/import-matrix.yaml | 30 + infospace/infospace.yaml | 2 + .../InfoTechCanonCapabilityModel.md | 411 ++++++ infospace/models/capability/capabilities.yaml | 1000 ++++++++++++++ infospace/validation/latest.json | 13 +- infospace/views/by-concept.md | 18 +- infospace/views/by-mapping-target.md | 15 + infospace/views/import-matrix.md | 130 +- infospace/views/kernel-overview.md | 14 +- infospace/views/repository-tree.md | 16 +- tests/test_cli.py | 2 +- tests/test_service.py | 13 +- ...-WP-0014-capability-model-consolidation.md | 133 ++ workplans/index.yaml | 28 + 37 files changed, 5333 insertions(+), 93 deletions(-) create mode 100644 CHANGELOG.md create mode 100644 incoming/README.md create mode 100644 infospace/agent/briefs/model-capability.md create mode 100644 infospace/assimilation/intake-and-assimilation-practice.md create mode 100644 infospace/assimilation/it-capability-canon/ASSIMILATION.md create mode 100644 infospace/assimilation/it-capability-canon/assimilation.yaml create mode 100644 infospace/assimilation/it-capability-canon/comparison-matrix.md create mode 100644 infospace/assimilation/it-capability-canon/extracted-concepts.yaml create mode 100644 infospace/assimilation/it-capability-canon/mappings.yaml create mode 100644 infospace/assimilation/it-capability-canon/open-questions.md create mode 100644 infospace/assimilation/it-capability-canon/proposed-changes.md create mode 100644 infospace/assimilation/it-capability-canon/source-summary.md create mode 100755 infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md create mode 100755 infospace/assimilation/it-capability-canon/source/capabilities.yaml create mode 100644 infospace/models/capability/InfoTechCanonCapabilityModel.md create mode 100644 infospace/models/capability/capabilities.yaml create mode 100644 workplans/ITC-WP-0014-capability-model-consolidation.md diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..76e5811 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,101 @@ +# Changelog — InfoTechCanon + +Canon versions and their change notes. Entries follow the ChangeRecord shape of +`InfoTechCanonCore` §8.13: what changed, rationale, whether it is breaking, and +what produced it. + +Versioning of `canon.yaml → version`: + +- **patch** — editorial or generated-output changes; no concept change +- **minor** — new artifact, new concepts, backward-compatible extension +- **major** — a concept is removed, renamed, or its ownership moves + +Canonical identifiers are durable interfaces; any break requires migration +semantics. + +--- + +## 0.2.0 — 2026-08-14 + +### Added — InfoTechCanon Capability Model (`ITC-CAP`) + +**Change.** The canon gains a twelfth domain model, +`infospace/models/capability/InfoTechCanonCapabilityModel.md`, with its +machine-readable baseline at `infospace/models/capability/capabilities.yaml`: +41 capabilities across 8 navigation domains, the D0–D7 provision maturity scale, +the C/S/N/I/P resource classes, capability relationship types, and admission +rules. + +New canonical concepts: `Capability`, `CapabilityDomain`, `CapabilityProfile`, +`CapabilityContract`, `CapabilityRequirement`, `CapabilityProvider`, +`CapabilityProvision`, `CapabilityMaturityLevel`, `CapabilityQualityDimension`, +`CapabilityEvidenceHook`, `CapabilityResourceClass`, `CapabilityInclusionRule`. + +**Rationale.** The canon modelled landscape, data, security, delivery, network, +observability, governance, organization, task, and access — but never *what an +information system must be able to do*. The Landscape Model deferred this ground +explicitly (§11.4). Consumers were already working around the gap. + +**Source and disposition.** Adapted from the Information Technology Capability +Canon (ITCC) v0.1 under assimilation `assimilation/it-capability-canon`, +disposition `adapt`. Changes made on adoption: + +- `Profile` renamed to `CapabilityProfile` — the name collided with the canon + `Profile` artifact type (Core §8.6); +- `CapabilityProvision` made explicit, so maturity has a defined bearer; +- per-capability `anchors` added, naming the canon model(s) owning the concepts + each capability exercises (guards Core §6.2 and §6.3); +- `CapabilityRequirement` bound to the Purpose and Demand extension as a typed + `DemandSignal` rather than a parallel vocabulary; +- the source's proposed CILM landscape model **rejected** — the Landscape Model + already owns that ground; +- capability definitions held only in YAML; the Markdown does not restate them. + +**Breaking:** no. No existing canonical concept was removed, renamed, or moved. + +**Artifact status.** The model enters at `proposed`. Promotion requires +resolution of open question OQ-2 (the `governance.*` id prefix), a published +contract schema, formal mapping artifacts, and one profile expressing a real +requirement set with evidence — tracked in `ITC-WP-0014`. + +**Known weakness.** Seven capabilities (`commerce.*` except `entitlement`, and +four `intelligence.*`) are unanchored — new canon surface with no owning model +(OQ-5). Accepted at `proposed` status. + +### Added — Intake and Assimilation Practice + +`infospace/assimilation/intake-and-assimilation-practice.md` defines the +repository-wide procedure for absorbing new concepts and terminology: the +`incoming/` drop zone, frozen source snapshots, the Minimal Assimilation Profile, +the disposition gate, canon transformation and registration, and the resulting +canon version with change notes. `incoming/README.md` documents the drop zone. + +**Rationale.** Inputs previously had no defined path from arrival to canon, +risking the copy-paste assimilation Core §29.6 warns against. + +### Changed + +- `canon.yaml` — version `0.1.0-scaffold` → `0.2.0`; `itc-cap` registered under + `models:` with assimilation provenance. +- `infospace/artifacts/index.yaml` — registered `model/capability`, + `capability-catalog/itc-cap`, `assimilation/it-capability-canon`, + `practice/intake-and-assimilation` (65 artifacts, up from 61). +- `infospace/infospace.yaml` — Capability Model added to disciplines. +- Regenerated agent briefs, retrieval indexes, and views. +- `tests/` — artifact and model counts updated to match the registered canon. +- `workplans/index.yaml` — registered `ITC-WP-0014`, and `ITC-WP-0013` which was + missing from the registry. + +### Validation + +`make validate` passes with 0 errors and 0 warnings (65 artifacts, 286 +relationships, 0 consistency cycles, coverage 1.0, redundancy 0.0). +`make test` passes (22 tests). + +--- + +## 0.1.0-scaffold + +Seed kernel: kernel documents, eleven domain models, three standards, the +infospace scaffold, service surface (CLI / JSON / API), generated views and +agent briefs. See `workplans/` ITC-WP-0001 through ITC-WP-0012 for the history. diff --git a/canon.yaml b/canon.yaml index c79e194..06da2d1 100644 --- a/canon.yaml +++ b/canon.yaml @@ -1,7 +1,7 @@ repository: info-tech-canon title: InfoTechCanon status: service-baseline -version: 0.1.0-scaffold +version: 0.2.0 description: > An evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. @@ -89,6 +89,16 @@ models: title: InfoTechCanonObservabilityModel path: infospace/models/observability/InfoTechCanonObservabilityModel.md status: RC1-seed + - id: itc-cap + title: InfoTechCanonCapabilityModel + path: infospace/models/capability/InfoTechCanonCapabilityModel.md + status: proposed + catalog: infospace/models/capability/capabilities.yaml + provenance: + assimilation: assimilation/it-capability-canon + source_body: Information Technology Capability Canon (ITCC) + source_version: "0.1" + disposition: adapt standards: - id: itc-tag @@ -131,6 +141,20 @@ workplans: - ITC-WP-0008 - ITC-WP-0009 - ITC-WP-0010 + - ITC-WP-0011 + - ITC-WP-0012 + - ITC-WP-0013 + - ITC-WP-0014 + +assimilation: + practice: infospace/assimilation/intake-and-assimilation-practice.md + intake_dir: incoming/ + records: + - id: assimilation/it-capability-canon + source: Information Technology Capability Canon (ITCC) v0.1 + disposition: adapt + status: closed + produced: itc-cap first_proofs: near_term: @@ -146,3 +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 + - resolve ITC-WP-0014 T01 capability identifier prefix (blocks ITC-CAP promotion) diff --git a/incoming/README.md b/incoming/README.md new file mode 100644 index 0000000..663624a --- /dev/null +++ b/incoming/README.md @@ -0,0 +1,24 @@ +# incoming/ + +Drop zone for raw, un-reviewed material proposed for absorption into +InfoTechCanon: external standards, vocabularies, product schemas, internal +drafts, and their machine-readable companions. + +**Rules** + +- Files land here unedited and stay unedited. +- No canon artifact may reference a path under `incoming/` — nothing here is + part of the canon. +- This directory is expected to be empty after a processing session. Anything + left here is unprocessed backlog. + +**Processing** + +Follow `infospace/assimilation/intake-and-assimilation-practice.md`. In short: +`git mv` the input into `infospace/assimilation//source/` as a frozen +snapshot, produce the assimilation workspace, record a disposition, and — if +adopted — transform it into a canon artifact and cut a new canon version with +notes in `CHANGELOG.md`. + +If an input is a *need* rather than a body of knowledge, it belongs in `demand/` +with a workplan, not here. diff --git a/infospace/agent/briefs/model-capability.md b/infospace/agent/briefs/model-capability.md new file mode 100644 index 0000000..8f704e4 --- /dev/null +++ b/infospace/agent/briefs/model-capability.md @@ -0,0 +1,46 @@ +--- +id: agent-brief/model-capability +artifact_id: model/capability +source_path: models/capability/InfoTechCanonCapabilityModel.md +source_kind: model +generated: true +--- + + + +# Agent Brief: InfoTechCanon Capability Model + +- Artifact ID: `model/capability` +- Kind: `model` +- Canonical path: `models/capability/InfoTechCanonCapabilityModel.md` +- Full source: `models/capability/InfoTechCanonCapabilityModel.md` +- Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model. + +## Retrieval Hints + +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` + +## Related Distinctions + +No common distinction is anchored directly on this artifact. diff --git a/infospace/agent/global-agent-brief.md b/infospace/agent/global-agent-brief.md index 691a5bc..707ca48 100644 --- a/infospace/agent/global-agent-brief.md +++ b/infospace/agent/global-agent-brief.md @@ -5,8 +5,8 @@ This brief summarizes the current canon service surface for agents. - Infospace slug: `canon` -- Artifact count: 61 -- Retrieval index items: 61 +- Artifact count: 65 +- Retrieval index items: 65 - Primary confidence command: `make validate` - Refresh generated indexes and views with: `make index` - Refresh agent briefs and interface templates with: `make agent-briefs` diff --git a/infospace/agent/retrieval-index.json b/infospace/agent/retrieval-index.json index 89a8385..c7a40ab 100644 --- a/infospace/agent/retrieval-index.json +++ b/infospace/agent/retrieval-index.json @@ -43,8 +43,29 @@ } ], "infospace": "canon", - "item_count": 61, + "item_count": 65, "items": [ + { + "canonical_path": "assimilation/it-capability-canon/ASSIMILATION.md", + "id": "assimilation/it-capability-canon", + "imports": [ + "kernel/itc-core" + ], + "kind": "assimilation", + "owned_concepts": [ + "Assimilation \u2014 IT Capability Canon (ITCC) v0.1" + ], + "relationships": [ + { + "target": "kernel/itc-core", + "type": "conforms_to" + } + ], + "source_path": "infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md", + "summary": "Canon artifact: Assimilation \u2014 IT Capability Canon (ITCC) v0.1.", + "title": "Assimilation \u2014 IT Capability Canon (ITCC) v0.1", + "warnings": [] + }, { "canonical_path": "standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml", "id": "benchmark/caring/kubernetes-rbac", @@ -232,6 +253,20 @@ "title": "Kubernetes RBAC Native Concept Map", "warnings": [] }, + { + "canonical_path": "models/capability/capabilities.yaml", + "id": "capability-catalog/itc-cap", + "imports": [], + "kind": "capability-catalog", + "owned_concepts": [ + "InfoTechCanon Capability Catalog" + ], + "relationships": [], + "source_path": "infospace/assimilation/it-capability-canon/source/capabilities.yaml", + "summary": "Canon artifact: InfoTechCanon Capability Catalog.", + "title": "InfoTechCanon Capability Catalog", + "warnings": [] + }, { "canonical_path": "evaluations/repo-scoping/canon-benefit-analysis.yaml", "id": "comparison/repo-scoping/canon-benefit-analysis", @@ -1049,6 +1084,67 @@ "title": "InfoTechCanon Access Control Model", "warnings": [] }, + { + "canonical_path": "models/capability/InfoTechCanonCapabilityModel.md", + "id": "model/capability", + "imports": [ + "kernel/itc-core", + "model/governance", + "model/landscape", + "model/observability", + "model/purpose-demand-extension" + ], + "kind": "model", + "owned_concepts": [ + "Capability", + "CapabilityContract", + "CapabilityDomain", + "CapabilityEvidenceHook", + "CapabilityInclusionRule", + "CapabilityMaturityLevel", + "CapabilityProfile", + "CapabilityProvider", + "CapabilityProvision", + "CapabilityQualityDimension", + "CapabilityRequirement", + "CapabilityResourceClass", + "InfoTechCanon Capability Model" + ], + "relationships": [ + { + "target": "kernel/itc-core", + "type": "conforms_to" + }, + { + "target": "model/landscape", + "type": "uses" + }, + { + "target": "model/governance", + "type": "uses" + }, + { + "target": "model/purpose-demand-extension", + "type": "uses" + }, + { + "target": "model/observability", + "type": "uses" + }, + { + "target": "capability-catalog/itc-cap", + "type": "introduces" + }, + { + "target": "assimilation/it-capability-canon", + "type": "derived_from" + } + ], + "source_path": "infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md", + "summary": "Domain model used by canon profiles and standards: InfoTechCanon Capability Model.", + "title": "InfoTechCanon Capability Model", + "warnings": [] + }, { "canonical_path": "models/data/InfoTechCanonDataModel.md", "id": "model/data", @@ -1363,6 +1459,27 @@ "title": "Intent Scope Purposes Pattern", "warnings": [] }, + { + "canonical_path": "assimilation/intake-and-assimilation-practice.md", + "id": "practice/intake-and-assimilation", + "imports": [ + "kernel/itc-core" + ], + "kind": "practice", + "owned_concepts": [ + "Intake and Assimilation Practice" + ], + "relationships": [ + { + "target": "kernel/itc-core", + "type": "conforms_to" + } + ], + "source_path": "assimilation/intake-and-assimilation-practice.md", + "summary": "Canon artifact: Intake and Assimilation Practice.", + "title": "Intake and Assimilation Practice", + "warnings": [] + }, { "canonical_path": "profiles/small-saas/profile.yaml", "id": "profile/small-saas", diff --git a/infospace/agent/retrieval-index.md b/infospace/agent/retrieval-index.md index ae8474a..a985de8 100644 --- a/infospace/agent/retrieval-index.md +++ b/infospace/agent/retrieval-index.md @@ -4,7 +4,7 @@ Schema: `info-tech-canon.retrieval-index.v1` Infospace: `canon` -Items: **61** +Items: **65** ## Common Distinctions @@ -15,6 +15,16 @@ Items: **61** ## Items +### Assimilation — IT Capability Canon (ITCC) v0.1 + +- ID: `assimilation/it-capability-canon` +- Kind: `assimilation` +- Canonical path: `assimilation/it-capability-canon/ASSIMILATION.md` +- Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md` +- Summary: Canon artifact: Assimilation — IT Capability Canon (ITCC) v0.1. +- Imports and anchors: `kernel/itc-core` +- Owned concepts: `Assimilation — IT Capability Canon (ITCC) v0.1` + ### CARING Kubernetes RBAC Benchmark - ID: `benchmark/caring/kubernetes-rbac` @@ -65,6 +75,16 @@ Items: **61** - Imports and anchors: none - Owned concepts: `Kubernetes RBAC Native Concept Map` +### InfoTechCanon Capability Catalog + +- ID: `capability-catalog/itc-cap` +- Kind: `capability-catalog` +- Canonical path: `models/capability/capabilities.yaml` +- Source path: `infospace/assimilation/it-capability-canon/source/capabilities.yaml` +- Summary: Canon artifact: InfoTechCanon Capability Catalog. +- Imports and anchors: none +- Owned concepts: `InfoTechCanon Capability Catalog` + ### Repo Scoping Canon Benefit Analysis - ID: `comparison/repo-scoping/canon-benefit-analysis` @@ -275,6 +295,16 @@ Items: **61** - Imports and anchors: `kernel/itc-core`, `model/governance`, `model/organization` - Owned concepts: `InfoTechCanon Access Control Model` +### InfoTechCanon Capability Model + +- ID: `model/capability` +- Kind: `model` +- Canonical path: `models/capability/InfoTechCanonCapabilityModel.md` +- 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` + ### InfoTechCanon Data Model - ID: `model/data` @@ -395,6 +425,16 @@ Items: **61** - Imports and anchors: `model/governance`, `model/task` - Owned concepts: `Intent Scope Purposes Pattern`, `IntentScopePurposePattern` +### Intake and Assimilation Practice + +- ID: `practice/intake-and-assimilation` +- Kind: `practice` +- Canonical path: `assimilation/intake-and-assimilation-practice.md` +- Source path: `assimilation/intake-and-assimilation-practice.md` +- Summary: Canon artifact: Intake and Assimilation Practice. +- Imports and anchors: `kernel/itc-core` +- Owned concepts: `Intake and Assimilation Practice` + ### Small SaaS System Profile - ID: `profile/small-saas` diff --git a/infospace/agent/retrieval-index.yaml b/infospace/agent/retrieval-index.yaml index 4a7adaa..9c136e9 100644 --- a/infospace/agent/retrieval-index.yaml +++ b/infospace/agent/retrieval-index.yaml @@ -1,7 +1,21 @@ schema: info-tech-canon.retrieval-index.v1 infospace: canon -item_count: 61 +item_count: 65 items: +- id: assimilation/it-capability-canon + kind: assimilation + title: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1" + canonical_path: assimilation/it-capability-canon/ASSIMILATION.md + source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md + summary: "Canon artifact: Assimilation \u2014 IT Capability Canon (ITCC) v0.1." + owned_concepts: + - "Assimilation \u2014 IT Capability Canon (ITCC) v0.1" + imports: + - kernel/itc-core + relationships: + - type: conforms_to + target: kernel/itc-core + warnings: [] - id: benchmark/caring/kubernetes-rbac kind: benchmark-workspace title: CARING Kubernetes RBAC Benchmark @@ -119,6 +133,17 @@ items: - type: maps target: model/landscape warnings: [] +- id: capability-catalog/itc-cap + kind: capability-catalog + title: InfoTechCanon Capability Catalog + canonical_path: models/capability/capabilities.yaml + source_path: infospace/assimilation/it-capability-canon/source/capabilities.yaml + summary: 'Canon artifact: InfoTechCanon Capability Catalog.' + owned_concepts: + - InfoTechCanon Capability Catalog + imports: [] + relationships: [] + warnings: [] - id: comparison/repo-scoping/canon-benefit-analysis kind: benefit-analysis title: Repo Scoping Canon Benefit Analysis @@ -639,6 +664,49 @@ items: - type: uses target: model/governance warnings: [] +- id: model/capability + kind: model + title: InfoTechCanon Capability Model + canonical_path: models/capability/InfoTechCanonCapabilityModel.md + source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md + summary: 'Domain model used by canon profiles and standards: InfoTechCanon Capability + Model.' + owned_concepts: + - Capability + - CapabilityContract + - CapabilityDomain + - CapabilityEvidenceHook + - CapabilityInclusionRule + - CapabilityMaturityLevel + - CapabilityProfile + - CapabilityProvider + - CapabilityProvision + - CapabilityQualityDimension + - CapabilityRequirement + - CapabilityResourceClass + - InfoTechCanon Capability Model + imports: + - kernel/itc-core + - model/governance + - model/landscape + - model/observability + - model/purpose-demand-extension + relationships: + - type: conforms_to + target: kernel/itc-core + - type: uses + target: model/landscape + - type: uses + target: model/governance + - type: uses + target: model/purpose-demand-extension + - type: uses + target: model/observability + - type: introduces + target: capability-catalog/itc-cap + - type: derived_from + target: assimilation/it-capability-canon + warnings: [] - id: model/data kind: model title: InfoTechCanon Data Model @@ -858,6 +926,20 @@ items: - type: uses target: model/task warnings: [] +- id: practice/intake-and-assimilation + kind: practice + title: Intake and Assimilation Practice + canonical_path: assimilation/intake-and-assimilation-practice.md + source_path: assimilation/intake-and-assimilation-practice.md + summary: 'Canon artifact: Intake and Assimilation Practice.' + owned_concepts: + - Intake and Assimilation Practice + imports: + - kernel/itc-core + relationships: + - type: conforms_to + target: kernel/itc-core + warnings: [] - id: profile/small-saas kind: profile title: Small SaaS System Profile diff --git a/infospace/artifacts/index.yaml b/infospace/artifacts/index.yaml index b33df05..2e5b4f6 100644 --- a/infospace/artifacts/index.yaml +++ b/infospace/artifacts/index.yaml @@ -107,6 +107,58 @@ artifacts: target: model/task - type: introduces target: concept-catalog/purpose-demand + - id: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + kind: model + title: InfoTechCanon Capability Model + provenance: + source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md + placement: adapted + assimilation: assimilation/it-capability-canon + source_body: Information Technology Capability Canon (ITCC) v0.1 + relationships: + - type: conforms_to + target: kernel/itc-core + - type: uses + target: model/landscape + - type: uses + target: model/governance + - type: uses + target: model/purpose-demand-extension + - type: uses + target: model/observability + - type: introduces + target: capability-catalog/itc-cap + - type: derived_from + target: assimilation/it-capability-canon + - id: capability-catalog/itc-cap + path: models/capability/capabilities.yaml + kind: capability-catalog + title: InfoTechCanon Capability Catalog + provenance: + source_path: infospace/assimilation/it-capability-canon/source/capabilities.yaml + placement: adapted + assimilation: assimilation/it-capability-canon + relationships: [] + - id: assimilation/it-capability-canon + path: assimilation/it-capability-canon/ASSIMILATION.md + kind: assimilation + title: Assimilation — IT Capability Canon (ITCC) v0.1 + provenance: + source_path: infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md + disposition: adapt + relationships: + - type: conforms_to + target: kernel/itc-core + - id: practice/intake-and-assimilation + path: assimilation/intake-and-assimilation-practice.md + kind: practice + title: Intake and Assimilation Practice + provenance: + placement: authored + relationships: + - type: conforms_to + target: kernel/itc-core - id: model/task path: models/task/InfoTechCanonTaskModel.md kind: model diff --git a/infospace/assimilation/README.md b/infospace/assimilation/README.md index de78711..3e2e0ad 100644 --- a/infospace/assimilation/README.md +++ b/infospace/assimilation/README.md @@ -1,3 +1,29 @@ # Assimilation Assimilation records for external knowledge and consumer demand live here. + +The procedure that governs them — from the `incoming/` drop zone through frozen +source snapshots, comparison, disposition, canon transformation, and the +resulting canon version — is +[`intake-and-assimilation-practice.md`](intake-and-assimilation-practice.md). + +Each assimilation is one directory: + +```text +/ + assimilation.yaml record (schemas/assimilation.schema.yaml) + ASSIMILATION.md scope, findings, decision record + source/ frozen snapshot of the processed input + source-summary.md + extracted-concepts.yaml + comparison-matrix.md + mappings.yaml + proposed-changes.md + open-questions.md +``` + +## Records + +| Assimilation | Source | Disposition | Status | +|---|---|---|---| +| [`it-capability-canon`](it-capability-canon/) | Information Technology Capability Canon (ITCC) v0.1 | adapt | decided | diff --git a/infospace/assimilation/intake-and-assimilation-practice.md b/infospace/assimilation/intake-and-assimilation-practice.md new file mode 100644 index 0000000..a5656d2 --- /dev/null +++ b/infospace/assimilation/intake-and-assimilation-practice.md @@ -0,0 +1,207 @@ +# Intake and Assimilation Practice + +**Status:** Practice (normative for this repository) +**Applies to:** every external or internally-drafted document, schema, vocabulary, +or model proposed for absorption into InfoTechCanon +**Anchors:** `InfoTechCanonCore` §14 (Assimilation Model), §8.13 (ChangeRecord), +§8.14 (DecisionRecord), §27.4 (Minimal Assimilation Profile) + +--- + +## 1. Why this exists + +New concepts and terminology arrive continuously — from consumers, from external +standards, from Bernd's own drafts. Without a fixed pipeline they either rot in a +drop directory or get pasted into the canon without comparison, which is the +anti-pattern Core §29.6 names explicitly ("Assimilation by copy-paste"). + +This practice defines the full path: + +```text +incoming/ drop zone, un-reviewed, never referenced by canon + │ (1) intake + ▼ +infospace/assimilation//source/ processed input, frozen snapshot + │ (2) scope, extract, compare + ▼ +infospace/assimilation// assimilation workspace + proposals + │ (3) disposition decision ← human gate + ▼ +infospace/{models,standards,...}/ canon change (adopt / adapt) + │ (4) register + regenerate + validate + ▼ +canon.yaml version bump + CHANGELOG.md new canon version with change notes +``` + +**Governing rule (Core §14.7):** assimilation produces *proposals*, not automatic +canon changes. Steps 1–2 may run unattended. Step 3 requires an explicit +disposition recorded by the canon owner. + +--- + +## 2. The drop zone: `incoming/` + +- `incoming/` holds raw, un-reviewed inputs exactly as received. Do not edit them. +- Nothing in the canon (`canon.yaml`, `infospace/artifacts/index.yaml`, links from + canon documents) may reference a path under `incoming/`. +- An input may be several files (a Markdown document plus its machine-readable + companion). Keep them together; they assimilate as one unit. +- `incoming/` is expected to be **empty** after a processing session. A file + remaining there is an unprocessed backlog item, not a resting place. + +Related but distinct front doors — do not confuse them: + +| Directory | Holds | Next step | +|---|---|---| +| `incoming/` | raw candidate material to absorb | this practice | +| `demand/` | a stated consumer need, not yet a document | workplan + design | +| `seeds/` | historical provenance of first-generation canon files | frozen | + +If an input turns out to be a *need* rather than a *body of knowledge*, move it to +`demand/` and open a workplan instead of an assimilation workspace. + +--- + +## 3. Stage 1 — Intake + +Create the workspace and move the input into it. Use `git mv` so the provenance +chain stays visible in history. + +```bash +slug= +mkdir -p infospace/assimilation/$slug/source +git mv incoming/ infospace/assimilation/$slug/source/ +``` + +The snapshot under `source/` is **frozen**: it is the evidence of what was +assimilated and what version it was. Later revisions of the same external body +arrive as a new intake with a new `source_version`, never as an edit in place. + +Write `infospace/assimilation//assimilation.yaml` conforming to +`infospace/schemas/assimilation.schema.yaml`: + +```yaml +id: assimilation/ +title: +source: +source_version: "" +source_type: external-standard | internal-draft | product-schema | ... +source_files: [source/, ...] +requested_by: +status: intake | scoping | analysis | proposed | decided | closed +disposition: observe | map | adopt | adapt | reject # provisional until stage 3 +impacts: [] +``` + +## 4. Stage 2 — Scoping, extraction, comparison + +Produce the Minimal Assimilation Profile (Core §27.4). One file per output so +each can be reviewed and diffed independently: + +| File | Content | +|---|---| +| `ASSIMILATION.md` | the record: scope, stages, findings, recommendation | +| `source-summary.md` | faithful précis of the input, no canon opinion | +| `extracted-concepts.yaml` | every concept the input introduces, with its own terms | +| `comparison-matrix.md` | each extracted concept classified against the canon | +| `mappings.yaml` | concept-level mappings to existing canon owners | +| `proposed-changes.md` | concrete, reviewable canon change proposals | +| `open-questions.md` | unresolved issues blocking or following adoption | + +Classify every extracted concept with one of the Core §14.6 result categories: +`already_covered`, `covered_differently`, `broader_than_existing`, +`narrower_than_existing`, `missing_concept`, `conflicting_concept`, +`implementation_detail_only`, `viewpoint_difference`, +`terminology_difference_only`. + +Two canon principles decide most rows: + +- **Single canonical owner** (Core §6.2) — a concept has exactly one owning + artifact. If the input redefines something an existing model owns, that is a + mapping or a conflict, never a second definition. +- **Import, do not redefine** (Core §6.3) — where the input needs a concept the + canon already owns, the proposal is an import, not a copy. + +## 5. Stage 3 — Disposition (human gate) + +The canon owner records one disposition for the assimilation as a whole, and, where +they differ, per proposed change: + +| Disposition | Meaning | Canon effect | +|---|---|---| +| `observe` | recorded, no change yet | workspace only | +| `map` | related to canon via mappings | `infospace/mappings/` entries | +| `adopt` | taken in essentially as-is | new/extended canon artifact | +| `adapt` | taken in, restructured to canon shape | new/extended canon artifact | +| `reject` | out of scope or conflicting | rationale in the record | + +Record the decision in `ASSIMILATION.md` as a DecisionRecord (Core §8.14): +Context, Decision, Options Considered, Rationale, Consequences, Review Trigger. +Set `status: decided` and the final `disposition` in `assimilation.yaml`. + +For `adopt`/`adapt`, open a workplan (`workplans/ITC-WP-NNNN-.md`) for any +follow-on work that is not completed in the same session — mappings to sibling +models, profiles, schemas, consumer alignment notes. + +## 6. Stage 4 — Transforming into the canon + +When adopting or adapting, the new artifact is written in canon shape, not pasted: + +1. **Place** it under the correct classification — `infospace/models//` + for a broad domain structure, `infospace/standards//` for a cross-cutting + convention or named framework, `infospace/patterns/`, `infospace/profiles/`. +2. **Head it with canon frontmatter** — `id`, `title`, `short_name`, `type`, + `status`, `version`, `source_version`, `source_file`, `canonical_owner`, + `namespace`, `imports`, `related`, `owned_concepts`, `created_at`, `updated_at`. + `source_version` and `source_file` preserve the provenance chain back to the + frozen snapshot (see CARING for the reference example). +3. **Separate normative prose from data.** Human-readable normative content goes + in the Markdown; enumerations, catalogs and baselines go in a sibling YAML that + is the single machine-readable source of truth. Do not maintain the same list + in both. +4. **Declare owned concepts and imports** so ownership stays checkable, and add + the imported-from relationships rather than restating imported definitions. +5. **Register** the artifact: + - `canon.yaml` — `kernel:` / `models:` / `standards:` entry with `path` and `status` + - `infospace/artifacts/index.yaml` — `id`, `path`, `kind`, `title`, `provenance` + (with `source_path` pointing at the frozen snapshot), `relationships` + - `infospace/infospace.yaml` — `disciplines:` entry for the primary document +6. **Regenerate and validate**: + ```bash + make agent-briefs && make index && make tree + make validate && make test + ``` + Generated files (agent briefs, retrieval indexes, views) carry a + `GENERATED` notice — never hand-edit them; fix the source and regenerate. + +## 7. Stage 5 — New canon version with change notes + +A canon change that adds, removes, or redefines canonical concepts produces a new +canon version. + +- **Version field:** `canon.yaml → version`, semantic: + - *patch* — editorial, generated output, no concept change; + - *minor* — new artifact, new concepts, backward-compatible extension; + - *major* — a concept is removed, renamed, or its ownership moves; identifiers + are durable interfaces, so any break requires migration semantics. +- **Change notes:** every version gets an entry in `CHANGELOG.md` at the repo root, + structured as a ChangeRecord (Core §8.13): what changed, rationale, whether it is + breaking, what it supersedes, and the assimilation or workplan that produced it. +- **Artifact status:** a newly assimilated artifact enters at `proposed` or + `draft` status and is promoted only after practical use, even when the canon + version itself is released. +- Close the loop: set the assimilation `status: closed`, add a progress event, and + run `statehub fix-consistency` if workplan files changed. + +## 8. Session checklist + +```text +[ ] incoming/ is empty (every input intaken or routed to demand/) +[ ] each input has a frozen source/ snapshot and an assimilation.yaml +[ ] Minimal Assimilation Profile files exist and every concept is classified +[ ] disposition recorded as a DecisionRecord +[ ] adopted artifacts registered in canon.yaml, artifacts/index.yaml, infospace.yaml +[ ] make agent-briefs && make index && make tree && make validate && make test pass +[ ] canon.yaml version bumped and CHANGELOG.md entry written +[ ] follow-on workplan opened for anything deferred +``` diff --git a/infospace/assimilation/it-capability-canon/ASSIMILATION.md b/infospace/assimilation/it-capability-canon/ASSIMILATION.md new file mode 100644 index 0000000..bace9f2 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/ASSIMILATION.md @@ -0,0 +1,138 @@ +# Assimilation — Information Technology Capability Canon (ITCC) v0.1 + +**Record:** `assimilation/it-capability-canon` +**Source:** ITCC v0.1 (`source/ITCapabilityCanonV0.1.md`, `source/capabilities.yaml`) +**Disposition:** `adapt` +**Status:** decided +**Canon version produced:** `0.2.0` +**Date:** 2026-08-14 +**Practice:** [`../intake-and-assimilation-practice.md`](../intake-and-assimilation-practice.md) + +--- + +## 1. Intake + +Both files arrived in `incoming/` and were moved unmodified into `source/` as the +frozen snapshot. The source document itself (§15) asks to be reconciled with and +incorporated into InfoTechCanon, so the request is explicit rather than inferred. + +## 2. Scoping + +**In scope:** the capability object model, inclusion rules, exclusions, the eight +navigation domains and 41-capability baseline, capability relationship types, the +D0–D7 maturity scale, the C/S/N/I/P resource model, evidence hooks, and the +capability contract shape. + +**Out of scope:** the proposed CILM landscape model (§15) — the canon Landscape +Model already owns that ground; and the FinOps cost formula (§13) beyond the +resource classification itself. + +## 3. Concept extraction + +18 concepts extracted — see [`extracted-concepts.yaml`](extracted-concepts.yaml). + +## 4. Concept comparison + +See [`comparison-matrix.md`](comparison-matrix.md). Summary: + +- `missing_concept`: Capability, CapabilityDomain, Provision, MaturityLevel, + QualityDimension, EvidenceHook, CapabilityContract, ResourceClass, and the + capability relationship types +- `already_covered`: Implementation, Evidence, CILM, and four of the source's + design principles (all four restate existing Core principles) +- `covered_differently`: Profile (name collision with Core §8.6), Provider +- `narrower_than_existing`: Requirement (a typed DemandSignal), quality dimensions +- `viewpoint_difference`: the entire capability baseline against the domain models + — abilities versus the structures that realize them +- `conflicting_concept`: one naming conflict only (`governance.*` prefix, OQ-2) + +## 5. Gap and conflict analysis + +**Primary gap filled.** The canon models landscape, data, security, delivery, +network, observability, governance, organization, task, and access, but nowhere +states *what an information system must be able to do*. The Landscape Model +defers exactly this (§11.4). Consumers hit the gap in practice: repo-scoping +already needs `Ability` / `Capability` / `Feature` distinctions. + +**No definitional conflicts.** Not one source concept redefines a concept an +existing model owns. The relationship is anchoring, not overlap — which is why +the disposition is `adapt` rather than `observe`. + +**Conflicts found:** (1) `Profile` name collision, resolved by renaming to +`CapabilityProfile`; (2) inconsistent `governance.*` ID prefix, unresolved and +recorded as OQ-2, blocking promotion beyond `proposed`. + +**Risk.** A capability catalog is the kind of artifact that quietly becomes a +second ontology. Mitigated by PC-3: every capability must name the canon model(s) +that own the concepts it exercises. + +## 6. Canon impact proposal + +Eight proposals — see [`proposed-changes.md`](proposed-changes.md). All eight were +accepted; PC-6 is an accepted *rejection* (CILM not adopted). Six further items +are deferred to `ITC-WP-0014`. + +## 7. Mapping and publication + +[`mappings.yaml`](mappings.yaml) records 26 concept-level mappings to canonical +owners. Formal per-pair mapping artifacts under `infospace/mappings/` are deferred +to ITC-WP-0014. + +Published as: + +- `infospace/models/capability/InfoTechCanonCapabilityModel.md` +- `infospace/models/capability/capabilities.yaml` + +--- + +## Decision Record + +**Context.** InfoTechCanon has no owner for abstract capability. A well-formed +draft vocabulary (41 capabilities, machine-readable, explicitly written for +reconciliation with InfoTechCanon) was submitted for absorption. The Landscape +Model has deferred this ground since RC1. + +**Decision.** Disposition `adapt`. Adopt the vocabulary as a new domain model, +`InfoTechCanonCapabilityModel`, restructured to canon shape: canon frontmatter and +declared ownership, imports instead of redefinitions, per-capability anchors to +owning models, `Profile` renamed to `CapabilityProfile`, `Provision` made +explicit, CILM rejected. The artifact enters at status `proposed`. + +**Options considered.** + +1. *`observe`* — record and change nothing. Rejected: leaves a known gap open while + consumers work around it. +2. *`map` only* — map the source to existing models without a new artifact. + Rejected: there is no artifact to map *to*; capability has no owner. +3. *`adopt` as-is* — take the document in unchanged. Rejected: it carries a name + collision on `Profile`, a competing landscape model, an implicit provision + bearer, and no anchoring to canon owners. +4. *`adapt`* — chosen. +5. *Classify as a standard rather than a model.* Deferred as OQ-1; a capability + set is a broad domain structure, which is the definition of a model here. + +**Rationale.** The source passes its own inclusion rules and the canon's: +implementation-independent, reusable, demandable, providable, testable, +profileable, stable. It conflicts with nothing the canon already owns. The two +genuinely new surfaces (`commerce.*`, `intelligence.*`) extend the canon into +areas no existing model reaches. Adapting rather than adopting preserves single +canonical ownership. + +**Consequences.** + +- Canon version `0.2.0`; the canon gains a twelfth model and 41 capability IDs + that are treated as durable interfaces from here on. +- The Landscape Model's deferred strategy/capability concepts + (`BusinessCapability`, `ProductCapability`) now have a destination; the + Landscape §11.4 note should be revised — deferred to ITC-WP-0014. +- Capability IDs must not be renamed without migration semantics, which makes + OQ-2 blocking for promotion. +- `commerce.*` and `intelligence.*` create canon surface with no anchoring model + (OQ-5), an accepted weakness at `proposed` status. + +**Review trigger.** Promotion beyond `proposed` requires: OQ-2 resolved, the +contract schema published, and at least one profile expressing a real capability +requirement set with evidence. + +**Supersession.** None. A later ITCC revision arrives as a new intake with a new +`source_version`, never as an edit to this frozen snapshot. diff --git a/infospace/assimilation/it-capability-canon/assimilation.yaml b/infospace/assimilation/it-capability-canon/assimilation.yaml new file mode 100644 index 0000000..1713a75 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/assimilation.yaml @@ -0,0 +1,44 @@ +id: assimilation/it-capability-canon +title: Information Technology Capability Canon (ITCC) v0.1 +source: Information Technology Capability Canon (ITCC) v0.1 +source_version: "0.1" +source_type: internal-draft +source_files: + - source/ITCapabilityCanonV0.1.md + - source/capabilities.yaml +reason: > + Standalone draft capability vocabulary written to be reconciled with and + incorporated into InfoTechCanon (source document section 15). Fills the + capability gap the Landscape Model explicitly defers (section 11.4). +requested_by: bernd +owner: info-tech-canon +scope: > + The abstract capability vocabulary, its profile/provider/implementation/ + resource/evidence/maturity object model, relationship types, and the 41 + capability baseline. Excludes the source document's proposed CILM + landscape-state model, which the Landscape Model already owns. +status: decided +disposition: adapt +impacts: + - model/capability + - model/landscape + - model/governance + - model/observability + - model/devsecops + - standard/caring + - kernel/itc-kernel-map +outputs: + - ASSIMILATION.md + - source-summary.md + - extracted-concepts.yaml + - comparison-matrix.md + - mappings.yaml + - proposed-changes.md + - open-questions.md +adopted_as: + - infospace/models/capability/InfoTechCanonCapabilityModel.md + - infospace/models/capability/capabilities.yaml +follow_on_workplan: ITC-WP-0014 +canon_version: 0.2.0 +created_at: "2026-08-14" +updated_at: "2026-08-14" diff --git a/infospace/assimilation/it-capability-canon/comparison-matrix.md b/infospace/assimilation/it-capability-canon/comparison-matrix.md new file mode 100644 index 0000000..06ab31c --- /dev/null +++ b/infospace/assimilation/it-capability-canon/comparison-matrix.md @@ -0,0 +1,68 @@ +# Comparison Matrix — ITCC v0.1 vs InfoTechCanon + +Result categories per `InfoTechCanonCore` §14.6. + +## 1. Object model + +| ITCC concept | Nearest canon owner | Category | Resolution | +|---|---|---|---| +| Capability | none — Landscape §11 defers it ("keep only landscape-relevant references once a dedicated strategy/capability standard exists") | `missing_concept` | New model owns `Capability` | +| Capability Profile | Core §8.6 `Profile` | `covered_differently` | Keep both; rename to `CapabilityProfile`, state the distinction explicitly | +| Capability Domain | Core namespaces | `missing_concept` | Adopt as navigation-only, non-semantic | +| Requirement | `DemandSignal`, `ConsumerNeed` (Purpose and Demand extension) | `narrower_than_existing` | Adopt as `CapabilityRequirement`, defined as a typed DemandSignal carrying a minimum maturity | +| Provider | Landscape `ServiceProvider`, `Service`, `ServiceInstance` | `covered_differently` | Import Landscape entities; `CapabilityProvider` is a *role*, not a new entity type | +| Implementation | Landscape `Technology`, `SoftwareEntity`, `RuntimeEntity` | `already_covered` | Import; do not redefine | +| Resource (C/S/N/I/P) | Landscape `RuntimeResource` | `broader_than_existing` | Adopt the classification as `CapabilityResourceClass` for cost attribution; the entity stays with Landscape | +| Evidence | Governance `Evidence`; Observability signals | `already_covered` | Import; add `CapabilityEvidenceHook` as the capability-scoped expectation | +| Maturity D0–D7 | Core status/lifecycle model; conformance levels | `missing_concept` | Adopt; explicitly *not* an artifact status and *not* a conformance level | +| Provision | none | `missing_concept` | Make explicit — maturity attaches here, per the source's own correct/incorrect example | +| Quality dimension | Landscape `ServiceLevelObjective`; Observability SLOs | `narrower_than_existing` | Adopt as named dimensions; measured targets stay with Observability | +| Capability contract | Core `Standard`/schema conventions | `missing_concept` | Adopt as the machine-readable capability record | + +## 2. Relationships + +| ITCC relationship | Category | Resolution | +|---|---|---| +| `depends_on`, `may_use`, `composes` | `missing_concept` | Owned by the new model | +| `requires` | `missing_concept` | Landscape entity or consumer purpose → capability | +| `provides` | `missing_concept` | Landscape service/provider → capability | +| `implements` | `covered_differently` | Landscape already relates technology to service; the capability-typed form is new | +| `consumes` | `missing_concept` | Provision → resource class, for cost attribution | + +## 3. Capability baseline vs existing domain models + +The 41 capabilities are *abilities*; the existing models own the *structures* that +realize, govern, or observe them. No capability duplicates a canon concept — but +each anchors to an owning model, which is what makes the baseline safe to adopt. + +| Capability group | Anchoring canon owner | Category | Note | +|---|---|---|---| +| `identity.*` | Access Control, Organization, CARING | `viewpoint_difference` | Access Control owns Subject/Principal/Permission/Grant/Decision; `identity.authorization` is the *ability*, not the mechanism. `identity.organization` anchors on Organization (tenancy) — no second tenancy definition. | +| `data.*` | Data Model | `viewpoint_difference` | Data owns Dataset/Schema/Classification/Lineage/Contract; persistence, backup, archive, search are abilities over them | +| `integration.*` | Landscape, Network | `viewpoint_difference` | `integration.traffic` overlaps Network exposure/reachability — mapped, not redefined | +| `runtime.*` | Landscape, DevSecOps | `viewpoint_difference` | `runtime.deployment` anchors on DevSecOps source→artifact→release→deployment flow | +| `operations.*` | Observability, Governance | `viewpoint_difference` | `operations.audit` anchors on Governance evidence, `operations.observability` on the Observability model | +| `security.*` | Security, Governance | `viewpoint_difference` | `security.policy` must import Governance `Policy`/`Control`; it does not define policy semantics | +| `governance.evidence`, `governance.lifecycle` | Governance, Data | `conflicting_concept` (naming) | IDs sit in the *Security & Governance* navigation domain while using a `governance.` prefix — see `open-questions.md` OQ-2 | +| `commerce.*` | none | `missing_concept` | Genuinely new canon surface; no existing model covers metering, billing, payment, entitlement | +| `intelligence.*` | none | `missing_concept` | Genuinely new canon surface; Information Space covers retrieval of markdown knowledge, not metered cognitive processing | + +## 4. Structural claims + +| Claim | Category | Note | +|---|---|---| +| "The model is a graph, domains are navigation only" | `terminology_difference_only` | Core §6.4 *Network Before Tree* already says this | +| "Import; do not duplicate" (§15) | `already_covered` | Core §6.3 *Import, Do Not Redefine* | +| Prefer profiles over new capabilities (§8) | `already_covered` | Core §6.5 *Profiles, Not Forks* | +| Evidence over assertion (§19) | `already_covered` | Core §6.9 *Evidence and Provenance Matter* | +| CILM as a proposed sibling model (§15) | `already_covered` | The Landscape Model already owns landscape entities — **rejected as a new model** | +| Intended / declared / applied / observed / assessed state (§15) | `broader_than_existing` | Not currently a canon-wide qualifier set — carried to OQ-3, not adopted here | + +## 5. Verdict + +- No conflicting definition of an existing canonical concept was found. +- Two capability groups (`commerce.*`, `intelligence.*`) are canon-new surface. +- One naming conflict (`governance.*` prefix) and one structural proposal (CILM) + require resolution or rejection before promotion beyond `proposed`. +- The dominant relationship to existing models is **anchoring**, not overlap, + which supports disposition `adapt` rather than `observe` or `reject`. diff --git a/infospace/assimilation/it-capability-canon/extracted-concepts.yaml b/infospace/assimilation/it-capability-canon/extracted-concepts.yaml new file mode 100644 index 0000000..f2fa38d --- /dev/null +++ b/infospace/assimilation/it-capability-canon/extracted-concepts.yaml @@ -0,0 +1,107 @@ +assimilation: assimilation/it-capability-canon +source: ITCC v0.1 +note: > + Concepts as the source names them, before canon comparison. Classification + against the canon lives in comparison-matrix.md; the canonical names chosen on + adoption are recorded in the canon_name field. + +concepts: + - source_name: Capability + definition: Abstract, implementation-independent ability an information system may require or provide. + canon_name: Capability + category: missing_concept + + - source_name: Capability Profile + definition: Constrained specialization of a capability that does not change its identity. + canon_name: CapabilityProfile + category: covered_differently + note: Distinct from a canon Profile (Core §8.6), which constrains canon artifacts for an implementation context. + + - source_name: Capability Domain + definition: Navigation grouping of capabilities; not a semantic container. + canon_name: CapabilityDomain + category: missing_concept + + - source_name: Requirement + definition: A statement that a system needs a capability at a minimum maturity. + canon_name: CapabilityRequirement + category: narrower_than_existing + note: A typed, maturity-bearing form of DemandSignal / ConsumerNeed from the Purpose and Demand extension. + + - source_name: Provider + definition: Operational entity that provides a capability in a particular context. + canon_name: CapabilityProvider + category: covered_differently + note: Landscape owns ServiceProvider / Service / ServiceInstance; provider here is a role played by a landscape entity. + + - source_name: Implementation + definition: Concrete technology, product, configuration, or composition used by a provider. + canon_name: (imported) + category: already_covered + note: Landscape owns Technology / SoftwareEntity / RuntimeEntity. + + - source_name: Resource + definition: Economic resource consumed while providing a capability (C, S, N, I, P). + canon_name: CapabilityResourceClass + category: missing_concept + note: Landscape owns RuntimeResource as an entity; the C/S/N/I/P classification for cost attribution is new. + + - source_name: Evidence + definition: Information supporting a capability or maturity claim. + canon_name: (imported) + category: already_covered + note: Governance owns Evidence; Observability owns telemetry evidence. + + - source_name: Evidence Hook + definition: Named evidence type expected for a specific capability. + canon_name: CapabilityEvidenceHook + category: missing_concept + + - source_name: Maturity + definition: Quality and operational standing of a capability as provided in a specific context. + canon_name: CapabilityMaturityLevel + category: missing_concept + + - source_name: Provision + definition: The relationship binding provider, capability, context, and maturity. + canon_name: CapabilityProvision + category: missing_concept + note: Implicit in the source; made explicit on adoption because maturity attaches here and nowhere else. + + - source_name: Quality Dimension + definition: Named quality attribute relevant to a capability (rpo, latency, assurance, ...). + canon_name: CapabilityQualityDimension + category: missing_concept + + - source_name: Capability Contract + definition: Minimal machine-readable definition of a capability (id, purpose, profiles, qualities, relationships, evidence). + canon_name: CapabilityContract + category: missing_concept + + - source_name: Canon Graph + definition: Capability relationships form a graph traversable from product need to technology and cost. + canon_name: (structural) + category: viewpoint_difference + note: Core §6.4 "Network Before Tree" already states this stance canon-wide. + + - source_name: depends_on / may_use / composes + definition: Capability-to-capability relationship types. + canon_name: depends_on / may_use / composes + category: missing_concept + + - source_name: requires / provides / implements / consumes + definition: Landscape-entity-to-capability relationship types. + canon_name: requires / provides / implements / consumes + category: missing_concept + + - source_name: Canon inclusion rules + definition: Seven tests a concept must pass to enter the capability set. + canon_name: CapabilityInclusionRule + category: narrower_than_existing + note: Core §14 governs canon change generally; these are capability-specific admission tests. + + - source_name: CILM (Canonical IT Landscape Model) + definition: Proposed sibling model owning landscape entities and intended/declared/applied/observed/assessed state. + canon_name: (rejected) + category: already_covered + note: InfoTechCanonLandscapeModel owns this. Only the state-qualifier idea is carried forward as an open question. diff --git a/infospace/assimilation/it-capability-canon/mappings.yaml b/infospace/assimilation/it-capability-canon/mappings.yaml new file mode 100644 index 0000000..549641f --- /dev/null +++ b/infospace/assimilation/it-capability-canon/mappings.yaml @@ -0,0 +1,181 @@ +assimilation: assimilation/it-capability-canon +source: ITCC v0.1 +target_canon_version: "0.2.0" +note: > + Concept-level mappings from the source vocabulary to canonical owners. + mapping_type follows the canon mapping vocabulary: equivalent, narrower, + broader, related, imports, superseded_by, no_mapping. + +mappings: + - source_concept: Implementation + target_concept: Technology / SoftwareEntity / RuntimeEntity + target_owner: model/landscape + mapping_type: imports + rationale: Landscape is the canonical owner of concrete landscape entities. + confidence: high + + - source_concept: Provider + target_concept: Service / ServiceProvider / ServiceInstance + target_owner: model/landscape + mapping_type: related + rationale: CapabilityProvider is a role played by a landscape entity, not a new entity type. + confidence: high + + - source_concept: Resource + target_concept: RuntimeResource + target_owner: model/landscape + mapping_type: broader + rationale: C/S/N/I/P are cost-attribution classes over runtime resources, including non-runtime metered intelligence. + confidence: medium + + - source_concept: Evidence + target_concept: Evidence + target_owner: model/governance + mapping_type: imports + rationale: Governance owns evidence semantics; capability evidence hooks name expected evidence types. + confidence: high + + - source_concept: Evidence (telemetry-derived) + target_concept: TelemetrySignal / Metric / SLO + target_owner: model/observability + mapping_type: related + rationale: Measured maturity evidence (availability, latency, RPO/RTO) is produced by observability. + confidence: high + + - source_concept: Requirement + target_concept: DemandSignal / ConsumerNeed + target_owner: model/purpose-demand-extension + mapping_type: narrower + rationale: A capability requirement is a typed demand signal carrying a minimum maturity. + confidence: high + + - source_concept: Quality dimension + target_concept: ServiceLevelObjective + target_owner: model/landscape + mapping_type: related + rationale: Dimensions are named; targets and measurement remain with SLOs and observability. + confidence: medium + + - source_concept: identity.authentication + target_concept: Principal / AuthenticationEvent + target_owner: model/access-control + mapping_type: related + rationale: The capability is the ability; Access Control owns the mechanism semantics. + confidence: high + + - source_concept: identity.authorization + target_concept: AuthorizationDecision / Permission / Grant + target_owner: model/access-control + mapping_type: related + rationale: Same ability/mechanism split; CARING adds access-governance analysis over it. + confidence: high + + - source_concept: identity.organization + target_concept: Organization / Team / Tenant + target_owner: model/organization + mapping_type: related + rationale: Tenancy structure stays with Organization; the capability is the ability to scope by it. + confidence: high + + - source_concept: security.policy + target_concept: Policy / Rule / Control + target_owner: model/governance + mapping_type: imports + rationale: Policy semantics are owned by Governance and must not be redefined per capability. + confidence: high + + - source_concept: security.secrets / security.keys / security.vulnerability + target_concept: Secret / Key / Vulnerability / Finding + target_owner: model/security + mapping_type: related + confidence: high + + - source_concept: governance.evidence + target_concept: Evidence / Assurance / Control + target_owner: model/governance + mapping_type: related + confidence: high + + - source_concept: governance.lifecycle + target_concept: Retention / Classification / DataContract + target_owner: model/data + mapping_type: related + confidence: medium + + - source_concept: data.* (transactional, object, cache, backup, archive, search) + target_concept: Dataset / DataStore / Schema / Lineage / Retention + target_owner: model/data + mapping_type: related + rationale: Data owns the assets; capabilities are the abilities exercised over them. + confidence: high + + - source_concept: integration.traffic + target_concept: Routing / Exposure / Reachability / NetworkPolicy + target_owner: model/network + mapping_type: related + confidence: high + + - source_concept: integration.api / integration.messaging / integration.exchange + target_concept: Endpoint / Interface / Flow + target_owner: model/landscape + mapping_type: related + confidence: medium + + - source_concept: runtime.deployment + target_concept: Release / Deployment / Artifact + target_owner: model/devsecops + mapping_type: related + confidence: high + + - source_concept: runtime.execution / runtime.configuration / runtime.scheduling + target_concept: RuntimeEntity / RuntimeResource / Configuration + target_owner: model/landscape + mapping_type: related + confidence: medium + + - source_concept: runtime.workflow + target_concept: Task / Action / Dependency + target_owner: model/task + mapping_type: related + rationale: Task owns work-item semantics; workflow orchestration is the ability to run them. + confidence: medium + + - source_concept: operations.observability / operations.alerting + target_concept: Telemetry / Alert / Health / SLO + target_owner: model/observability + mapping_type: related + confidence: high + + - source_concept: operations.audit + target_concept: Evidence / AuditRecord + target_owner: model/governance + mapping_type: related + confidence: high + + - source_concept: operations.recovery / operations.continuity + target_concept: Incident / ServiceLevelObjective + target_owner: model/security + mapping_type: related + confidence: low + note: Continuity has no strong canon owner today — see open question OQ-4. + + - source_concept: commerce.* + target_concept: (none) + target_owner: model/capability + mapping_type: no_mapping + rationale: New canon surface; no existing model covers metering, billing, payment, or entitlement. + confidence: high + + - source_concept: intelligence.* + target_concept: (none) + target_owner: model/capability + mapping_type: no_mapping + rationale: New canon surface. Information Space covers markdown knowledge packaging and retrieval, not metered cognitive processing. + confidence: high + + - source_concept: CILM (Canonical IT Landscape Model) + target_concept: InfoTechCanonLandscapeModel + target_owner: model/landscape + mapping_type: superseded_by + rationale: The proposed sibling model is already the canon Landscape Model. Not adopted as a separate artifact. + confidence: high diff --git a/infospace/assimilation/it-capability-canon/open-questions.md b/infospace/assimilation/it-capability-canon/open-questions.md new file mode 100644 index 0000000..d659fe4 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/open-questions.md @@ -0,0 +1,56 @@ +# Open Questions — ITCC v0.1 assimilation + +## OQ-1 — Is the capability set a model or a standard? + +Resolved for now as a **model** (broad domain structure). If capability contracts +later grow enforcement rules and conformance levels for consumers, part of it may +split into a standard. **Review trigger:** first consumer conformance request. + +## OQ-2 — The `governance.*` prefix inside the Security & Governance domain + +Six capabilities sit in navigation domain `security` but two use a `governance.` +ID prefix (`governance.evidence`, `governance.lifecycle`). Options: + +1. keep as-is — IDs are durable interfaces and already drafted; +2. renumber to `security.*` — consistent prefixes, but breaks IDs; +3. split the navigation domain into `security` and `governance`. + +Capability IDs are durable interfaces, so this must be settled **before** +promotion beyond `proposed`. Preference: option 3 — it preserves every ID and +removes the inconsistency. **Owner:** canon owner. **Blocks:** promotion to +`draft`/`release-candidate`. + +## OQ-3 — Should the intended/declared/applied/observed/assessed state qualifier be canon-wide? + +The source proposes it for maturity claims (a provider may claim D5 while an +assessment concludes D4). The same distinction would be useful for controls, +access maps, and network policy. Adopting it inside the capability model alone +would create a local dialect. **Deferred:** raise as kernel-level (Core) pressure, +not a capability-model decision. + +## OQ-4 — Who owns continuity and service recovery? + +`operations.recovery` and `operations.continuity` have no strong canon owner: +Security owns incidents, Observability owns health, Data owns backup assets, but +business continuity and recovery objectives sit between them. Mapping confidence +is `low`. **Candidate:** a Governance or Landscape extension. + +## OQ-5 — Do `commerce.*` and `intelligence.*` need their own domain models? + +Both are canon-new surface with no anchoring model. Today they are capability IDs +with no owner behind them, which is acceptable for a capability catalog but weak +if consumers start requiring structural semantics (invoices, entitlements, +prompts, evaluations). **Review trigger:** the first consumer demand that needs +structure rather than ability. + +## OQ-6 — How are capability requirements validated against provisions? + +The source sketches a validator (§18) comparing product requirements to provider +maturity. That belongs to the service surface (`ITC-WP-0002`) and needs the +contract schema first. **Deferred:** ITC-WP-0014. + +## OQ-7 — Relationship between `CapabilityProfile` and canon `Profile` + +Named and distinguished, but not yet formally related. A canon `Profile` (e.g. +small-saas) will plausibly *select* capability profiles. **Deferred:** ITC-WP-0014 +alongside the small-SaaS requirement set. diff --git a/infospace/assimilation/it-capability-canon/proposed-changes.md b/infospace/assimilation/it-capability-canon/proposed-changes.md new file mode 100644 index 0000000..d08c7b2 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/proposed-changes.md @@ -0,0 +1,125 @@ +# Proposed Changes — ITCC v0.1 + +Each proposal is a reviewable canon change. Status reflects what was applied in +canon version `0.2.0`. + +--- + +## PC-1 — Add a Capability Model to `models/` + +**Change:** create `InfoTechCanonCapabilityModel` (`ITC-CAP`, namespace `itc-cap`) +at `infospace/models/capability/`, owning the capability object model, the +maturity scale, the resource classes, and the capability relationship types. + +**Rationale:** the canon has no owner for *abstract ability*. The Landscape Model +(§11.4) explicitly defers it: "The Landscape Model should keep only +landscape-relevant references once a dedicated strategy/capability standard +exists." This is that standard. + +**Classification:** model, not standard — it defines a broad domain structure +(abilities and their provision), not a cross-cutting convention. + +**Breaking:** no. **Status:** applied, artifact status `proposed`. + +--- + +## PC-2 — Adopt the 41-capability baseline as machine-readable data + +**Change:** `infospace/models/capability/capabilities.yaml` holds the canonical +baseline — domains, capability contracts, profiles, quality dimensions, evidence +hooks, relationships, maturity levels, resource classes. The Markdown carries +normative prose and an ID index only; the list is not duplicated in both places. + +**Rationale:** capability IDs are durable interfaces and the primary consumer is +tooling. Prose and data must not drift apart. + +**Breaking:** no. **Status:** applied. + +--- + +## PC-3 — Anchor every capability to an owning canon model + +**Change:** each capability entry carries an `anchors` field naming the canon +model(s) that own the concepts it exercises (e.g. `identity.authorization` → +`model/access-control`; `runtime.deployment` → `model/devsecops`). + +**Rationale:** enforces Core §6.2 (single canonical owner) and §6.3 (import, do +not redefine) mechanically. Without anchors, a capability catalog quietly grows +into a second, competing ontology. + +**Breaking:** no. **Status:** applied. + +--- + +## PC-4 — Make Provision explicit; forbid maturity on the abstract capability + +**Change:** introduce `CapabilityProvision` as the binding of provider × +capability × context, and state normatively that maturity attaches to a provision +and never to a `Capability`. + +**Rationale:** the source states the rule correctly (§3.8) but leaves the bearer +implicit, which is what lets `capability: X, maturity: D5` get written by mistake. + +**Breaking:** no. **Status:** applied. + +--- + +## PC-5 — Rename Profile → CapabilityProfile + +**Change:** the source's "Profile" becomes `CapabilityProfile`; the model states +its distinction from the canon `Profile` (Core §8.6). + +**Rationale:** Core §8.6 already owns `Profile` as an artifact type constraining +models for an implementation context. Two meanings of one word inside one canon +is a defect, not a nuance. + +**Breaking:** no (source was never canon). **Status:** applied. + +--- + +## PC-6 — Reject CILM as a separate model + +**Change:** the source's proposed Canonical IT Landscape Model is not adopted. +The Landscape Model already owns landscape entities and relationships. The +capability model *imports* Landscape rather than proposing a sibling. + +**Rationale:** Core §6.2. Adopting CILM would create a second landscape owner. + +**Breaking:** no. **Status:** applied (rejection recorded). + +--- + +## PC-7 — Requirement expressed through Purpose and Demand + +**Change:** `CapabilityRequirement` is defined as a typed `DemandSignal` carrying +a minimum maturity, importing the Purpose and Demand extension rather than +inventing a parallel requirement vocabulary. + +**Rationale:** the canon already models consumer demand; capability requirements +are a maturity-bearing specialization of it. + +**Breaking:** no. **Status:** applied. + +--- + +## PC-8 — Register in kernel map, canon.yaml, artifact index, infospace disciplines + +**Change:** register `model/capability` across `canon.yaml`, +`infospace/artifacts/index.yaml`, `infospace/infospace.yaml`; regenerate agent +briefs, retrieval indexes, and views. + +**Breaking:** no. **Status:** applied. Kernel-map prose update is deferred to +ITC-WP-0014 T01 (the map is a seed document with its own revision cycle). + +--- + +## Deferred to ITC-WP-0014 + +| Item | Reason | +|---|---| +| Formal mapping artifacts under `infospace/mappings/` for each anchor | Needs the mapping schema applied per concept pair, not just the assimilation-level mappings recorded here | +| `capability.schema.yaml` under `infospace/schemas/` | Contract shape should stabilize against one real profile first | +| Small-SaaS profile capability requirement set | Profile proof work belongs with ITC-WP-0004 | +| Resolution of the `governance.*` prefix (OQ-2) | Requires an ID-stability decision before promotion | +| CARING import of `identity.*` capability ids | Touches a release-candidate standard; needs its own review | +| Kernel map revision | Seed document revision cycle | diff --git a/infospace/assimilation/it-capability-canon/source-summary.md b/infospace/assimilation/it-capability-canon/source-summary.md new file mode 100644 index 0000000..cf01a6c --- /dev/null +++ b/infospace/assimilation/it-capability-canon/source-summary.md @@ -0,0 +1,99 @@ +# Source Summary — ITCC v0.1 + +Faithful précis of `source/ITCapabilityCanonV0.1.md` and `source/capabilities.yaml`. +No canon judgement here; comparison lives in `comparison-matrix.md`. + +## Identity + +- **Name:** Information Technology Capability Canon +- **Short name:** ITCC +- **Version:** 0.1, status *draft baseline* +- **Companion data:** `capabilities.yaml` — declared by the document (§17) as the + initial machine-readable representation + +## Stated purpose + +Define **what an information system must be able to do**, independently of how it +is implemented, positioned deliberately between product and technology: + +```text +Business / Product → requires → Capability → provided by → Service + → implemented by → Technology → consumes → Resources → Cost +``` + +The document states (§15) that ITCC is intended to become a capability-oriented +component of the wider InfoTechCanon, governed by "import; do not duplicate". + +## Object model (§3) + +| Object | Meaning | +|---|---| +| Capability | Abstract, implementation-independent ability that may be required or provided | +| Profile | Constrained specialization of a capability, preferred over new capabilities | +| Requirement | A system's statement that it needs a capability at a minimum maturity | +| Provider | Operational entity providing a capability in a context | +| Implementation | Concrete technology/product/configuration used by a provider | +| Resource | Economic resource consumed while providing: C, S, N, I, P | +| Evidence | Information supporting a capability or maturity claim | +| Maturity | Quality/operational standing **of a provision**, never of the abstract capability | + +## Inclusion rules (§4) + +A concept enters the canon only if it is implementation-independent, reusable, +demandable, providable, testable, profileable, and stable. + +## Exclusions (§5) + +Technologies (PostgreSQL, Keycloak, Stripe), protocols and standards (REST, +OIDC, OpenTelemetry), product features (password reset screen), and +domain-specific business capabilities (hospital admission, insurance +underwriting). + +## Structure (§6, §7) + +Eight navigation domains over 41 capabilities; the underlying model is asserted +to be a **graph**, not a tree: + +| Domain | Capabilities | +|---|---| +| Identity & Access | lifecycle, authentication, authorization, federation, organization | +| Data & State | transactional, object, cache, backup, archive, search | +| Integration & Communication | api, messaging, exchange, notification, traffic | +| Runtime & Automation | execution, configuration, scheduling, workflow, deployment | +| Operations & Assurance | observability, alerting, audit, recovery, continuity | +| Security & Governance | secrets, keys, policy, vulnerability, governance.evidence, governance.lifecycle | +| Commerce | metering, billing, payment, entitlement | +| Intelligence | generation, extraction, embedding, retrieval, reasoning | + +Each capability carries `id`, `name`, `purpose`, `profiles`, `qualities`, +`evidence`, and optional `depends_on` / `may_use`. + +## Relationship types (§9) + +`depends_on`, `may_use`, `composes` (capability-to-capability); +`requires`, `provides`, `implements`, `consumes` (landscape-to-capability). + +## Maturity scale (§10, §11) + +`D0` Absent · `D1` Experimental · `D2` Available · `D3` Usable · `D4` Production · +`D5` Reliable · `D6` Scalable · `D7` Strategic. Claims are per provision and per +environment; the same provider may hold different levels in dev/staging/prod. + +## Resource and cost model (§13) + +`C` Compute · `S` Storage · `N` Networking · `I` Intelligence · `P` Platform. +Cost attaches to provisions and implementations, not to abstract capabilities, +enabling capability-oriented FinOps questions. + +## Evolution stance (§16, §19) + +Conservative: prefer profiles over new capabilities, treat capability IDs as +durable interfaces, require explicit migration semantics for rename/removal, +introduce provisionally and promote only after repeated practical use. v0.1 +explicitly does not aim at completeness. + +## Proposed ownership split (§15) + +ITCC owns *what abstract abilities exist*; a "CILM" landscape model owns *what +entities exist and what state they are in*; CARING keeps specialized +access-governance semantics and may import ITCC concepts. diff --git a/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md b/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md new file mode 100755 index 0000000..bb2e1d1 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md @@ -0,0 +1,1154 @@ +# Information Technology Capability Canon v0.1 + +**Status:** Draft baseline +**Short name:** ITCC +**Version:** 0.1 +**Purpose:** Establish a compact, implementation-independent vocabulary for commonly required information-technology capabilities and make those capabilities usable as stable building blocks for architecture, platform engineering, product design, FinOps, governance, and automated reasoning. + +--- + +## 1. Intent + +The Information Technology Capability Canon (ITCC) defines **what an information system must be able to do**, independently of how that ability is implemented. + +The canon is deliberately positioned between products and technology: + +```text +Business / Product + │ + │ requires + ▼ +Canonical Capabilities + │ + │ provided by + ▼ +Services + │ + │ implemented by + ▼ +Technologies + │ + │ consume + ▼ +Resources + │ + ▼ +Cost +``` + +ITCC is intended to provide a practical baseline that can later be reconciled with and incorporated into the wider **InfoTechCanon**. + +The core design objective is a vocabulary that is: + +- small enough to understand; +- stable enough to survive technology changes; +- abstract enough to support heterogeneous implementations; +- precise enough to support contracts and validation; +- machine-readable enough for automated analysis; +- useful enough for day-to-day architecture and operations. + +--- + +## 2. Core Principle + +A **capability** is an abstract, implementation-independent ability that an information system, service, platform, or product may require or provide. + +Examples: + +- Authentication +- Backup & Restore +- Payment +- Workflow Orchestration +- Observability +- Reasoning & Decision + +Technologies are **not** canonical capabilities. + +For example: + +```text +Authentication capability +Keycloak implementation + +Backup & Restore capability +pgBackRest implementation + +Payment capability +Stripe provider / implementation + +Object Persistence capability +S3 implementation / service interface +``` + +The canon therefore aims to remain stable even when technologies, vendors, protocols, and architectures change. + +--- + +## 3. Canonical Objects + +ITCC distinguishes the following concepts. + +### 3.1 Capability + +An abstract ability. + +Example: + +```text +identity.authentication +``` + +### 3.2 Profile + +A specialization or constrained form of a capability. + +Examples: + +```text +Authentication +├── human +├── machine +├── federated +├── passwordless +├── mfa +└── high-assurance +``` + +Profiles should be preferred over creating new canonical capabilities when the underlying ability remains the same. + +### 3.3 Requirement + +A statement that a system needs a capability at a minimum acceptable maturity or quality. + +Example: + +```yaml +requires: + identity.authentication: D5 + data.backup: D5 + operations.observability: D4 +``` + +### 3.4 Provider + +An operational entity that provides a capability in a particular context. + +Example: + +```yaml +provider: auth.prod.eu +provides: + capability: identity.authentication + maturity: D5 +``` + +### 3.5 Implementation + +A concrete technology, product, configuration, or composition used by a provider. + +Examples: + +- Keycloak +- PostgreSQL +- Kubernetes +- Stripe +- OpenTelemetry +- an internal service + +### 3.6 Resource + +An economic resource consumed while providing a capability. + +The initial resource model uses: + +| ID | Resource | 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 | + +### 3.7 Evidence + +Information supporting the claim that a capability exists or has a particular maturity. + +Examples: + +- successful tests; +- measured availability; +- restore tests; +- policy evaluations; +- telemetry; +- configuration evidence; +- audit records. + +### 3.8 Maturity + +A statement about the quality and operational standing of a capability **as provided in a specific context**. + +Maturity attaches to a provision relationship, not to the abstract capability itself. + +Correct: + +```yaml +provider: auth.prod.eu +capability: identity.authentication +maturity: D5 +``` + +Incorrect: + +```yaml +capability: identity.authentication +maturity: D5 +``` + +The latter incorrectly implies that Authentication is intrinsically D5 everywhere. + +--- + +## 4. Canon Inclusion Rules + +A concept should normally enter the canonical capability set only if it satisfies the following tests. + +### 4.1 Implementation-independent + +The capability survives replacement of the underlying technology. + +> Keycloak may disappear; Authentication remains. + +### 4.2 Reusable + +The capability occurs across materially different products or systems. + +### 4.3 Demandable + +A system can meaningfully state that it requires the capability. + +### 4.4 Providable + +Another system, service, or platform component can meaningfully state that it provides the capability. + +### 4.5 Testable + +Evidence can be gathered that the capability exists and is functioning. + +### 4.6 Profileable + +Important specializations can be expressed as profiles without redefining the underlying capability. + +### 4.7 Stable + +The concept is likely to outlive individual products, protocols, or vendors. + +--- + +## 5. What Does Not Belong in the Canon + +The canon intentionally excludes several nearby categories. + +### Technologies + +Examples: + +- PostgreSQL +- Kubernetes +- Keycloak +- OpenBao +- Stripe +- Grafana + +### Protocols and Standards + +Examples: + +- REST +- OAuth +- OpenID Connect +- SAML +- OpenTelemetry + +These may be referenced by capability profiles or implementations. + +### Product Features + +Examples: + +- password reset screen; +- invoice export; +- document upload button. + +### Domain-Specific Business Capabilities + +Examples: + +- hospital admission; +- insurance underwriting; +- warehouse picking; +- vacation booking. + +Such capabilities may depend on ITCC capabilities but are outside this canon. + +--- + +## 6. Canon Structure + +ITCC v0.1 organizes capabilities into eight navigation domains: + +1. Identity & Access +2. Data & State +3. Integration & Communication +4. Runtime & Automation +5. Operations & Assurance +6. Security & Governance +7. Commerce +8. Intelligence + +Domains are primarily a navigation aid. + +The underlying model should be treated as a **graph**, because capabilities may depend on or compose other capabilities across domain boundaries. + +--- + +# 7. Canonical Capability Baseline + +## 7.1 Identity & Access + +### `identity.lifecycle` — Identity Lifecycle + +Create, maintain, suspend, recover, and remove identities over time. + +Typical profiles: + +- human; +- machine; +- external; +- privileged. + +### `identity.authentication` — Authentication + +Establish that an actor controls or legitimately represents an identity. + +Typical profiles: + +- human; +- machine; +- password; +- passkey; +- MFA; +- passwordless; +- high-assurance. + +### `identity.authorization` — Authorization + +Determine whether an authenticated or otherwise identified actor may perform an action on a resource. + +Typical profiles: + +- RBAC; +- ABAC; +- relationship-based; +- policy-based. + +### `identity.federation` — Identity Federation + +Establish and use trust relationships between identity domains. + +Typical profiles: + +- workforce; +- customer; +- partner; +- machine federation. + +### `identity.organization` — Organization & Tenancy + +Associate identities, resources, policies, and operations with organizational or tenant boundaries. + +Typical profiles: + +- organization; +- team; +- tenant; +- hierarchy; +- delegation. + +--- + +## 7.2 Data & State + +### `data.transactional` — Transactional Persistence + +Persist structured mutable state with defined consistency and transaction semantics. + +### `data.object` — Object Persistence + +Persist opaque objects, files, blobs, documents, or similar binary or semi-structured objects. + +### `data.cache` — Caching + +Maintain temporary or derived state for accelerated access. + +### `data.backup` — Backup & Restore + +Create recoverable copies or recovery points and restore previously valid persisted state after loss, corruption, or erroneous modification. + +Important qualities include: + +- recovery point objective (RPO); +- recovery time objective (RTO); +- retention; +- isolation; +- geographical separation; +- restoration validation. + +### `data.archive` — Archive & Retention + +Preserve information for long-term retention under defined lifecycle, integrity, and retrieval rules. + +### `data.search` — Search & Retrieval + +Locate persisted information based on indexed or queryable characteristics. + +Profiles may include: + +- lexical; +- structured; +- faceted; +- semantic; +- hybrid. + +--- + +## 7.3 Integration & Communication + +### `integration.api` — API Exposure + +Expose machine-consumable interfaces through which systems can invoke or retrieve functionality. + +### `integration.messaging` — Messaging & Eventing + +Exchange asynchronous messages or events between producers and consumers. + +Profiles may include: + +- queue; +- pub/sub; +- event stream; +- event bus. + +### `integration.exchange` — Data Exchange + +Move datasets, files, or structured information between systems. + +### `integration.notification` — Notification + +Deliver information to human users or external endpoints. + +Profiles may include: + +- email; +- SMS; +- push; +- chat; +- webhook; +- physical mail. + +### `integration.traffic` — Traffic Management + +Route, balance, control, filter, or shape communication between endpoints. + +Profiles may include: + +- load balancing; +- ingress; +- service routing; +- rate limiting; +- API gateway. + +--- + +## 7.4 Runtime & Automation + +### `runtime.execution` — Workload Execution + +Execute software workloads with defined runtime resources and isolation. + +### `runtime.configuration` — Configuration + +Supply controlled runtime configuration to software and services. + +### `runtime.scheduling` — Scheduling + +Initiate activities according to time, delay, calendar, or recurrence. + +### `runtime.workflow` — Workflow Orchestration + +Coordinate multi-step activities, state transitions, dependencies, retries, and completion. + +### `runtime.deployment` — Deployment & Release + +Bring defined software versions and configurations into operational environments in a controlled manner. + +--- + +## 7.5 Operations & Assurance + +### `operations.observability` — Observability + +Establish operational state and behavior from telemetry such as logs, metrics, traces, events, and derived signals. + +### `operations.alerting` — Alerting + +Detect relevant conditions and surface them to humans or automation. + +### `operations.audit` — Audit + +Produce attributable historical evidence about relevant actions, changes, and decisions. + +### `operations.recovery` — Service Recovery + +Restore an operational service after failure or degradation. + +### `operations.continuity` — Continuity + +Maintain acceptable service operation despite disruption. + +These are intentionally distinguished: + +```text +Backup & Restore recovery of persisted state +Service Recovery recovery of an operational service +Continuity maintaining acceptable operation through disruption +``` + +--- + +## 7.6 Security & Governance + +### `security.secrets` — Secret Management + +Protect, distribute, rotate, and revoke confidential credentials and secrets. + +### `security.keys` — Key & Certificate Management + +Create, protect, distribute, rotate, validate, and revoke cryptographic keys and certificates. + +### `security.policy` — Policy Management & Enforcement + +Define, distribute, evaluate, and enforce machine-interpretable policies. + +### `security.vulnerability` — Vulnerability Management + +Identify, assess, prioritize, remediate, mitigate, and track exploitable weaknesses. + +### `governance.evidence` — Compliance Evidence + +Produce and maintain evidence supporting governance, assurance, certification, or compliance assertions. + +### `governance.lifecycle` — Information Lifecycle Governance + +Apply rules governing information retention, handling, deletion, preservation, and lifecycle transitions. + +--- + +## 7.7 Commerce + +### `commerce.metering` — Metering + +Measure usage or activity that is commercially or contractually relevant. + +### `commerce.billing` — Billing + +Calculate amounts owed based on contracts, pricing rules, entitlements, metering, or events. + +### `commerce.payment` — Payment + +Transfer monetary value between parties. + +Typical profiles: + +- card; +- SEPA; +- bank transfer; +- wallet; +- payout; +- recurring. + +### `commerce.entitlement` — Entitlement + +Determine which products, features, capacities, or service levels a customer or actor is contractually allowed to use. + +A subscription is normally a composition rather than a primitive capability: + +```text +Subscription +├── Metering +├── Billing +├── Payment +└── Entitlement +``` + +--- + +## 7.8 Intelligence + +### `intelligence.generation` — Generation + +Produce novel information representations from context or instructions. + +Profiles may include: + +- text; +- image; +- audio; +- video; +- code; +- structured data. + +### `intelligence.extraction` — Extraction & Classification + +Derive structured information, labels, attributes, or classifications from input. + +Profiles may include: + +- OCR; +- document extraction; +- entity extraction; +- classification; +- speech recognition. + +### `intelligence.embedding` — Semantic Representation + +Produce machine-usable semantic representations of information. + +### `intelligence.retrieval` — Semantic Retrieval & Ranking + +Select or rank information according to semantic relevance. + +### `intelligence.reasoning` — Reasoning & Decision + +Derive judgments, plans, decisions, hypotheses, or action proposals from context and constraints. + +--- + +# 8. Capability Profiles + +Profiles specialize a canonical capability without changing its identity. + +A profile may constrain: + +- supported interaction type; +- subject; +- protocol; +- assurance level; +- delivery channel; +- consistency; +- durability; +- performance; +- regulatory context; +- geography; +- tenancy; +- security posture. + +Example: + +```yaml +capability: identity.authentication +profile: + subject: human + assurance: high + factors: + minimum: 2 + federation: + oidc: true +``` + +Profiles should remain composable and should avoid encoding particular products or vendors unless the profile explicitly represents an implementation standard. + +--- + +# 9. Capability Relationships + +The canon should support at least the following relationship types. + +## `depends_on` + +The capability normally requires another capability to operate. + +```text +data.backup + DEPENDS_ON data.object +``` + +## `may_use` + +The capability may use another capability but is not conceptually dependent on it. + +```text +runtime.workflow + MAY_USE integration.messaging +``` + +## `composes` + +A higher-level capability or pattern is constructed from multiple lower-level capabilities. + +```text +Subscription + COMPOSES Metering + Billing + Payment + Entitlement +``` + +## `requires` + +A product, workload, service, or other landscape entity requires a capability. + +## `provides` + +A service or provider supplies a capability. + +## `implements` + +A technology or implementation realizes all or part of a provider. + +## `consumes` + +A provider or implementation consumes economic resources. + +--- + +# 10. Maturity Model + +ITCC v0.1 uses the following maturity scale. + +| Level | State | Meaning | +|---|---|---| +| **D0** | Absent | Capability is not provided | +| **D1** | Experimental | Proof of concept or exploratory implementation | +| **D2** | Available | A provider exists and can be consumed | +| **D3** | Usable | Documented and practically consumable | +| **D4** | Production | Approved for production dependency | +| **D5** | Reliable | Reliability is measured and actively controlled | +| **D6** | Scalable | Capacity and operational scaling are demonstrated | +| **D7** | Strategic | Governed, reusable, and deliberately evolved as a platform capability | + +A maturity claim should be contextual. + +Example: + +```yaml +provider: auth.prod.eu +capability: identity.authentication +maturity: D5 +environment: production +``` + +A single provider may expose different maturity in different contexts: + +```yaml +provider: auth +provisions: + - environment: development + capability: identity.authentication + maturity: D3 + - environment: staging + capability: identity.authentication + maturity: D4 + - environment: production + capability: identity.authentication + maturity: D6 +``` + +--- + +# 11. Evidence and Maturity + +Maturity should increasingly require evidence. + +Suggested interpretation: + +### D0 — Absent + +No provider exists. + +### D1 — Experimental + +Evidence may consist of: + +- prototype; +- experiment; +- demonstration; +- initial configuration. + +### D2 — Available + +Evidence should show: + +- discoverable provider; +- successful invocation; +- basic ownership. + +### D3 — Usable + +Evidence should include: + +- documented usage; +- defined interface; +- known limitations; +- repeatable consumption. + +### D4 — Production + +Evidence should additionally include: + +- production approval; +- operational ownership; +- security baseline; +- backup/recovery posture where applicable; +- production change process. + +### D5 — Reliable + +Evidence should additionally include: + +- operational objectives; +- measurement; +- monitoring; +- incident handling; +- demonstrated recovery. + +### D6 — Scalable + +Evidence should additionally include: + +- capacity model; +- load or scale validation; +- scaling mechanisms; +- demonstrated operation beyond current baseline demand. + +### D7 — Strategic + +Evidence should additionally include: + +- explicit governance; +- reuse across multiple consumers; +- lifecycle ownership; +- roadmap; +- compatibility/evolution policy; +- cost and performance understanding. + +These criteria may later be specialized by capability. + +--- + +# 12. Capability Contract + +Each canonical capability should ultimately have a minimal machine-readable contract. + +Example: + +```yaml +id: data.backup +name: Backup & Restore +domain: data + +purpose: > + Recover previously valid persisted state after loss, + corruption, or erroneous modification. + +profiles: + - database + - object + - volume + +qualities: + - rpo + - rto + - retention + - isolation + - geographical_separation + - restore_validation + +depends_on: + - data.object + +evidence: + - successful_backup + - successful_restore_test + - measured_rpo + - measured_rto +``` + +The initial canon intentionally standardizes identity, semantics, relationships, and evidence hooks before attempting to standardize every feature or quality dimension. + +--- + +# 13. Resource and Cost Model + +ITCC separates capabilities from economic resources. + +The resource model is: + +```text +C — Compute +S — Storage +N — Networking +I — Intelligence +P — Platform +``` + +A capability provision may consume any combination of these resources. + +Conceptually: + +\[ +Cost(capability\ provision) = C + S + N + I + P +\] + +Examples: + +```text +Authentication + → Compute + → Storage + → Networking + → Platform + +Backup & Restore + → Compute + → Storage + → Networking + → Platform + +Generation via external model API + → Networking + → Intelligence + → Platform +``` + +Resource consumption should attach to actual providers or implementations rather than to the abstract capability definition. + +This supports capability-oriented FinOps questions such as: + +- What does Authentication cost? +- What is the marginal cost of Backup & Restore? +- Which capabilities dominate Intelligence spend? +- What is the cost of a capability per tenant, customer, transaction, or workload? + +--- + +# 14. Canon Graph + +Domains provide navigation, but the actual canon is a graph. + +Example: + +```text +Payment + DEPENDS_ON → Authentication + MAY_USE → Audit + MAY_USE → API Exposure + +Backup & Restore + DEPENDS_ON → Object Persistence + MAY_USE → Scheduling + MAY_USE → Observability + +Workflow Orchestration + MAY_USE → Messaging & Eventing + MAY_USE → Scheduling + MAY_USE → Notification +``` + +The graph enables traversal from product need to technology and cost: + +```text +Product + → REQUIRES Capability + ← PROVIDED_BY Service + → IMPLEMENTED_BY Technology + → CONSUMES C/S/N/I/P +``` + +--- + +# 15. Relationship to InfoTechCanon + +ITCC is intended to become a capability-oriented component of the wider InfoTechCanon. + +A proposed conceptual ownership model is: + +```text +InfoTechCanon +│ +├── Capability Canon / ITCC +│ owns: +│ What abstract IT abilities exist? +│ +├── CILM — Canonical IT Landscape Model +│ owns: +│ What entities exist in an IT landscape? +│ How are entities related? +│ What state is intended, declared, applied, +│ observed, historical, or assessed? +│ +├── CARING +│ owns: +│ Specialized access-governance semantics +│ and assessment +│ +├── Standards +├── Profiles +├── Patterns +├── Mappings +└── Validation +``` + +The governing principle should be: + +> **Import; do not duplicate.** + +For example, ITCC owns the meaning of: + +- Identity Lifecycle; +- Authentication; +- Authorization; +- Policy; +- Audit; +- Compliance Evidence. + +CARING may import those concepts and add richer access-governance semantics. + +CILM may express relationships such as: + +```text +Workload REQUIRES Capability +Service PROVIDES Capability +Technology IMPLEMENTS Service +``` + +CILM's state model can later distinguish: + +- intended maturity; +- declared maturity; +- applied maturity; +- observed maturity; +- assessed maturity. + +That allows a provider to claim D5 while an assessment concludes D4, without corrupting the underlying capability model. + +--- + +# 16. Canon Evolution + +The canon should evolve conservatively. + +A proposed change process: + +1. **Identify a repeated architectural need.** +2. **Test whether an existing capability plus profile already represents it.** +3. **Apply the canon inclusion rules.** +4. **Check for overlap with existing capabilities.** +5. **Define purpose and boundary.** +6. **Add initial profiles and relationships.** +7. **Add evidence hooks.** +8. **Introduce the capability provisionally.** +9. **Promote only after repeated practical use.** + +Canonical capability IDs should be treated as durable interfaces. + +Renaming or removing an ID should require explicit migration semantics. + +--- + +# 17. Initial Machine-Readable Source + +The companion file: + +```text +capabilities.yaml +``` + +is the initial machine-readable representation of this canon. + +It contains: + +- version metadata; +- domains; +- capability identifiers; +- names and purposes; +- initial profiles; +- initial quality dimensions; +- evidence hooks; +- dependency relationships; +- maturity definitions; +- resource definitions. + +The Markdown document provides normative human-readable context; the YAML file provides a basis for tooling, validation, graph construction, and agentic reasoning. + +--- + +# 18. Example: Product Requirement and Provision + +A product may declare: + +```yaml +product: lifedesk + +requires: + - capability: identity.authentication + minimum_maturity: D5 + + - capability: data.backup + minimum_maturity: D5 + + - capability: operations.observability + minimum_maturity: D4 + + - capability: commerce.payment + minimum_maturity: D4 + + - capability: intelligence.reasoning + minimum_maturity: D2 +``` + +Providers may declare: + +```yaml +providers: + - id: auth.prod.eu + provides: + - capability: identity.authentication + maturity: D6 + + - id: backup.prod.eu + provides: + - capability: data.backup + maturity: D5 +``` + +A validator can then determine whether the environment satisfies the product requirements. + +This is the intended direction: architecture as a **typed dependency and evidence system**, not merely a collection of technology diagrams. + +--- + +# 19. v0.1 Design Position + +ITCC v0.1 intentionally favors: + +- abstract ability over technology; +- a small canon over exhaustive taxonomy; +- profiles over proliferation of capabilities; +- graph relationships over rigid hierarchy; +- maturity of provision over maturity of concepts; +- evidence over assertion; +- stable identifiers over fashionable terminology; +- machine-readability from the beginning. + +The baseline is expected to change through practical use. + +The goal of v0.1 is not completeness. + +The goal is to establish a coherent kernel strong enough to be used, tested, challenged, and reconciled with the wider InfoTechCanon. diff --git a/infospace/assimilation/it-capability-canon/source/capabilities.yaml b/infospace/assimilation/it-capability-canon/source/capabilities.yaml new file mode 100755 index 0000000..3db24d2 --- /dev/null +++ b/infospace/assimilation/it-capability-canon/source/capabilities.yaml @@ -0,0 +1,787 @@ +canon: + id: itcc + name: Information Technology Capability Canon + short_name: ITCC + version: '0.1' + status: draft + purpose: Implementation-independent canonical vocabulary for common information-technology capabilities. +resources: +- id: C + name: Compute + description: Generic execution capacity. +- id: S + name: Storage + description: Persistence capacity. +- id: N + name: Networking + description: Information movement. +- id: I + name: Intelligence + description: Metered or purchased cognitive or semantic processing capability. +- id: P + name: Platform + description: Enabling operational overhead that makes other resources usable. +maturity_model: +- id: D0 + name: Absent + description: Capability is not provided. +- id: D1 + name: Experimental + description: Proof of concept or exploratory implementation. +- id: D2 + name: Available + description: A provider exists and can be consumed. +- id: D3 + name: Usable + description: Documented and practically consumable. +- id: D4 + name: Production + description: Approved for production dependency. +- id: D5 + name: Reliable + description: Reliability is measured and actively controlled. +- id: D6 + name: Scalable + description: Capacity and operational scaling are demonstrated. +- id: D7 + name: Strategic + description: Governed, reusable, and deliberately evolved as a platform capability. +relationship_types: +- id: depends_on + description: Capability normally requires another capability to operate. +- id: may_use + description: Capability may use another capability without conceptual dependency. +- id: composes + description: A higher-level capability or pattern is composed from lower-level capabilities. +- id: requires + description: A landscape entity requires a capability. +- id: provides + description: A provider supplies a capability. +- id: implements + description: A technology or implementation realizes a provider or capability provision. +- id: consumes + description: A provider or implementation consumes economic resources. +domains: +- id: identity + name: Identity & Access + capabilities: + - id: identity.lifecycle + name: Identity Lifecycle + purpose: Create, maintain, suspend, recover, and remove identities over time. + profiles: + - human + - machine + - external + - privileged + qualities: + - provisioning_latency + - deprovisioning_latency + - recovery + - ownership + evidence: + - successful_provisioning + - successful_deprovisioning + - ownership_record + - id: identity.authentication + name: Authentication + purpose: Establish that an actor controls or legitimately represents an identity. + profiles: + - human + - machine + - password + - passkey + - mfa + - passwordless + - high-assurance + qualities: + - assurance + - availability + - latency + - factor_support + evidence: + - successful_authentication + - failure_metrics + - availability_metrics + - id: identity.authorization + name: Authorization + purpose: Determine whether an actor may perform an action on a resource. + profiles: + - rbac + - abac + - relationship-based + - policy-based + qualities: + - decision_latency + - policy_coverage + - explainability + evidence: + - policy_tests + - authorization_decisions + - denial_evidence + - id: identity.federation + name: Identity Federation + purpose: Establish and use trust relationships between identity domains. + profiles: + - workforce + - customer + - partner + - machine + qualities: + - trust_scope + - protocol_support + - availability + evidence: + - federation_configuration + - successful_federated_login + - id: identity.organization + name: Organization & Tenancy + purpose: Associate identities, resources, policies, and operations with organizational or tenant boundaries. + profiles: + - organization + - team + - tenant + - hierarchy + - delegation + qualities: + - isolation + - delegation + - hierarchy_depth + evidence: + - tenant_isolation_tests + - membership_records +- id: data + name: Data & State + capabilities: + - id: data.transactional + name: Transactional Persistence + purpose: Persist structured mutable state with defined consistency and transaction semantics. + profiles: + - relational + - document + - key-value + qualities: + - consistency + - durability + - availability + - latency + - throughput + evidence: + - durability_tests + - availability_metrics + - id: data.object + name: Object Persistence + purpose: Persist opaque objects, files, blobs, documents, or similar binary or semi-structured objects. + profiles: + - blob + - document + - artifact + qualities: + - durability + - availability + - retention + - size_limits + evidence: + - object_integrity_tests + - availability_metrics + - id: data.cache + name: Caching + purpose: Maintain temporary or derived state for accelerated access. + profiles: + - local + - distributed + - content + qualities: + - hit_rate + - latency + - eviction_policy + - freshness + evidence: + - cache_metrics + - latency_metrics + - id: data.backup + name: Backup & Restore + purpose: Create recoverable copies or recovery points and restore previously valid persisted state after loss, + corruption, or erroneous modification. + profiles: + - database + - object + - volume + qualities: + - rpo + - rto + - retention + - isolation + - geographical_separation + - restore_validation + depends_on: + - data.object + may_use: + - runtime.scheduling + - operations.observability + evidence: + - successful_backup + - successful_restore_test + - measured_rpo + - measured_rto + - id: data.archive + name: Archive & Retention + purpose: Preserve information for long-term retention under defined lifecycle, integrity, and retrieval rules. + profiles: + - regulatory + - operational + - cold + qualities: + - retention + - immutability + - retrievability + - integrity + evidence: + - retention_policy + - integrity_verification + - retrieval_test + - id: data.search + name: Search & Retrieval + purpose: Locate persisted information based on indexed or queryable characteristics. + profiles: + - lexical + - structured + - faceted + - semantic + - hybrid + qualities: + - latency + - recall + - precision + - freshness + evidence: + - search_tests + - latency_metrics +- id: integration + name: Integration & Communication + capabilities: + - id: integration.api + name: API Exposure + purpose: Expose machine-consumable interfaces through which systems can invoke or retrieve functionality. + profiles: + - request-response + - streaming + - public + - internal + qualities: + - availability + - latency + - compatibility + - rate_limits + evidence: + - contract_tests + - availability_metrics + - id: integration.messaging + name: Messaging & Eventing + purpose: Exchange asynchronous messages or events between producers and consumers. + profiles: + - queue + - pub-sub + - event-stream + - event-bus + qualities: + - delivery_semantics + - ordering + - durability + - latency + - throughput + evidence: + - delivery_tests + - lag_metrics + - id: integration.exchange + name: Data Exchange + purpose: Move datasets, files, or structured information between systems. + profiles: + - batch + - file + - stream + - managed-transfer + qualities: + - integrity + - latency + - throughput + - retries + evidence: + - transfer_tests + - integrity_checks + - id: integration.notification + name: Notification + purpose: Deliver information to human users or external endpoints. + profiles: + - email + - sms + - push + - chat + - webhook + - physical-mail + qualities: + - delivery_rate + - latency + - channel_support + - tracking + evidence: + - delivery_receipts + - failure_metrics + - id: integration.traffic + name: Traffic Management + purpose: Route, balance, control, filter, or shape communication between endpoints. + profiles: + - load-balancing + - ingress + - service-routing + - rate-limiting + - api-gateway + qualities: + - availability + - latency + - routing_correctness + - capacity + evidence: + - routing_tests + - availability_metrics +- id: runtime + name: Runtime & Automation + capabilities: + - id: runtime.execution + name: Workload Execution + purpose: Execute software workloads with defined runtime resources and isolation. + profiles: + - process + - container + - virtual-machine + - function + - batch + qualities: + - availability + - isolation + - startup_time + - capacity + evidence: + - execution_tests + - capacity_metrics + - id: runtime.configuration + name: Configuration + purpose: Supply controlled runtime configuration to software and services. + profiles: + - static + - dynamic + - environment + - feature + qualities: + - versioning + - propagation_latency + - consistency + - auditability + evidence: + - configuration_history + - propagation_tests + - id: runtime.scheduling + name: Scheduling + purpose: Initiate activities according to time, delay, calendar, or recurrence. + profiles: + - cron + - calendar + - delay + - recurring + qualities: + - timing_accuracy + - delivery_guarantee + - timezone_support + evidence: + - schedule_execution_records + - id: runtime.workflow + name: Workflow Orchestration + purpose: Coordinate multi-step activities, state transitions, dependencies, retries, and completion. + profiles: + - durable + - human-in-the-loop + - saga + - agentic + qualities: + - durability + - retry_semantics + - visibility + - recovery + may_use: + - integration.messaging + - runtime.scheduling + - integration.notification + evidence: + - workflow_completion_records + - recovery_tests + - id: runtime.deployment + name: Deployment & Release + purpose: Bring defined software versions and configurations into operational environments in a controlled manner. + profiles: + - rolling + - blue-green + - canary + - immutable + qualities: + - rollback + - lead_time + - failure_rate + - traceability + evidence: + - deployment_records + - rollback_test +- id: operations + name: Operations & Assurance + capabilities: + - id: operations.observability + name: Observability + purpose: Establish operational state and behavior from telemetry such as logs, metrics, traces, events, and + derived signals. + profiles: + - logs + - metrics + - traces + - events + - profiles + qualities: + - coverage + - freshness + - retention + - queryability + evidence: + - telemetry_coverage + - dashboard_or_query_evidence + - id: operations.alerting + name: Alerting + purpose: Detect relevant conditions and surface them to humans or automation. + profiles: + - threshold + - anomaly + - event + - slo + qualities: + - detection_latency + - precision + - delivery + - escalation + may_use: + - operations.observability + - integration.notification + evidence: + - alert_tests + - incident_linkage + - id: operations.audit + name: Audit + purpose: Produce attributable historical evidence about relevant actions, changes, and decisions. + profiles: + - security + - administrative + - business + - decision + qualities: + - integrity + - attribution + - retention + - queryability + evidence: + - audit_records + - integrity_verification + - id: operations.recovery + name: Service Recovery + purpose: Restore an operational service after failure or degradation. + profiles: + - restart + - failover + - rebuild + - disaster-recovery + qualities: + - rto + - recovery_success_rate + - automation + may_use: + - data.backup + - operations.observability + evidence: + - recovery_tests + - incident_recovery_records + - id: operations.continuity + name: Continuity + purpose: Maintain acceptable service operation despite disruption. + profiles: + - high-availability + - multi-zone + - multi-region + - degraded-mode + qualities: + - availability + - fault_tolerance + - capacity_reserve + evidence: + - continuity_tests + - availability_metrics +- id: security + name: Security & Governance + capabilities: + - id: security.secrets + name: Secret Management + purpose: Protect, distribute, rotate, and revoke confidential credentials and secrets. + profiles: + - static + - dynamic + - application + - human + qualities: + - rotation + - access_control + - auditability + - availability + evidence: + - rotation_records + - access_audit + - id: security.keys + name: Key & Certificate Management + purpose: Create, protect, distribute, rotate, validate, and revoke cryptographic keys and certificates. + profiles: + - tls + - signing + - encryption + - pki + qualities: + - rotation + - revocation + - expiry_control + - key_protection + evidence: + - certificate_inventory + - rotation_records + - id: security.policy + name: Policy Management & Enforcement + purpose: Define, distribute, evaluate, and enforce machine-interpretable policies. + profiles: + - access + - configuration + - admission + - compliance + qualities: + - coverage + - decision_latency + - versioning + - explainability + evidence: + - policy_tests + - decision_records + - id: security.vulnerability + name: Vulnerability Management + purpose: Identify, assess, prioritize, remediate, mitigate, and track exploitable weaknesses. + profiles: + - source + - dependency + - image + - runtime + - infrastructure + qualities: + - coverage + - time_to_detect + - time_to_remediate + - risk_acceptance + evidence: + - scan_results + - remediation_records + - id: governance.evidence + name: Compliance Evidence + purpose: Produce and maintain evidence supporting governance, assurance, certification, or compliance assertions. + profiles: + - technical + - organizational + - regulatory + qualities: + - completeness + - traceability + - freshness + - integrity + evidence: + - evidence_records + - assessment_links + - id: governance.lifecycle + name: Information Lifecycle Governance + purpose: Apply rules governing information retention, handling, deletion, preservation, and lifecycle transitions. + profiles: + - retention + - deletion + - legal-hold + - classification + qualities: + - coverage + - enforcement + - traceability + evidence: + - lifecycle_policy + - deletion_records + - retention_evidence +- id: commerce + name: Commerce + capabilities: + - id: commerce.metering + name: Metering + purpose: Measure usage or activity that is commercially or contractually relevant. + profiles: + - usage + - event + - capacity + - time + qualities: + - accuracy + - completeness + - latency + - auditability + evidence: + - meter_records + - reconciliation + - id: commerce.billing + name: Billing + purpose: Calculate amounts owed based on contracts, pricing rules, entitlements, metering, or events. + profiles: + - subscription + - usage-based + - one-time + - hybrid + qualities: + - accuracy + - explainability + - reconciliation + - currency_support + may_use: + - commerce.metering + - commerce.entitlement + evidence: + - invoice_tests + - billing_reconciliation + - id: commerce.payment + name: Payment + purpose: Transfer monetary value between parties. + profiles: + - card + - sepa + - bank-transfer + - wallet + - payout + - recurring + qualities: + - success_rate + - settlement_time + - currency_support + - refund_support + may_use: + - identity.authentication + - operations.audit + - integration.api + evidence: + - payment_records + - settlement_reconciliation + - id: commerce.entitlement + name: Entitlement + purpose: Determine which products, features, capacities, or service levels a customer or actor is contractually + allowed to use. + profiles: + - feature + - capacity + - plan + - time-bound + qualities: + - decision_latency + - consistency + - auditability + may_use: + - identity.authorization + evidence: + - entitlement_tests + - decision_records +- id: intelligence + name: Intelligence + capabilities: + - id: intelligence.generation + name: Generation + purpose: Produce novel information representations from context or instructions. + profiles: + - text + - image + - audio + - video + - code + - structured-data + qualities: + - quality + - latency + - cost + - safety + evidence: + - evaluation_results + - latency_metrics + - id: intelligence.extraction + name: Extraction & Classification + purpose: Derive structured information, labels, attributes, or classifications from input. + profiles: + - ocr + - document-extraction + - entity-extraction + - classification + - speech-recognition + qualities: + - accuracy + - recall + - precision + - latency + evidence: + - evaluation_results + - golden_set_tests + - id: intelligence.embedding + name: Semantic Representation + purpose: Produce machine-usable semantic representations of information. + profiles: + - text + - image + - multimodal + qualities: + - dimensionality + - semantic_quality + - latency + - cost + evidence: + - retrieval_benchmarks + - latency_metrics + - id: intelligence.retrieval + name: Semantic Retrieval & Ranking + purpose: Select or rank information according to semantic relevance. + profiles: + - vector + - reranking + - hybrid + - multimodal + qualities: + - recall + - precision + - ranking_quality + - latency + may_use: + - intelligence.embedding + - data.search + evidence: + - retrieval_benchmarks + - id: intelligence.reasoning + name: Reasoning & Decision + purpose: Derive judgments, plans, decisions, hypotheses, or action proposals from context and constraints. + profiles: + - analysis + - planning + - decision + - agentic + qualities: + - task_success + - reliability + - latency + - cost + - explainability + may_use: + - intelligence.retrieval + evidence: + - task_evaluations + - decision_records diff --git a/infospace/indexes/artifact-tree.yaml b/infospace/indexes/artifact-tree.yaml index daf39a4..c60f38d 100644 --- a/infospace/indexes/artifact-tree.yaml +++ b/infospace/indexes/artifact-tree.yaml @@ -1,5 +1,5 @@ root: infospace -file_count: 161 +file_count: 175 files: - path: README.md directory: . @@ -85,6 +85,9 @@ files: - path: agent/briefs/model-access-control.md directory: agent/briefs name: model-access-control.md +- path: agent/briefs/model-capability.md + directory: agent/briefs + name: model-capability.md - path: agent/briefs/model-data.md directory: agent/briefs name: model-data.md @@ -199,6 +202,39 @@ files: - path: assimilation/README.md directory: assimilation name: README.md +- path: assimilation/intake-and-assimilation-practice.md + directory: assimilation + name: intake-and-assimilation-practice.md +- path: assimilation/it-capability-canon/ASSIMILATION.md + directory: assimilation/it-capability-canon + name: ASSIMILATION.md +- path: assimilation/it-capability-canon/assimilation.yaml + directory: assimilation/it-capability-canon + name: assimilation.yaml +- path: assimilation/it-capability-canon/comparison-matrix.md + directory: assimilation/it-capability-canon + name: comparison-matrix.md +- path: assimilation/it-capability-canon/extracted-concepts.yaml + directory: assimilation/it-capability-canon + name: extracted-concepts.yaml +- path: assimilation/it-capability-canon/mappings.yaml + directory: assimilation/it-capability-canon + name: mappings.yaml +- path: assimilation/it-capability-canon/open-questions.md + directory: assimilation/it-capability-canon + name: open-questions.md +- path: assimilation/it-capability-canon/proposed-changes.md + directory: assimilation/it-capability-canon + name: proposed-changes.md +- path: assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md + directory: assimilation/it-capability-canon/source + name: ITCapabilityCanonV0.1.md +- path: assimilation/it-capability-canon/source/capabilities.yaml + directory: assimilation/it-capability-canon/source + name: capabilities.yaml +- path: assimilation/it-capability-canon/source-summary.md + directory: assimilation/it-capability-canon + name: source-summary.md - path: concepts/purpose-demand.yaml directory: concepts name: purpose-demand.yaml @@ -304,6 +340,12 @@ files: - path: models/access-control/InfoTechCanonAccessControlModel.md directory: models/access-control name: InfoTechCanonAccessControlModel.md +- path: models/capability/InfoTechCanonCapabilityModel.md + directory: models/capability + name: InfoTechCanonCapabilityModel.md +- path: models/capability/capabilities.yaml + directory: models/capability + name: capabilities.yaml - path: models/data/InfoTechCanonDataModel.md directory: models/data name: InfoTechCanonDataModel.md diff --git a/infospace/indexes/concept-ownership.yaml b/infospace/indexes/concept-ownership.yaml index 6704d6c..ec24ead 100644 --- a/infospace/indexes/concept-ownership.yaml +++ b/infospace/indexes/concept-ownership.yaml @@ -1,5 +1,9 @@ -concept_count: 90 +concept_count: 106 concepts: +- concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1" + owner: assimilation/it-capability-canon + path: assimilation/it-capability-canon/ASSIMILATION.md + source: artifact_title - concept: CARING Kubernetes RBAC Benchmark owner: benchmark/caring/kubernetes-rbac path: standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml @@ -20,6 +24,10 @@ concepts: owner: benchmark/caring/kubernetes-rbac/native-concepts path: standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml source: artifact_title +- concept: InfoTechCanon Capability Catalog + owner: capability-catalog/itc-cap + path: models/capability/capabilities.yaml + source: artifact_title - concept: Repo Scoping Canon Benefit Analysis owner: comparison/repo-scoping/canon-benefit-analysis path: evaluations/repo-scoping/canon-benefit-analysis.yaml @@ -104,6 +112,58 @@ concepts: owner: model/access-control path: models/access-control/InfoTechCanonAccessControlModel.md source: artifact_title +- concept: InfoTechCanon Capability Model + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: artifact_title +- concept: Capability + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityDomain + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityProfile + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityContract + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityRequirement + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityProvider + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityProvision + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityMaturityLevel + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityQualityDimension + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityEvidenceHook + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityResourceClass + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts +- concept: CapabilityInclusionRule + owner: model/capability + path: models/capability/InfoTechCanonCapabilityModel.md + source: frontmatter.owned_concepts - concept: InfoTechCanon Data Model owner: model/data path: models/data/InfoTechCanonDataModel.md @@ -192,6 +252,10 @@ concepts: owner: pattern/intent-scope-purposes path: patterns/intent-scope-purposes.md source: frontmatter.owned_concepts +- concept: Intake and Assimilation Practice + owner: practice/intake-and-assimilation + path: assimilation/intake-and-assimilation-practice.md + source: artifact_title - concept: Small SaaS System Profile owner: profile/small-saas path: profiles/small-saas/profile.yaml diff --git a/infospace/indexes/import-matrix.yaml b/infospace/indexes/import-matrix.yaml index 02c4166..34c1cf9 100644 --- a/infospace/indexes/import-matrix.yaml +++ b/infospace/indexes/import-matrix.yaml @@ -1,9 +1,11 @@ artifacts: +- assimilation/it-capability-canon - benchmark/caring/kubernetes-rbac - benchmark/caring/kubernetes-rbac/access-descriptors - benchmark/caring/kubernetes-rbac/caring-mapping - benchmark/caring/kubernetes-rbac/findings - benchmark/caring/kubernetes-rbac/native-concepts +- capability-catalog/itc-cap - comparison/repo-scoping/canon-benefit-analysis - comparison/repo-scoping/consumer-workplan-brief - comparison/repo-scoping/extension-candidates @@ -25,6 +27,7 @@ artifacts: - kernel/itc-kernel-map - mapping/purpose-demand-governance-candidates - model/access-control +- model/capability - model/data - model/devsecops - model/governance @@ -37,6 +40,7 @@ artifacts: - model/security - model/task - pattern/intent-scope-purposes +- practice/intake-and-assimilation - profile/small-saas - review-kit/alignment - review-kit/alignment/model-selection-guide @@ -61,6 +65,10 @@ artifacts: - standard/repository-layout - standard/tagging rows: +- artifact: assimilation/it-capability-canon + targets: + kernel/itc-core: + - conforms_to - artifact: benchmark/caring/kubernetes-rbac targets: model/access-control: @@ -123,6 +131,8 @@ rows: - maps standard/caring: - maps +- artifact: capability-catalog/itc-cap + targets: {} - artifact: comparison/repo-scoping/canon-benefit-analysis targets: comparison/repo-scoping/report: @@ -381,6 +391,22 @@ rows: - uses model/organization: - uses +- artifact: model/capability + targets: + assimilation/it-capability-canon: + - derived_from + capability-catalog/itc-cap: + - introduces + kernel/itc-core: + - conforms_to + model/governance: + - uses + model/landscape: + - uses + model/observability: + - uses + model/purpose-demand-extension: + - uses - artifact: model/data targets: kernel/itc-core: @@ -451,6 +477,10 @@ rows: - implements model/task: - uses +- artifact: practice/intake-and-assimilation + targets: + kernel/itc-core: + - conforms_to - artifact: profile/small-saas targets: kernel/itc-core: diff --git a/infospace/infospace.yaml b/infospace/infospace.yaml index f8da63d..12cd1de 100644 --- a/infospace/infospace.yaml +++ b/infospace/infospace.yaml @@ -31,6 +31,8 @@ disciplines: path: models/network/InfoTechCanonNetworkModel.md - name: Observability Model path: models/observability/InfoTechCanonObservabilityModel.md + - name: Capability Model + path: models/capability/InfoTechCanonCapabilityModel.md - name: Tagging Standard path: standards/tagging/InfoTechCanonTaggingStandard.md - name: CARING Access Governance Standard diff --git a/infospace/models/capability/InfoTechCanonCapabilityModel.md b/infospace/models/capability/InfoTechCanonCapabilityModel.md new file mode 100644 index 0000000..4e8b333 --- /dev/null +++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md @@ -0,0 +1,411 @@ +--- +id: itc-cap:CapabilityModel +title: InfoTechCanon Capability Model +short_name: ITC-CAP +type: domain-model +standard_family: InfoTechCanon +repository_context: info-tech-canon +recommended_path: models/capability/InfoTechCanonCapabilityModel.md +status: proposed +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 +assimilation: assimilation/it-capability-canon +disposition: adapt +canonical_owner: InfoTechCanonCapabilityModel +namespace: itc-cap +classification: model +primary_cluster: capability +catalog: models/capability/capabilities.yaml +imports: + - InfoTechCanonCore + - InfoTechCanonLandscapeModel + - InfoTechCanonGovernanceModel + - InfoTechCanonPurposeDemandExtension + - InfoTechCanonObservabilityModel +related: + - InfoTechCanonKernelMap + - InfoTechCanonDataModel + - InfoTechCanonDevSecOpsModel + - InfoTechCanonNetworkModel + - InfoTechCanonAccessControlModel + - InfoTechCanonSecurityModel + - InfoTechCanonTaskModel + - InfoTechCanonCaringAccessGovernanceStandard +owned_concepts: + - Capability + - CapabilityDomain + - CapabilityProfile + - CapabilityContract + - CapabilityRequirement + - CapabilityProvider + - CapabilityProvision + - CapabilityMaturityLevel + - CapabilityQualityDimension + - CapabilityEvidenceHook + - CapabilityResourceClass + - CapabilityInclusionRule +created_at: 2026-08-14 +updated_at: 2026-08-14 +--- + +# InfoTechCanon Capability Model + +**Short Name:** `ITC-CAP` +**Document Status:** Proposed (assimilated, not yet promoted) +**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` + +--- + +# 1. Purpose + +The **InfoTechCanon Capability Model** defines what an information system must be +**able to do**, independently of how that ability is implemented. + +Every other InfoTechCanon model describes a *structure*: landscapes, data, tasks, +policies, telemetry, delivery flow, access. None of them names the abilities those +structures exist to deliver. The Landscape Model has deferred this ground +explicitly since RC1 (§11.4: "The Landscape Model should keep only +landscape-relevant references once a dedicated strategy/capability standard +exists"). This model occupies it. + +It sits deliberately between product and technology: + +```text +Consumer purpose / product + │ requires + ▼ +Capability ← owned here + │ provided by + ▼ +Service / provider ← ITC-LAND + │ implemented by + ▼ +Technology ← ITC-LAND + │ consumes + ▼ +Resource classes → cost ← classification owned here +``` + +--- + +# 2. Scope + +## 2.1 In Scope + +- the concept of a capability and its identity; +- capability profiles, quality dimensions, and evidence hooks; +- 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; +- admission rules governing what may become a canonical capability; +- the canonical capability baseline held in `capabilities.yaml`. + +## 2.2 Out of Scope + +- landscape entities, services, technologies, and runtime resources — ITC-LAND; +- policy, control, and evidence semantics — ITC-GOV; +- permission, grant, and authorization-decision semantics — ITC-ACCESS; +- telemetry, SLO measurement, and health — ITC-OBS; +- delivery pipeline semantics — ITC-DEVSECOPS; +- domain-specific business capabilities (hospital admission, underwriting, + warehouse picking) — outside InfoTechCanon; +- product features, protocols, and named technologies. + +--- + +# 3. Core Principle + +> A capability is an abstract, implementation-independent ability that an +> information system, service, platform, or product may require or provide. + +Technologies are never capabilities: + +```text +Authentication capability +Keycloak implementation + +Backup & Restore capability +pgBackRest implementation + +Object Persistence capability +S3 implementation +``` + +The model is expected to remain stable while technologies, vendors, protocols, +and architectures change beneath it. + +--- + +# 4. Concepts + +## 4.1 Capability + +An abstract ability, identified by a stable dotted id (`identity.authentication`). +A capability has a purpose, profiles, quality dimensions, evidence hooks, and +relationships — but no maturity, no cost, and no implementation. + +**Capability ids are durable interfaces.** Renaming or removing one requires +explicit migration semantics. + +## 4.2 CapabilityDomain + +A navigation grouping (`identity`, `data`, `commerce`, …). Domains carry **no +semantics**: the model is a graph, per Core §6.4 *Network Before Tree*. +Capabilities may depend on or compose capabilities across domain boundaries. + +## 4.3 CapabilityProfile + +A constrained specialization of a capability that does not change its identity — +subject, assurance level, protocol, consistency, tenancy, geography, and so on. + +> **Distinction.** A `CapabilityProfile` is *not* a canon `Profile` (Core §8.6). +> A canon Profile constrains canon artifacts for an implementation context (e.g. +> `small-saas`). A CapabilityProfile constrains one capability. A canon Profile +> may *select* capability profiles; it is not one. + +Prefer a new profile over a new capability whenever the underlying ability is +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. + +## 4.5 CapabilityRequirement + +A statement that a system, product, or consumer purpose needs a capability at a +minimum maturity: + +```yaml +requires: + - capability: identity.authentication + minimum_maturity: D5 + - capability: data.backup + minimum_maturity: D5 +``` + +A CapabilityRequirement is a **typed `DemandSignal`** (ITC-GOV Purpose and Demand +extension) carrying a minimum maturity. It does not introduce a parallel +requirement vocabulary. + +## 4.6 CapabilityProvider + +A role played by a landscape entity — a service, service instance, platform team, +or external provider — that supplies a capability in a context. The entity itself +is owned by ITC-LAND; only the role is named here. + +## 4.7 CapabilityProvision + +The binding of **provider × capability × context**. Maturity, evidence, and +resource consumption all attach here. + +```yaml +provision: + provider: auth.prod.eu + capability: identity.authentication + environment: production + maturity: D6 +``` + +## 4.8 CapabilityMaturityLevel + +| Level | State | Meaning | +|---|---|---| +| `D0` | Absent | Capability is not provided | +| `D1` | Experimental | Proof of concept or exploratory implementation | +| `D2` | Available | A provider exists and can be consumed | +| `D3` | Usable | Documented and practically consumable | +| `D4` | Production | Approved for production dependency | +| `D5` | Reliable | Reliability is measured and actively controlled | +| `D6` | Scalable | Capacity and operational scaling are demonstrated | +| `D7` | Strategic | Governed, reusable, deliberately evolved as a platform capability | + +Maturity is **not** a canon artifact status (Core §10) and **not** a conformance +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. + +## 4.10 CapabilityEvidenceHook + +The evidence types expected to substantiate a provision (`successful_restore_test`, +`measured_rpo`, `policy_tests`). Evidence semantics are imported from ITC-GOV; +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 | + +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?"). + +--- + +# 5. Normative Rules + +**CAP-R1** A Capability MUST be implementation-independent. Naming a technology, +product, protocol, or vendor as a capability is invalid. + +**CAP-R2** Maturity MUST attach to a CapabilityProvision. A maturity claim on a +Capability is invalid: + +```yaml +# invalid # valid +capability: identity.authentication provider: auth.prod.eu +maturity: D5 capability: identity.authentication + maturity: D5 +``` + +**CAP-R3** Every Capability MUST declare `anchors` — the canon model(s) owning the +concepts it exercises — or carry an explicit `anchor_note` recording that it is +new canon surface with no owner yet. + +**CAP-R4** A Capability MUST NOT define concepts owned elsewhere. `security.policy` +imports ITC-GOV `Policy` and `Control`; `identity.authorization` imports +ITC-ACCESS `Permission`, `Grant`, and `AuthorizationDecision`. (Core §6.2, §6.3.) + +**CAP-R5** Capability ids MUST be treated as durable interfaces. Rename or removal +requires a ChangeRecord with migration semantics and a canon major version. + +**CAP-R6** A specialization that leaves the underlying ability unchanged MUST be +expressed as a CapabilityProfile, not a new Capability. + +**CAP-R7** The Markdown document MUST NOT restate capability definitions held in +`capabilities.yaml`. + +--- + +# 6. Admission Rules + +A concept enters the canonical capability set only if it is: + +1. **implementation-independent** — survives replacement of the technology; +2. **reusable** — occurs across materially different products or systems; +3. **demandable** — a system can meaningfully require it; +4. **providable** — something can meaningfully provide it; +5. **testable** — evidence can show it exists and functions; +6. **profileable** — specializations expressible as profiles; +7. **stable** — likely to outlive individual products, protocols, and vendors. + +Explicitly excluded: technologies; protocols and standards; product features; and +domain-specific business capabilities. + +--- + +# 7. Relationships + +Capability to capability: + +| Type | Meaning | +|---|---| +| `depends_on` | The capability normally requires another to operate | +| `may_use` | May use another without conceptual dependency | +| `composes` | A higher-level capability or pattern built from lower-level ones | + +Landscape and consumer to capability: + +| Type | Meaning | +|---|---| +| `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 | + +Traversal from need to cost: + +```text +ConsumerPurpose --requires--> Capability <--provides-- Service + │ implements + ▼ + Technology + │ consumes + ▼ + C / S / N / I / P +``` + +--- + +# 8. Catalog + +The baseline is **41 capabilities across 8 navigation domains**, held in +`models/capability/capabilities.yaml`. + +| Domain | Count | Capability ids | +|---|---|---| +| Identity & Access | 5 | `identity.lifecycle`, `identity.authentication`, `identity.authorization`, `identity.federation`, `identity.organization` | +| Data & State | 6 | `data.transactional`, `data.object`, `data.cache`, `data.backup`, `data.archive`, `data.search` | +| Integration & Communication | 5 | `integration.api`, `integration.messaging`, `integration.exchange`, `integration.notification`, `integration.traffic` | +| Runtime & Automation | 5 | `runtime.execution`, `runtime.configuration`, `runtime.scheduling`, `runtime.workflow`, `runtime.deployment` | +| Operations & Assurance | 5 | `operations.observability`, `operations.alerting`, `operations.audit`, `operations.recovery`, `operations.continuity` | +| Security & Governance | 6 | `security.secrets`, `security.keys`, `security.policy`, `security.vulnerability`, `governance.evidence`, `governance.lifecycle` | +| Commerce | 4 | `commerce.metering`, `commerce.billing`, `commerce.payment`, `commerce.entitlement` | +| Intelligence | 5 | `intelligence.generation`, `intelligence.extraction`, `intelligence.embedding`, `intelligence.retrieval`, `intelligence.reasoning` | + +Seven capabilities (`commerce.metering`, `commerce.billing`, `commerce.payment`, +`intelligence.generation`, `intelligence.extraction`, `intelligence.embedding`, +`intelligence.reasoning`) are **unanchored** — new canon surface with no owning +model. This is accepted at `proposed` status and tracked as OQ-5. + +--- + +# 9. Boundary with Other Models + +| 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-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. | +| ITC-OBS | Owns telemetry, SLO measurement, health — the source of measured maturity evidence. | +| ITC-DATA | Owns datasets, schemas, classification, lineage, retention. `data.*` capabilities are abilities over those assets. | +| ITC-DEVSECOPS | Owns source→artifact→release→deployment. `runtime.deployment` anchors there. | +| ITC-NET | Owns addressing, routing, exposure, reachability. `integration.traffic` anchors there. | +| ITC-TASK | Owns work items, actions, dependencies. `runtime.workflow` is the ability to orchestrate them. | + +--- + +# 10. Status and Promotion + +This model enters the canon at status `proposed`. Promotion requires: + +1. resolution of assimilation open question **OQ-2** (the `governance.*` id prefix + inside the Security & Governance domain) — blocking, because ids are durable + interfaces; +2. publication of `capability.schema.yaml` validating contracts; +3. at least one canon Profile expressing a real capability requirement set with + evidence; +4. formal mapping artifacts under `infospace/mappings/` for each anchor. + +Tracked in `ITC-WP-0014`. + +--- + +# 11. Provenance + +Adapted from the Information Technology Capability Canon (ITCC) v0.1 under +disposition `adapt`. The frozen source snapshot, comparison matrix, mappings, +proposed changes, decision record, and open questions are held in +`infospace/assimilation/it-capability-canon/`. + +Changes made on adoption: `Profile` renamed `CapabilityProfile`; `Provision` made +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. diff --git a/infospace/models/capability/capabilities.yaml b/infospace/models/capability/capabilities.yaml new file mode 100644 index 0000000..5fc7f4e --- /dev/null +++ b/infospace/models/capability/capabilities.yaml @@ -0,0 +1,1000 @@ +# InfoTechCanon Capability Catalog +# +# Canonical machine-readable source of truth for the capability baseline. +# The normative prose lives in InfoTechCanonCapabilityModel.md; capability +# definitions are NOT duplicated there. +# +# Adapted from ITCC v0.1 via assimilation/it-capability-canon. +# Capability ids are durable interfaces: renaming or removing one requires +# explicit migration semantics. +canon: + id: itc-cap + name: InfoTechCanon Capability Model — Capability Catalog + short_name: ITC-CAP + artifact_id: model/capability + version: 0.1.0 + status: proposed + canon_version: 0.2.0 + purpose: Canonical, implementation-independent catalog of the abilities an information system may require + or provide. + normative_document: models/capability/InfoTechCanonCapabilityModel.md + provenance: + assimilation: assimilation/it-capability-canon + source_body: Information Technology Capability Canon (ITCC) + source_version: '0.1' + source_path: infospace/assimilation/it-capability-canon/source/capabilities.yaml + disposition: adapt +resource_classes: +- id: C + name: Compute + description: Generic execution capacity. + note: Consumed by a capability provision, never by an abstract capability. +- id: S + name: Storage + description: Persistence capacity. + 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. +- id: I + name: Intelligence + 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: 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 + description: Capability is not provided. + applies_to: capability_provision +- id: D1 + name: Experimental + description: Proof of concept or exploratory implementation. + applies_to: capability_provision +- id: D2 + name: Available + description: A provider exists and can be consumed. + applies_to: capability_provision +- id: D3 + name: Usable + description: Documented and practically consumable. + applies_to: capability_provision +- id: D4 + name: Production + description: Approved for production dependency. + applies_to: capability_provision +- id: D5 + name: Reliable + description: Reliability is measured and actively controlled. + applies_to: capability_provision +- id: D6 + name: Scalable + description: Capacity and operational scaling are demonstrated. + applies_to: capability_provision +- id: D7 + name: Strategic + description: Governed, reusable, and deliberately evolved as a platform capability. + applies_to: capability_provision +relationship_types: +- id: depends_on + description: Capability normally requires another capability to operate. +- id: may_use + description: Capability may use another capability without conceptual dependency. +- id: composes + description: A higher-level capability or pattern is composed from lower-level capabilities. +- id: requires + description: A landscape entity requires a capability. +- id: provides + description: A provider supplies a capability. +- id: implements + description: A technology or implementation realizes a provider or capability provision. +- id: consumes + description: A provider or implementation consumes economic resources. +domains: +- id: identity + name: Identity & Access + navigation_only: true + capabilities: + - id: identity.lifecycle + name: Identity Lifecycle + purpose: Create, maintain, suspend, recover, and remove identities over time. + anchors: + - model/organization + - model/access-control + profiles: + - human + - machine + - external + - privileged + quality_dimensions: + - provisioning_latency + - deprovisioning_latency + - recovery + - ownership + evidence_hooks: + - 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. + anchors: + - model/access-control + profiles: + - human + - machine + - password + - passkey + - mfa + - passwordless + - high-assurance + quality_dimensions: + - assurance + - availability + - latency + - factor_support + evidence_hooks: + - 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. + anchors: + - model/access-control + - standard/caring + profiles: + - rbac + - abac + - relationship-based + - policy-based + quality_dimensions: + - decision_latency + - policy_coverage + - explainability + evidence_hooks: + - 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. + anchors: + - model/access-control + profiles: + - workforce + - customer + - partner + - machine + quality_dimensions: + - trust_scope + - protocol_support + - availability + 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. + anchors: + - model/organization + profiles: + - organization + - team + - tenant + - hierarchy + - delegation + quality_dimensions: + - isolation + - delegation + - hierarchy_depth + evidence_hooks: + - tenant_isolation_tests + - membership_records + typical_resource_classes: *id001 +- id: data + name: Data & State + navigation_only: true + capabilities: + - id: data.transactional + name: Transactional Persistence + purpose: Persist structured mutable state with defined consistency and transaction semantics. + anchors: + - model/data + profiles: + - relational + - document + - key-value + quality_dimensions: + - consistency + - durability + - availability + - latency + - throughput + 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. + anchors: + - model/data + profiles: + - blob + - document + - artifact + quality_dimensions: + - durability + - availability + - retention + - size_limits + 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. + anchors: + - model/data + - model/landscape + profiles: + - local + - distributed + - content + quality_dimensions: + - hit_rate + - latency + - eviction_policy + - freshness + 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 + after loss, corruption, or erroneous modification. + anchors: + - model/data + profiles: + - database + - object + - volume + quality_dimensions: + - rpo + - rto + - retention + - isolation + - geographical_separation + - restore_validation + evidence_hooks: + - successful_backup + - successful_restore_test + - measured_rpo + - measured_rto + typical_resource_classes: *id002 + depends_on: + - data.object + may_use: + - runtime.scheduling + - operations.observability + - id: data.archive + name: Archive & Retention + purpose: Preserve information for long-term retention under defined lifecycle, integrity, and retrieval + rules. + anchors: + - model/data + - model/governance + profiles: + - regulatory + - operational + - cold + quality_dimensions: + - retention + - immutability + - retrievability + - integrity + evidence_hooks: + - 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. + anchors: + - model/data + - model/information-space + profiles: + - lexical + - structured + - faceted + - semantic + - hybrid + quality_dimensions: + - latency + - recall + - precision + - freshness + evidence_hooks: + - search_tests + - latency_metrics + typical_resource_classes: *id002 +- id: integration + name: Integration & Communication + navigation_only: true + capabilities: + - id: integration.api + name: API Exposure + purpose: Expose machine-consumable interfaces through which systems can invoke or retrieve functionality. + anchors: + - model/landscape + - model/network + profiles: + - request-response + - streaming + - public + - internal + quality_dimensions: + - availability + - latency + - compatibility + - rate_limits + 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. + anchors: + - model/landscape + profiles: + - queue + - pub-sub + - event-stream + - event-bus + quality_dimensions: + - delivery_semantics + - ordering + - durability + - latency + - throughput + 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. + anchors: + - model/data + - model/landscape + profiles: + - batch + - file + - stream + - managed-transfer + quality_dimensions: + - integrity + - latency + - throughput + - retries + evidence_hooks: + - transfer_tests + - integrity_checks + typical_resource_classes: *id003 + - id: integration.notification + name: Notification + purpose: Deliver information to human users or external endpoints. + anchors: + - model/landscape + profiles: + - email + - sms + - push + - chat + - webhook + - physical-mail + quality_dimensions: + - delivery_rate + - latency + - channel_support + - tracking + 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. + anchors: + - model/network + profiles: + - load-balancing + - ingress + - service-routing + - rate-limiting + - api-gateway + quality_dimensions: + - availability + - latency + - routing_correctness + - capacity + evidence_hooks: + - routing_tests + - availability_metrics + typical_resource_classes: *id003 +- id: runtime + name: Runtime & Automation + navigation_only: true + capabilities: + - id: runtime.execution + name: Workload Execution + purpose: Execute software workloads with defined runtime resources and isolation. + anchors: + - model/landscape + profiles: + - process + - container + - virtual-machine + - function + - batch + quality_dimensions: + - availability + - isolation + - startup_time + - capacity + 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. + anchors: + - model/landscape + - model/devsecops + profiles: + - static + - dynamic + - environment + - feature + quality_dimensions: + - versioning + - propagation_latency + - consistency + - auditability + 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. + anchors: + - model/landscape + - model/task + profiles: + - cron + - calendar + - delay + - recurring + quality_dimensions: + - timing_accuracy + - delivery_guarantee + - 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. + anchors: + - model/task + profiles: + - durable + - human-in-the-loop + - saga + - agentic + quality_dimensions: + - durability + - retry_semantics + - visibility + - recovery + evidence_hooks: + - workflow_completion_records + - recovery_tests + typical_resource_classes: *id004 + may_use: + - integration.messaging + - runtime.scheduling + - integration.notification + - id: runtime.deployment + name: Deployment & Release + purpose: Bring defined software versions and configurations into operational environments in a controlled + manner. + anchors: + - model/devsecops + profiles: + - rolling + - blue-green + - canary + - immutable + quality_dimensions: + - rollback + - lead_time + - failure_rate + - traceability + evidence_hooks: + - deployment_records + - rollback_test + typical_resource_classes: *id004 +- id: operations + name: Operations & Assurance + navigation_only: true + capabilities: + - id: operations.observability + name: Observability + purpose: Establish operational state and behavior from telemetry such as logs, metrics, traces, events, + and derived signals. + anchors: + - model/observability + profiles: + - logs + - metrics + - traces + - events + - profiles + quality_dimensions: + - coverage + - freshness + - retention + - queryability + 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. + anchors: + - model/observability + profiles: + - threshold + - anomaly + - event + - slo + quality_dimensions: + - detection_latency + - precision + - delivery + - escalation + evidence_hooks: + - alert_tests + - incident_linkage + typical_resource_classes: *id005 + may_use: + - operations.observability + - integration.notification + - id: operations.audit + name: Audit + purpose: Produce attributable historical evidence about relevant actions, changes, and decisions. + anchors: + - model/governance + profiles: + - security + - administrative + - business + - decision + quality_dimensions: + - integrity + - attribution + - retention + - queryability + 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. + anchors: + - model/observability + - model/security + profiles: + - restart + - failover + - rebuild + - disaster-recovery + quality_dimensions: + - rto + - recovery_success_rate + - automation + evidence_hooks: + - recovery_tests + - incident_recovery_records + typical_resource_classes: *id005 + may_use: + - data.backup + - operations.observability + - id: operations.continuity + name: Continuity + purpose: Maintain acceptable service operation despite disruption. + anchors: + - model/governance + profiles: + - high-availability + - multi-zone + - multi-region + - degraded-mode + quality_dimensions: + - availability + - fault_tolerance + - capacity_reserve + evidence_hooks: + - continuity_tests + - availability_metrics + typical_resource_classes: *id005 +- id: security + name: Security & Governance + navigation_only: true + capabilities: + - id: security.secrets + name: Secret Management + purpose: Protect, distribute, rotate, and revoke confidential credentials and secrets. + anchors: + - model/security + profiles: + - static + - dynamic + - application + - human + quality_dimensions: + - rotation + - access_control + - auditability + - availability + 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. + anchors: + - model/security + profiles: + - tls + - signing + - encryption + - pki + quality_dimensions: + - rotation + - revocation + - expiry_control + - key_protection + 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. + anchors: + - model/governance + - model/security + profiles: + - access + - configuration + - admission + - compliance + quality_dimensions: + - coverage + - decision_latency + - versioning + - explainability + 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. + anchors: + - model/security + profiles: + - source + - dependency + - image + - runtime + - infrastructure + quality_dimensions: + - coverage + - time_to_detect + - time_to_remediate + - risk_acceptance + evidence_hooks: + - scan_results + - remediation_records + typical_resource_classes: *id006 + - id: governance.evidence + name: Compliance Evidence + purpose: Produce and maintain evidence supporting governance, assurance, certification, or compliance + assertions. + anchors: + - model/governance + profiles: + - technical + - organizational + - regulatory + quality_dimensions: + - completeness + - traceability + - freshness + - integrity + 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 + transitions. + anchors: + - model/governance + - model/data + profiles: + - retention + - deletion + - legal-hold + - classification + quality_dimensions: + - coverage + - enforcement + - traceability + evidence_hooks: + - lifecycle_policy + - deletion_records + - retention_evidence + typical_resource_classes: *id007 +- id: commerce + name: Commerce + navigation_only: true + capabilities: + - id: commerce.metering + name: Metering + purpose: Measure usage or activity that is commercially or contractually relevant. + anchors: [] + profiles: + - usage + - event + - capacity + - time + quality_dimensions: + - accuracy + - completeness + - latency + - auditability + 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 + purpose: Calculate amounts owed based on contracts, pricing rules, entitlements, metering, or events. + anchors: [] + profiles: + - subscription + - usage-based + - one-time + - hybrid + quality_dimensions: + - accuracy + - explainability + - reconciliation + - currency_support + evidence_hooks: + - invoice_tests + - billing_reconciliation + typical_resource_classes: *id008 + may_use: + - commerce.metering + - commerce.entitlement + anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5. + - id: commerce.payment + name: Payment + purpose: Transfer monetary value between parties. + anchors: [] + profiles: + - card + - sepa + - bank-transfer + - wallet + - payout + - recurring + quality_dimensions: + - success_rate + - settlement_time + - currency_support + - refund_support + evidence_hooks: + - payment_records + - settlement_reconciliation + typical_resource_classes: *id008 + may_use: + - identity.authentication + - operations.audit + - integration.api + anchor_note: No anchoring canon model yet — new canon surface. See assimilation open question OQ-5. + - id: commerce.entitlement + name: Entitlement + purpose: Determine which products, features, capacities, or service levels a customer or actor is + contractually allowed to use. + anchors: + - model/access-control + profiles: + - feature + - capacity + - plan + - time-bound + quality_dimensions: + - decision_latency + - consistency + - auditability + evidence_hooks: + - entitlement_tests + - decision_records + typical_resource_classes: *id008 + may_use: + - identity.authorization +- id: intelligence + name: Intelligence + navigation_only: true + capabilities: + - id: intelligence.generation + name: Generation + purpose: Produce novel information representations from context or instructions. + anchors: [] + profiles: + - text + - image + - audio + - video + - code + - structured-data + quality_dimensions: + - quality + - latency + - cost + - safety + 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 + purpose: Derive structured information, labels, attributes, or classifications from input. + anchors: [] + profiles: + - ocr + - document-extraction + - entity-extraction + - classification + - speech-recognition + quality_dimensions: + - accuracy + - recall + - precision + - latency + 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 + purpose: Produce machine-usable semantic representations of information. + anchors: [] + profiles: + - text + - image + - multimodal + quality_dimensions: + - dimensionality + - semantic_quality + - latency + - cost + 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 + purpose: Select or rank information according to semantic relevance. + anchors: + - model/information-space + profiles: + - vector + - reranking + - hybrid + - multimodal + quality_dimensions: + - recall + - precision + - ranking_quality + - latency + evidence_hooks: + - retrieval_benchmarks + typical_resource_classes: *id009 + may_use: + - intelligence.embedding + - data.search + - id: intelligence.reasoning + name: Reasoning & Decision + purpose: Derive judgments, plans, decisions, hypotheses, or action proposals from context and constraints. + anchors: [] + profiles: + - analysis + - planning + - decision + - agentic + quality_dimensions: + - task_success + - reliability + - latency + - cost + - explainability + 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/validation/latest.json b/infospace/validation/latest.json index 8610552..38d79cb 100644 --- a/infospace/validation/latest.json +++ b/infospace/validation/latest.json @@ -1,21 +1,16 @@ { "details": { - "artifact_count": 61, - "relationship_count": 277 + "artifact_count": 65, + "relationship_count": 286 }, "errors": [], "metrics": { "coherence_components": 1.0, "consistency_cycles": 0.0, "coverage_ratio": 1.0, - "granularity_entropy": 4.329602269609256, + "granularity_entropy": 4.443367176892838, "redundancy_ratio": 0.0 }, "ok": true, - "warnings": [ - { - "code": "empty_optional_collection", - "path": "infospace/assimilation" - } - ] + "warnings": [] } diff --git a/infospace/views/by-concept.md b/infospace/views/by-concept.md index d94a834..cf8af26 100644 --- a/infospace/views/by-concept.md +++ b/infospace/views/by-concept.md @@ -2,15 +2,17 @@ # By Concept -Concept count: **90** +Concept count: **106** | Concept | Owner | Source | | --- | --- | --- | +| Assimilation — IT Capability Canon (ITCC) v0.1 | `assimilation/it-capability-canon` | `artifact_title` | | CARING Kubernetes RBAC Benchmark | `benchmark/caring/kubernetes-rbac` | `artifact_title` | | Kubernetes RBAC CARING Access Descriptors | `benchmark/caring/kubernetes-rbac/access-descriptors` | `artifact_title` | | Kubernetes RBAC To CARING Mapping | `benchmark/caring/kubernetes-rbac/caring-mapping` | `artifact_title` | | Kubernetes RBAC Benchmark Findings And Canon Pressure | `benchmark/caring/kubernetes-rbac/findings` | `artifact_title` | | Kubernetes RBAC Native Concept Map | `benchmark/caring/kubernetes-rbac/native-concepts` | `artifact_title` | +| InfoTechCanon Capability Catalog | `capability-catalog/itc-cap` | `artifact_title` | | Repo Scoping Canon Benefit Analysis | `comparison/repo-scoping/canon-benefit-analysis` | `artifact_title` | | Repo Scoping Consumer Workplan Brief | `comparison/repo-scoping/consumer-workplan-brief` | `artifact_title` | | Repo Scoping Canon Extension Candidates | `comparison/repo-scoping/extension-candidates` | `artifact_title` | @@ -32,6 +34,19 @@ Concept count: **90** | InfoTechCanon Kernel Map | `kernel/itc-kernel-map` | `artifact_title` | | Purpose Demand Governance Extension Candidates | `mapping/purpose-demand-governance-candidates` | `artifact_title` | | InfoTechCanon Access Control Model | `model/access-control` | `artifact_title` | +| InfoTechCanon Capability Model | `model/capability` | `artifact_title` | +| Capability | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityDomain | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityProfile | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityContract | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityRequirement | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityProvider | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityProvision | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityMaturityLevel | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityQualityDimension | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityEvidenceHook | `model/capability` | `frontmatter.owned_concepts` | +| CapabilityResourceClass | `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` | | InfoTechCanon Governance Model | `model/governance` | `artifact_title` | @@ -54,6 +69,7 @@ Concept count: **90** | InfoTechCanon Task Model | `model/task` | `artifact_title` | | Intent Scope Purposes Pattern | `pattern/intent-scope-purposes` | `artifact_title` | | IntentScopePurposePattern | `pattern/intent-scope-purposes` | `frontmatter.owned_concepts` | +| Intake and Assimilation Practice | `practice/intake-and-assimilation` | `artifact_title` | | Small SaaS System Profile | `profile/small-saas` | `artifact_title` | | Canon Consumer Alignment Review Kit | `review-kit/alignment` | `artifact_title` | | Canon Model And Standard Selection Guide | `review-kit/alignment/model-selection-guide` | `artifact_title` | diff --git a/infospace/views/by-mapping-target.md b/infospace/views/by-mapping-target.md index 053942a..c1828c3 100644 --- a/infospace/views/by-mapping-target.md +++ b/infospace/views/by-mapping-target.md @@ -2,6 +2,10 @@ # By Mapping Target +## `assimilation/it-capability-canon` + +- `model/capability` via `derived_from` + ## `benchmark/caring/kubernetes-rbac` - `benchmark/caring/kubernetes-rbac/access-descriptors` via `part_of` @@ -11,6 +15,10 @@ - `review-kit/alignment` via `uses` - `review-kit/alignment/model-selection-guide` via `uses` +## `capability-catalog/itc-cap` + +- `model/capability` via `introduces` + ## `comparison/repo-scoping/report` - `comparison/repo-scoping/canon-benefit-analysis` via `part_of` @@ -46,9 +54,11 @@ ## `kernel/itc-core` +- `assimilation/it-capability-canon` via `conforms_to` - `concept-catalog/purpose-demand` via `conforms_to` - `kernel/itc-kernel-map` via `maps` - `model/access-control` via `conforms_to` +- `model/capability` via `conforms_to` - `model/data` via `conforms_to` - `model/devsecops` via `conforms_to` - `model/governance` via `conforms_to` @@ -60,6 +70,7 @@ - `model/purpose-demand-extension` via `conforms_to` - `model/security` via `conforms_to` - `model/task` via `conforms_to` +- `practice/intake-and-assimilation` via `conforms_to` - `profile/small-saas` via `conforms_to` - `review-kit/alignment` via `conforms_to` - `standard/caring` via `conforms_to` @@ -127,6 +138,7 @@ - `kernel/itc-kernel-map` via `maps` - `mapping/purpose-demand-governance-candidates` via `maps` - `model/access-control` via `uses` +- `model/capability` via `uses` - `model/data` via `uses` - `model/purpose-demand-extension` via `extends` - `pattern/intent-scope-purposes` via `uses` @@ -156,6 +168,7 @@ - `conformance/railiance-fabric/entity-edge-capture-criteria` via `uses` - `conformance/railiance-fabric/mapping-expectations` via `maps` - `kernel/itc-kernel-map` via `maps` +- `model/capability` via `uses` - `profile/small-saas` via `requires` - `review-kit/alignment/model-selection-guide` via `uses` - `small-saas/service/billing-portal` via `uses` @@ -180,6 +193,7 @@ - `conformance/railiance-fabric/entity-edge-capture-criteria` via `uses` - `conformance/railiance-fabric/mapping-expectations` via `maps` - `kernel/itc-kernel-map` via `maps` +- `model/capability` via `uses` - `profile/small-saas` via `requires` - `review-kit/alignment/model-selection-guide` via `uses` - `small-saas/evidence/access-review-2026-05` via `uses` @@ -217,6 +231,7 @@ - `evaluation/user-engine/questions` via `uses` - `example/consumer-purpose-portfolio` via `illustrates` - `mapping/purpose-demand-governance-candidates` via `maps` +- `model/capability` via `uses` - `pattern/intent-scope-purposes` via `implements` - `review-kit/alignment` via `uses` - `review-kit/alignment/model-selection-guide` via `uses` diff --git a/infospace/views/import-matrix.md b/infospace/views/import-matrix.md index 80de575..5ff190a 100644 --- a/infospace/views/import-matrix.md +++ b/infospace/views/import-matrix.md @@ -2,66 +2,70 @@ # Import Matrix -| Artifact | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | -| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | `stress_tests` | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `uses` | -| `benchmark/caring/kubernetes-rbac/access-descriptors` | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | -| `benchmark/caring/kubernetes-rbac/caring-mapping` | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | -| `benchmark/caring/kubernetes-rbac/findings` | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | -| `benchmark/caring/kubernetes-rbac/native-concepts` | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | -| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | `maps` | -| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `proposes` | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/frame` | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | -| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | -| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | `maps` | `maps` | `maps` | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | `evaluates` | | | | | | | | | | | | | | | | | | | | `uses` | | | -| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | -| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | | `uses` | | | | | `uses` | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | -| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | `uses` | | | | | | | | | | | | | | | | | | | | | | | -| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | -| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/data` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/governance` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/network` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/purpose-demand-extension` | | | | | | | | | | | `introduces` | | | | | | | | | | | | `conforms_to` | | | | | | `extends` | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/security` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `model/task` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | -| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | `requires` | | `requires` | -| `review-kit/alignment` | `uses` | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | `uses` | | | -| `review-kit/alignment/model-selection-guide` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | -| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | -| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `instantiates` | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | -| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | -| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | | | `instantiates` | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | -| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `instantiates` | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | -| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | `instantiates` | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | -| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | -| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | -| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `instantiates` | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | -| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | -| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | -| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | -| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | -| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `imports` | `imports` | `imports` | `imports` | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | `imports` | -| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | `imports` | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | -| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | +| Artifact | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `uses` | +| `benchmark/caring/kubernetes-rbac/access-descriptors` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | +| `benchmark/caring/kubernetes-rbac/caring-mapping` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | `maps` | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | +| `benchmark/caring/kubernetes-rbac/findings` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | +| `benchmark/caring/kubernetes-rbac/native-concepts` | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | +| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | +| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `proposes` | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/frame` | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | +| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | +| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | `maps` | `maps` | `maps` | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | `evaluates` | | | | | | | | | | | | | | | | | | | | `uses` | | | +| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | +| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | `uses` | | `uses` | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | +| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | +| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | +| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/capability` | `derived_from` | | | | | | `introduces` | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/data` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/governance` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/purpose-demand-extension` | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | `conforms_to` | | | | | | | `extends` | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `requires` | | `requires` | `requires` | `requires` | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | `requires` | | `requires` | +| `review-kit/alignment` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | +| `review-kit/alignment/model-selection-guide` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | +| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | +| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | +| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | +| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | | | | `instantiates` | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | +| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `instantiates` | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | +| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | +| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | +| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | +| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `instantiates` | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | +| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | +| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | +| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | +| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | +| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `imports` | | `imports` | `imports` | `imports` | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | `imports` | +| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | `imports` | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | +| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | diff --git a/infospace/views/kernel-overview.md b/infospace/views/kernel-overview.md index b37d24f..3ccee67 100644 --- a/infospace/views/kernel-overview.md +++ b/infospace/views/kernel-overview.md @@ -3,7 +3,7 @@ # Kernel Overview - Infospace: `canon` -- Artifacts: 61 +- Artifacts: 65 ## Artifact Kinds @@ -12,9 +12,11 @@ - `alignment-review-schema`: 1 - `alignment-review-workflow`: 1 - `alignment-scorecard`: 1 +- `assimilation`: 1 - `benchmark-findings`: 1 - `benchmark-workspace`: 1 - `benefit-analysis`: 1 +- `capability-catalog`: 1 - `capture-criteria`: 1 - `caring-mapping`: 1 - `comparison-frame`: 1 @@ -31,11 +33,12 @@ - `kernel`: 2 - `mapping`: 1 - `mapping-expectation`: 1 -- `model`: 11 +- `model`: 12 - `model-extension`: 1 - `model-selection-guide`: 1 - `native-concept-map`: 1 - `pattern`: 1 +- `practice`: 1 - `profile`: 1 - `profile-alignment`: 1 - `profile-artifact`: 13 @@ -47,9 +50,10 @@ - `access_evidenced_by`: 1 - `changes`: 1 - `compares`: 1 -- `conforms_to`: 19 +- `conforms_to`: 22 - `constrained_by`: 1 - `deploys`: 1 +- `derived_from`: 1 - `evaluates`: 2 - `evidenced_by`: 3 - `extends`: 1 @@ -59,7 +63,7 @@ - `implements`: 2 - `imports`: 14 - `instantiates`: 13 -- `introduces`: 1 +- `introduces`: 2 - `isolated_by`: 2 - `maps`: 36 - `member_of`: 1 @@ -72,4 +76,4 @@ - `separates`: 2 - `serves`: 2 - `stress_tests`: 6 -- `uses`: 113 +- `uses`: 117 diff --git a/infospace/views/repository-tree.md b/infospace/views/repository-tree.md index cd935af..80352a6 100644 --- a/infospace/views/repository-tree.md +++ b/infospace/views/repository-tree.md @@ -2,7 +2,7 @@ # Repository Tree -File count: **161** +File count: **175** - `README.md` - `agent/README.md` @@ -32,6 +32,7 @@ File count: **161** - `agent/briefs/kernel-itc-kernel-map.md` - `agent/briefs/mapping-purpose-demand-governance-candidates.md` - `agent/briefs/model-access-control.md` +- `agent/briefs/model-capability.md` - `agent/briefs/model-data.md` - `agent/briefs/model-devsecops.md` - `agent/briefs/model-governance.md` @@ -70,6 +71,17 @@ File count: **161** - `agent/templates/consumer-brief.template.md` - `artifacts/index.yaml` - `assimilation/README.md` +- `assimilation/intake-and-assimilation-practice.md` +- `assimilation/it-capability-canon/ASSIMILATION.md` +- `assimilation/it-capability-canon/assimilation.yaml` +- `assimilation/it-capability-canon/comparison-matrix.md` +- `assimilation/it-capability-canon/extracted-concepts.yaml` +- `assimilation/it-capability-canon/mappings.yaml` +- `assimilation/it-capability-canon/open-questions.md` +- `assimilation/it-capability-canon/proposed-changes.md` +- `assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md` +- `assimilation/it-capability-canon/source/capabilities.yaml` +- `assimilation/it-capability-canon/source-summary.md` - `concepts/purpose-demand.yaml` - `evaluations/railiance-fabric/conformance-pack.yaml` - `evaluations/railiance-fabric/consumer-workplan-brief.md` @@ -105,6 +117,8 @@ File count: **161** - `mappings/README.md` - `mappings/purpose-demand-governance-candidates.yaml` - `models/access-control/InfoTechCanonAccessControlModel.md` +- `models/capability/InfoTechCanonCapabilityModel.md` +- `models/capability/capabilities.yaml` - `models/data/InfoTechCanonDataModel.md` - `models/devsecops/InfoTechCanonDevSecOpsModel.md` - `models/governance/InfoTechCanonGovernanceModel.md` diff --git a/tests/test_cli.py b/tests/test_cli.py index 47679d7..3d7b6ba 100644 --- a/tests/test_cli.py +++ b/tests/test_cli.py @@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None: assert exit_code == 0 payload = json.loads(capsys.readouterr().out) assert payload["ok"] is True - assert payload["infospace"]["artifact_count"] == 61 + assert payload["infospace"]["artifact_count"] == 65 def test_cli_missing_profile_uses_structured_error(capsys) -> None: diff --git a/tests/test_service.py b/tests/test_service.py index c895981..757deb1 100644 --- a/tests/test_service.py +++ b/tests/test_service.py @@ -21,16 +21,18 @@ def test_inspect_canon_counts_artifact_kinds() -> None: assert payload["ok"] is True assert payload["infospace"]["slug"] == "canon" - assert payload["infospace"]["artifact_count"] == 61 + assert payload["infospace"]["artifact_count"] == 65 assert payload["infospace"]["kinds"] == { "access-descriptor-set": 1, "alignment-review-kit": 1, + "assimilation": 1, "alignment-review-schema": 1, "alignment-review-workflow": 1, "alignment-scorecard": 1, "benefit-analysis": 1, "benchmark-findings": 1, "benchmark-workspace": 1, + "capability-catalog": 1, "capture-criteria": 1, "caring-mapping": 1, "comparison-frame": 1, @@ -47,11 +49,12 @@ def test_inspect_canon_counts_artifact_kinds() -> None: "kernel": 2, "mapping": 1, "mapping-expectation": 1, - "model": 11, + "model": 12, "model-extension": 1, "model-selection-guide": 1, "native-concept-map": 1, "pattern": 1, + "practice": 1, "profile-alignment": 1, "profile": 1, "profile-artifact": 13, @@ -61,7 +64,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None: def test_model_and_standard_lists_are_filtered() -> None: - assert list_models()["count"] == 11 + assert list_models()["count"] == 12 assert list_standards()["count"] == 3 @@ -90,14 +93,14 @@ def test_validate_canon_passes_scaffold() -> None: assert payload["ok"] is True assert payload["errors"] == [] assert "warnings" in payload - assert payload["details"]["artifact_count"] == 61 + assert payload["details"]["artifact_count"] == 65 def test_graph_exports_relationship_summary() -> None: payload = artifact_graph() assert payload["ok"] is True - assert payload["graph"]["node_count"] == 61 + assert payload["graph"]["node_count"] == 65 assert payload["graph"]["edge_count"] > 15 diff --git a/workplans/ITC-WP-0014-capability-model-consolidation.md b/workplans/ITC-WP-0014-capability-model-consolidation.md new file mode 100644 index 0000000..22c68de --- /dev/null +++ b/workplans/ITC-WP-0014-capability-model-consolidation.md @@ -0,0 +1,133 @@ +--- +id: ITC-WP-0014 +type: workplan +title: "Capability Model consolidation (post-ITCC assimilation)" +domain: infotech +topic_slug: canon +repo: info-tech-canon +status: proposed +priority: medium +created: "2026-08-14" +updated: "2026-08-14" +depends_on_workplans: + - ITC-WP-0003 + - ITC-WP-0006 +owner: claude +spec_refs: + - infospace/assimilation/it-capability-canon/ASSIMILATION.md + - infospace/assimilation/it-capability-canon/proposed-changes.md + - infospace/assimilation/it-capability-canon/open-questions.md + - infospace/models/capability/InfoTechCanonCapabilityModel.md +--- + +# ITC-WP-0014 — Capability Model Consolidation + +## Goal + +Promote `InfoTechCanonCapabilityModel` from `proposed` to a usable canon model by +closing the items the ITCC v0.1 assimilation deliberately deferred. + +## Intent + +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. + +## Tasks + +### T01 — Resolve the `governance.*` identifier prefix (OQ-2) + +```task +id: ITC-WP-0014-T01 +status: todo +priority: high +``` + +Decide between keeping the ids, renumbering to `security.*`, or splitting the +navigation domain into `security` and `governance` (preferred — preserves every +id). Record as a DecisionRecord. **Blocks promotion beyond `proposed`.** + +### T02 — Publish `capability.schema.yaml` + +```task +id: ITC-WP-0014-T02 +status: todo +priority: high +depends_on: [T01] +``` + +Add the capability contract schema under `infospace/schemas/`, register it in +`infospace/infospace.yaml`, and validate `capabilities.yaml` against it. + +### T03 — Formal mapping artifacts for each anchor + +```task +id: ITC-WP-0014-T03 +status: todo +priority: medium +depends_on: [T02] +``` + +Turn `assimilation/it-capability-canon/mappings.yaml` into per-pair mapping +artifacts under `infospace/mappings/` conforming to `mapping.schema.yaml`. + +### T04 — Small-SaaS capability requirement set + +```task +id: ITC-WP-0014-T04 +status: todo +priority: medium +depends_on: [T02] +``` + +Express a real `CapabilityRequirement` set with provisions and evidence in the +small-saas profile (coordinate with ITC-WP-0004). This is the practical proof +required for promotion. + +### T05 — Landscape and kernel-map revision + +```task +id: ITC-WP-0014-T05 +status: todo +priority: medium +depends_on: [T01] +``` + +Revise `InfoTechCanonLandscapeModel` §11.4 (the deferred strategy/capability note) +to reference ITC-CAP, and add the capability model to +`InfoTechCanonKernelMap`. + +### T06 — Requirement/provision validation in the service surface + +```task +id: ITC-WP-0014-T06 +status: todo +priority: low +depends_on: [T02] +``` + +Extend the CLI/JSON/API surface (ITC-WP-0002) to answer "does this environment +satisfy this product's capability requirements?" — the validator sketched in +source §18. Covers OQ-6. + +### T07 — Promotion review + +```task +id: ITC-WP-0014-T07 +status: todo +priority: medium +depends_on: [T01, T02, T03, T04] +``` + +Promote the model from `proposed` to `draft` or `release-candidate`, bump the +canon version, and write the `CHANGELOG.md` entry. + +## Out of scope + +- 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. diff --git a/workplans/index.yaml b/workplans/index.yaml index efd723b..ca431ee 100644 --- a/workplans/index.yaml +++ b/workplans/index.yaml @@ -179,3 +179,31 @@ workplans: - repository-layout standard placement and extension candidates - registered repository-layout standard - consumer adoption brief + + - id: ITC-WP-0013 + title: Attribute Value Type catalog (Data Model extension) + status: proposed + priority: high + path: workplans/ITC-WP-0013-attribute-value-type-catalog.md + depends_on: + - ITC-WP-0006 + produces: + - reviewed attribute-value-type demand signal + - attribute value type catalog standard section + - machine-readable attribute value type catalog + - consumer alignment note + + - id: ITC-WP-0014 + title: Capability Model consolidation (post-ITCC assimilation) + status: proposed + priority: medium + path: workplans/ITC-WP-0014-capability-model-consolidation.md + depends_on: + - ITC-WP-0003 + - ITC-WP-0006 + produces: + - resolved capability identifier prefix decision + - capability contract schema + - formal capability mapping artifacts + - small-saas capability requirement set + - capability requirement/provision validation surface