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