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