# 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`.