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>
138 lines
6.2 KiB
Markdown
138 lines
6.2 KiB
Markdown
# Assimilation — Information Technology Capability Canon (ITCC) v0.1
|
||
|
||
**Record:** `assimilation/it-capability-canon`
|
||
**Source:** ITCC v0.1 (`source/ITCapabilityCanonV0.1.md`, `source/capabilities.yaml`)
|
||
**Disposition:** `adapt`
|
||
**Status:** decided
|
||
**Canon version produced:** `0.2.0`
|
||
**Date:** 2026-08-14
|
||
**Practice:** [`../intake-and-assimilation-practice.md`](../intake-and-assimilation-practice.md)
|
||
|
||
---
|
||
|
||
## 1. Intake
|
||
|
||
Both files arrived in `incoming/` and were moved unmodified into `source/` as the
|
||
frozen snapshot. The source document itself (§15) asks to be reconciled with and
|
||
incorporated into InfoTechCanon, so the request is explicit rather than inferred.
|
||
|
||
## 2. Scoping
|
||
|
||
**In scope:** the capability object model, inclusion rules, exclusions, the eight
|
||
navigation domains and 41-capability baseline, capability relationship types, the
|
||
D0–D7 maturity scale, the C/S/N/I/P resource model, evidence hooks, and the
|
||
capability contract shape.
|
||
|
||
**Out of scope:** the proposed CILM landscape model (§15) — the canon Landscape
|
||
Model already owns that ground; and the FinOps cost formula (§13) beyond the
|
||
resource classification itself.
|
||
|
||
## 3. Concept extraction
|
||
|
||
18 concepts extracted — see [`extracted-concepts.yaml`](extracted-concepts.yaml).
|
||
|
||
## 4. Concept comparison
|
||
|
||
See [`comparison-matrix.md`](comparison-matrix.md). Summary:
|
||
|
||
- `missing_concept`: Capability, CapabilityDomain, Provision, MaturityLevel,
|
||
QualityDimension, EvidenceHook, CapabilityContract, ResourceClass, and the
|
||
capability relationship types
|
||
- `already_covered`: Implementation, Evidence, CILM, and four of the source's
|
||
design principles (all four restate existing Core principles)
|
||
- `covered_differently`: Profile (name collision with Core §8.6), Provider
|
||
- `narrower_than_existing`: Requirement (a typed DemandSignal), quality dimensions
|
||
- `viewpoint_difference`: the entire capability baseline against the domain models
|
||
— abilities versus the structures that realize them
|
||
- `conflicting_concept`: one naming conflict only (`governance.*` prefix, OQ-2)
|
||
|
||
## 5. Gap and conflict analysis
|
||
|
||
**Primary gap filled.** The canon models landscape, data, security, delivery,
|
||
network, observability, governance, organization, task, and access, but nowhere
|
||
states *what an information system must be able to do*. The Landscape Model
|
||
defers exactly this (§11.4). Consumers hit the gap in practice: repo-scoping
|
||
already needs `Ability` / `Capability` / `Feature` distinctions.
|
||
|
||
**No definitional conflicts.** Not one source concept redefines a concept an
|
||
existing model owns. The relationship is anchoring, not overlap — which is why
|
||
the disposition is `adapt` rather than `observe`.
|
||
|
||
**Conflicts found:** (1) `Profile` name collision, resolved by renaming to
|
||
`CapabilityProfile`; (2) inconsistent `governance.*` ID prefix, unresolved and
|
||
recorded as OQ-2, blocking promotion beyond `proposed`.
|
||
|
||
**Risk.** A capability catalog is the kind of artifact that quietly becomes a
|
||
second ontology. Mitigated by PC-3: every capability must name the canon model(s)
|
||
that own the concepts it exercises.
|
||
|
||
## 6. Canon impact proposal
|
||
|
||
Eight proposals — see [`proposed-changes.md`](proposed-changes.md). All eight were
|
||
accepted; PC-6 is an accepted *rejection* (CILM not adopted). Six further items
|
||
are deferred to `ITC-WP-0014`.
|
||
|
||
## 7. Mapping and publication
|
||
|
||
[`mappings.yaml`](mappings.yaml) records 26 concept-level mappings to canonical
|
||
owners. Formal per-pair mapping artifacts under `infospace/mappings/` are deferred
|
||
to ITC-WP-0014.
|
||
|
||
Published as:
|
||
|
||
- `infospace/models/capability/InfoTechCanonCapabilityModel.md`
|
||
- `infospace/models/capability/capabilities.yaml`
|
||
|
||
---
|
||
|
||
## Decision Record
|
||
|
||
**Context.** InfoTechCanon has no owner for abstract capability. A well-formed
|
||
draft vocabulary (41 capabilities, machine-readable, explicitly written for
|
||
reconciliation with InfoTechCanon) was submitted for absorption. The Landscape
|
||
Model has deferred this ground since RC1.
|
||
|
||
**Decision.** Disposition `adapt`. Adopt the vocabulary as a new domain model,
|
||
`InfoTechCanonCapabilityModel`, restructured to canon shape: canon frontmatter and
|
||
declared ownership, imports instead of redefinitions, per-capability anchors to
|
||
owning models, `Profile` renamed to `CapabilityProfile`, `Provision` made
|
||
explicit, CILM rejected. The artifact enters at status `proposed`.
|
||
|
||
**Options considered.**
|
||
|
||
1. *`observe`* — record and change nothing. Rejected: leaves a known gap open while
|
||
consumers work around it.
|
||
2. *`map` only* — map the source to existing models without a new artifact.
|
||
Rejected: there is no artifact to map *to*; capability has no owner.
|
||
3. *`adopt` as-is* — take the document in unchanged. Rejected: it carries a name
|
||
collision on `Profile`, a competing landscape model, an implicit provision
|
||
bearer, and no anchoring to canon owners.
|
||
4. *`adapt`* — chosen.
|
||
5. *Classify as a standard rather than a model.* Deferred as OQ-1; a capability
|
||
set is a broad domain structure, which is the definition of a model here.
|
||
|
||
**Rationale.** The source passes its own inclusion rules and the canon's:
|
||
implementation-independent, reusable, demandable, providable, testable,
|
||
profileable, stable. It conflicts with nothing the canon already owns. The two
|
||
genuinely new surfaces (`commerce.*`, `intelligence.*`) extend the canon into
|
||
areas no existing model reaches. Adapting rather than adopting preserves single
|
||
canonical ownership.
|
||
|
||
**Consequences.**
|
||
|
||
- Canon version `0.2.0`; the canon gains a twelfth model and 41 capability IDs
|
||
that are treated as durable interfaces from here on.
|
||
- The Landscape Model's deferred strategy/capability concepts
|
||
(`BusinessCapability`, `ProductCapability`) now have a destination; the
|
||
Landscape §11.4 note should be revised — deferred to ITC-WP-0014.
|
||
- Capability IDs must not be renamed without migration semantics, which makes
|
||
OQ-2 blocking for promotion.
|
||
- `commerce.*` and `intelligence.*` create canon surface with no anchoring model
|
||
(OQ-5), an accepted weakness at `proposed` status.
|
||
|
||
**Review trigger.** Promotion beyond `proposed` requires: OQ-2 resolved, the
|
||
contract schema published, and at least one profile expressing a real capability
|
||
requirement set with evidence.
|
||
|
||
**Supersession.** None. A later ITCC revision arrives as a new intake with a new
|
||
`source_version`, never as an edit to this frozen snapshot.
|