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>
4.8 KiB
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 |