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