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>
99 lines
4.2 KiB
Markdown
99 lines
4.2 KiB
Markdown
# 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:
|
|
|
|
```text
|
|
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.
|