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>
107 lines
4.7 KiB
YAML
107 lines
4.7 KiB
YAML
assimilation: assimilation/it-capability-canon
|
|
source: ITCC v0.1
|
|
note: >
|
|
Concepts as the source names them, before canon comparison. Classification
|
|
against the canon lives in comparison-matrix.md; the canonical names chosen on
|
|
adoption are recorded in the canon_name field.
|
|
|
|
concepts:
|
|
- source_name: Capability
|
|
definition: Abstract, implementation-independent ability an information system may require or provide.
|
|
canon_name: Capability
|
|
category: missing_concept
|
|
|
|
- source_name: Capability Profile
|
|
definition: Constrained specialization of a capability that does not change its identity.
|
|
canon_name: CapabilityProfile
|
|
category: covered_differently
|
|
note: Distinct from a canon Profile (Core §8.6), which constrains canon artifacts for an implementation context.
|
|
|
|
- source_name: Capability Domain
|
|
definition: Navigation grouping of capabilities; not a semantic container.
|
|
canon_name: CapabilityDomain
|
|
category: missing_concept
|
|
|
|
- source_name: Requirement
|
|
definition: A statement that a system needs a capability at a minimum maturity.
|
|
canon_name: CapabilityRequirement
|
|
category: narrower_than_existing
|
|
note: A typed, maturity-bearing form of DemandSignal / ConsumerNeed from the Purpose and Demand extension.
|
|
|
|
- source_name: Provider
|
|
definition: Operational entity that provides a capability in a particular context.
|
|
canon_name: CapabilityProvider
|
|
category: covered_differently
|
|
note: Landscape owns ServiceProvider / Service / ServiceInstance; provider here is a role played by a landscape entity.
|
|
|
|
- source_name: Implementation
|
|
definition: Concrete technology, product, configuration, or composition used by a provider.
|
|
canon_name: (imported)
|
|
category: already_covered
|
|
note: Landscape owns Technology / SoftwareEntity / RuntimeEntity.
|
|
|
|
- source_name: Resource
|
|
definition: Economic resource consumed while providing a capability (C, S, N, I, P).
|
|
canon_name: CapabilityResourceClass
|
|
category: missing_concept
|
|
note: Landscape owns RuntimeResource as an entity; the C/S/N/I/P classification for cost attribution is new.
|
|
|
|
- source_name: Evidence
|
|
definition: Information supporting a capability or maturity claim.
|
|
canon_name: (imported)
|
|
category: already_covered
|
|
note: Governance owns Evidence; Observability owns telemetry evidence.
|
|
|
|
- source_name: Evidence Hook
|
|
definition: Named evidence type expected for a specific capability.
|
|
canon_name: CapabilityEvidenceHook
|
|
category: missing_concept
|
|
|
|
- source_name: Maturity
|
|
definition: Quality and operational standing of a capability as provided in a specific context.
|
|
canon_name: CapabilityMaturityLevel
|
|
category: missing_concept
|
|
|
|
- source_name: Provision
|
|
definition: The relationship binding provider, capability, context, and maturity.
|
|
canon_name: CapabilityProvision
|
|
category: missing_concept
|
|
note: Implicit in the source; made explicit on adoption because maturity attaches here and nowhere else.
|
|
|
|
- source_name: Quality Dimension
|
|
definition: Named quality attribute relevant to a capability (rpo, latency, assurance, ...).
|
|
canon_name: CapabilityQualityDimension
|
|
category: missing_concept
|
|
|
|
- source_name: Capability Contract
|
|
definition: Minimal machine-readable definition of a capability (id, purpose, profiles, qualities, relationships, evidence).
|
|
canon_name: CapabilityContract
|
|
category: missing_concept
|
|
|
|
- source_name: Canon Graph
|
|
definition: Capability relationships form a graph traversable from product need to technology and cost.
|
|
canon_name: (structural)
|
|
category: viewpoint_difference
|
|
note: Core §6.4 "Network Before Tree" already states this stance canon-wide.
|
|
|
|
- source_name: depends_on / may_use / composes
|
|
definition: Capability-to-capability relationship types.
|
|
canon_name: depends_on / may_use / composes
|
|
category: missing_concept
|
|
|
|
- source_name: requires / provides / implements / consumes
|
|
definition: Landscape-entity-to-capability relationship types.
|
|
canon_name: requires / provides / implements / consumes
|
|
category: missing_concept
|
|
|
|
- source_name: Canon inclusion rules
|
|
definition: Seven tests a concept must pass to enter the capability set.
|
|
canon_name: CapabilityInclusionRule
|
|
category: narrower_than_existing
|
|
note: Core §14 governs canon change generally; these are capability-specific admission tests.
|
|
|
|
- source_name: CILM (Canonical IT Landscape Model)
|
|
definition: Proposed sibling model owning landscape entities and intended/declared/applied/observed/assessed state.
|
|
canon_name: (rejected)
|
|
category: already_covered
|
|
note: InfoTechCanonLandscapeModel owns this. Only the state-qualifier idea is carried forward as an open question.
|