tegwick 28d5824362

CI Smoke / host-smoke (push) Successful in 0s

Details

CI Smoke / container-smoke (push) Successful in 1s

Details

Assimilate ITCC v0.1 as Capability Model; canon 0.2.0

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>

2026-08-14 20:54:32 +02:00

4.2 KiB

Raw Blame History

Source Summary — ITCC v0.1

Faithful précis of source/ITCapabilityCanonV0.1.md and source/capabilities.yaml. No canon judgement here; comparison lives in comparison-matrix.md.

Identity

Name: Information Technology Capability Canon
Short name: ITCC
Version: 0.1, status draft baseline
Companion data: capabilities.yaml — declared by the document (§17) as the initial machine-readable representation

Stated purpose

Define what an information system must be able to do, independently of how it is implemented, positioned deliberately between product and technology:

Business / Product → requires → Capability → provided by → Service
  → implemented by → Technology → consumes → Resources → Cost

The document states (§15) that ITCC is intended to become a capability-oriented component of the wider InfoTechCanon, governed by "import; do not duplicate".

Object model (§3)

Object	Meaning
Capability	Abstract, implementation-independent ability that may be required or provided
Profile	Constrained specialization of a capability, preferred over new capabilities
Requirement	A system's statement that it needs a capability at a minimum maturity
Provider	Operational entity providing a capability in a context
Implementation	Concrete technology/product/configuration used by a provider
Resource	Economic resource consumed while providing: C, S, N, I, P
Evidence	Information supporting a capability or maturity claim
Maturity	Quality/operational standing of a provision, never of the abstract capability

Inclusion rules (§4)

A concept enters the canon only if it is implementation-independent, reusable, demandable, providable, testable, profileable, and stable.

Exclusions (§5)

Technologies (PostgreSQL, Keycloak, Stripe), protocols and standards (REST, OIDC, OpenTelemetry), product features (password reset screen), and domain-specific business capabilities (hospital admission, insurance underwriting).

Structure (§6, §7)

Eight navigation domains over 41 capabilities; the underlying model is asserted to be a graph, not a tree:

Domain	Capabilities
Identity & Access	lifecycle, authentication, authorization, federation, organization
Data & State	transactional, object, cache, backup, archive, search
Integration & Communication	api, messaging, exchange, notification, traffic
Runtime & Automation	execution, configuration, scheduling, workflow, deployment
Operations & Assurance	observability, alerting, audit, recovery, continuity
Security & Governance	secrets, keys, policy, vulnerability, governance.evidence, governance.lifecycle
Commerce	metering, billing, payment, entitlement
Intelligence	generation, extraction, embedding, retrieval, reasoning

Each capability carries id, name, purpose, profiles, qualities, evidence, and optional depends_on / may_use.

Relationship types (§9)

depends_on, may_use, composes (capability-to-capability); requires, provides, implements, consumes (landscape-to-capability).

Maturity scale (§10, §11)

D0 Absent · D1 Experimental · D2 Available · D3 Usable · D4 Production · D5 Reliable · D6 Scalable · D7 Strategic. Claims are per provision and per environment; the same provider may hold different levels in dev/staging/prod.

Resource and cost model (§13)

C Compute · S Storage · N Networking · I Intelligence · P Platform. Cost attaches to provisions and implementations, not to abstract capabilities, enabling capability-oriented FinOps questions.

Evolution stance (§16, §19)

Conservative: prefer profiles over new capabilities, treat capability IDs as durable interfaces, require explicit migration semantics for rename/removal, introduce provisionally and promote only after repeated practical use. v0.1 explicitly does not aim at completeness.

Proposed ownership split (§15)

ITCC owns what abstract abilities exist; a "CILM" landscape model owns what entities exist and what state they are in; CARING keeps specialized access-governance semantics and may import ITCC concepts.

4.2 KiB Raw Blame History