tegwick
28d5824362
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 <noreply@anthropic.com>
68 lines
5.9 KiB
Markdown
68 lines
5.9 KiB
Markdown
# 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`.
|