126 lines
4.8 KiB
Markdown
126 lines
4.8 KiB
Markdown
|
# 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 |
|