# Information Technology Capability Canon v0.1 **Status:** Draft baseline **Short name:** ITCC **Version:** 0.1 **Purpose:** Establish a compact, implementation-independent vocabulary for commonly required information-technology capabilities and make those capabilities usable as stable building blocks for architecture, platform engineering, product design, FinOps, governance, and automated reasoning. --- ## 1. Intent The Information Technology Capability Canon (ITCC) defines **what an information system must be able to do**, independently of how that ability is implemented. The canon is deliberately positioned between products and technology: ```text Business / Product │ │ requires ▼ Canonical Capabilities │ │ provided by ▼ Services │ │ implemented by ▼ Technologies │ │ consume ▼ Resources │ ▼ Cost ``` ITCC is intended to provide a practical baseline that can later be reconciled with and incorporated into the wider **InfoTechCanon**. The core design objective is a vocabulary that is: - small enough to understand; - stable enough to survive technology changes; - abstract enough to support heterogeneous implementations; - precise enough to support contracts and validation; - machine-readable enough for automated analysis; - useful enough for day-to-day architecture and operations. --- ## 2. Core Principle A **capability** is an abstract, implementation-independent ability that an information system, service, platform, or product may require or provide. Examples: - Authentication - Backup & Restore - Payment - Workflow Orchestration - Observability - Reasoning & Decision Technologies are **not** canonical capabilities. For example: ```text Authentication capability Keycloak implementation Backup & Restore capability pgBackRest implementation Payment capability Stripe provider / implementation Object Persistence capability S3 implementation / service interface ``` The canon therefore aims to remain stable even when technologies, vendors, protocols, and architectures change. --- ## 3. Canonical Objects ITCC distinguishes the following concepts. ### 3.1 Capability An abstract ability. Example: ```text identity.authentication ``` ### 3.2 Profile A specialization or constrained form of a capability. Examples: ```text Authentication ├── human ├── machine ├── federated ├── passwordless ├── mfa └── high-assurance ``` Profiles should be preferred over creating new canonical capabilities when the underlying ability remains the same. ### 3.3 Requirement A statement that a system needs a capability at a minimum acceptable maturity or quality. Example: ```yaml requires: identity.authentication: D5 data.backup: D5 operations.observability: D4 ``` ### 3.4 Provider An operational entity that provides a capability in a particular context. Example: ```yaml provider: auth.prod.eu provides: capability: identity.authentication maturity: D5 ``` ### 3.5 Implementation A concrete technology, product, configuration, or composition used by a provider. Examples: - Keycloak - PostgreSQL - Kubernetes - Stripe - OpenTelemetry - an internal service ### 3.6 Resource An economic resource consumed while providing a capability. The initial resource model uses: | ID | Resource | Meaning | |---|---|---| | `C` | Compute | Generic execution capacity | | `S` | Storage | Persistence capacity | | `N` | Networking | Information movement | | `I` | Intelligence | Metered or purchased cognitive / semantic processing | | `P` | Platform | Enabling operational overhead | ### 3.7 Evidence Information supporting the claim that a capability exists or has a particular maturity. Examples: - successful tests; - measured availability; - restore tests; - policy evaluations; - telemetry; - configuration evidence; - audit records. ### 3.8 Maturity A statement about the quality and operational standing of a capability **as provided in a specific context**. Maturity attaches to a provision relationship, not to the abstract capability itself. Correct: ```yaml provider: auth.prod.eu capability: identity.authentication maturity: D5 ``` Incorrect: ```yaml capability: identity.authentication maturity: D5 ``` The latter incorrectly implies that Authentication is intrinsically D5 everywhere. --- ## 4. Canon Inclusion Rules A concept should normally enter the canonical capability set only if it satisfies the following tests. ### 4.1 Implementation-independent The capability survives replacement of the underlying technology. > Keycloak may disappear; Authentication remains. ### 4.2 Reusable The capability occurs across materially different products or systems. ### 4.3 Demandable A system can meaningfully state that it requires the capability. ### 4.4 Providable Another system, service, or platform component can meaningfully state that it provides the capability. ### 4.5 Testable Evidence can be gathered that the capability exists and is functioning. ### 4.6 Profileable Important specializations can be expressed as profiles without redefining the underlying capability. ### 4.7 Stable The concept is likely to outlive individual products, protocols, or vendors. --- ## 5. What Does Not Belong in the Canon The canon intentionally excludes several nearby categories. ### Technologies Examples: - PostgreSQL - Kubernetes - Keycloak - OpenBao - Stripe - Grafana ### Protocols and Standards Examples: - REST - OAuth - OpenID Connect - SAML - OpenTelemetry These may be referenced by capability profiles or implementations. ### Product Features Examples: - password reset screen; - invoice export; - document upload button. ### Domain-Specific Business Capabilities Examples: - hospital admission; - insurance underwriting; - warehouse picking; - vacation booking. Such capabilities may depend on ITCC capabilities but are outside this canon. --- ## 6. Canon Structure ITCC v0.1 organizes capabilities into eight navigation domains: 1. Identity & Access 2. Data & State 3. Integration & Communication 4. Runtime & Automation 5. Operations & Assurance 6. Security & Governance 7. Commerce 8. Intelligence Domains are primarily a navigation aid. The underlying model should be treated as a **graph**, because capabilities may depend on or compose other capabilities across domain boundaries. --- # 7. Canonical Capability Baseline ## 7.1 Identity & Access ### `identity.lifecycle` — Identity Lifecycle Create, maintain, suspend, recover, and remove identities over time. Typical profiles: - human; - machine; - external; - privileged. ### `identity.authentication` — Authentication Establish that an actor controls or legitimately represents an identity. Typical profiles: - human; - machine; - password; - passkey; - MFA; - passwordless; - high-assurance. ### `identity.authorization` — Authorization Determine whether an authenticated or otherwise identified actor may perform an action on a resource. Typical profiles: - RBAC; - ABAC; - relationship-based; - policy-based. ### `identity.federation` — Identity Federation Establish and use trust relationships between identity domains. Typical profiles: - workforce; - customer; - partner; - machine federation. ### `identity.organization` — Organization & Tenancy Associate identities, resources, policies, and operations with organizational or tenant boundaries. Typical profiles: - organization; - team; - tenant; - hierarchy; - delegation. --- ## 7.2 Data & State ### `data.transactional` — Transactional Persistence Persist structured mutable state with defined consistency and transaction semantics. ### `data.object` — Object Persistence Persist opaque objects, files, blobs, documents, or similar binary or semi-structured objects. ### `data.cache` — Caching Maintain temporary or derived state for accelerated access. ### `data.backup` — Backup & Restore Create recoverable copies or recovery points and restore previously valid persisted state after loss, corruption, or erroneous modification. Important qualities include: - recovery point objective (RPO); - recovery time objective (RTO); - retention; - isolation; - geographical separation; - restoration validation. ### `data.archive` — Archive & Retention Preserve information for long-term retention under defined lifecycle, integrity, and retrieval rules. ### `data.search` — Search & Retrieval Locate persisted information based on indexed or queryable characteristics. Profiles may include: - lexical; - structured; - faceted; - semantic; - hybrid. --- ## 7.3 Integration & Communication ### `integration.api` — API Exposure Expose machine-consumable interfaces through which systems can invoke or retrieve functionality. ### `integration.messaging` — Messaging & Eventing Exchange asynchronous messages or events between producers and consumers. Profiles may include: - queue; - pub/sub; - event stream; - event bus. ### `integration.exchange` — Data Exchange Move datasets, files, or structured information between systems. ### `integration.notification` — Notification Deliver information to human users or external endpoints. Profiles may include: - email; - SMS; - push; - chat; - webhook; - physical mail. ### `integration.traffic` — Traffic Management Route, balance, control, filter, or shape communication between endpoints. Profiles may include: - load balancing; - ingress; - service routing; - rate limiting; - API gateway. --- ## 7.4 Runtime & Automation ### `runtime.execution` — Workload Execution Execute software workloads with defined runtime resources and isolation. ### `runtime.configuration` — Configuration Supply controlled runtime configuration to software and services. ### `runtime.scheduling` — Scheduling Initiate activities according to time, delay, calendar, or recurrence. ### `runtime.workflow` — Workflow Orchestration Coordinate multi-step activities, state transitions, dependencies, retries, and completion. ### `runtime.deployment` — Deployment & Release Bring defined software versions and configurations into operational environments in a controlled manner. --- ## 7.5 Operations & Assurance ### `operations.observability` — Observability Establish operational state and behavior from telemetry such as logs, metrics, traces, events, and derived signals. ### `operations.alerting` — Alerting Detect relevant conditions and surface them to humans or automation. ### `operations.audit` — Audit Produce attributable historical evidence about relevant actions, changes, and decisions. ### `operations.recovery` — Service Recovery Restore an operational service after failure or degradation. ### `operations.continuity` — Continuity Maintain acceptable service operation despite disruption. These are intentionally distinguished: ```text Backup & Restore recovery of persisted state Service Recovery recovery of an operational service Continuity maintaining acceptable operation through disruption ``` --- ## 7.6 Security & Governance ### `security.secrets` — Secret Management Protect, distribute, rotate, and revoke confidential credentials and secrets. ### `security.keys` — Key & Certificate Management Create, protect, distribute, rotate, validate, and revoke cryptographic keys and certificates. ### `security.policy` — Policy Management & Enforcement Define, distribute, evaluate, and enforce machine-interpretable policies. ### `security.vulnerability` — Vulnerability Management Identify, assess, prioritize, remediate, mitigate, and track exploitable weaknesses. ### `governance.evidence` — Compliance Evidence Produce and maintain evidence supporting governance, assurance, certification, or compliance assertions. ### `governance.lifecycle` — Information Lifecycle Governance Apply rules governing information retention, handling, deletion, preservation, and lifecycle transitions. --- ## 7.7 Commerce ### `commerce.metering` — Metering Measure usage or activity that is commercially or contractually relevant. ### `commerce.billing` — Billing Calculate amounts owed based on contracts, pricing rules, entitlements, metering, or events. ### `commerce.payment` — Payment Transfer monetary value between parties. Typical profiles: - card; - SEPA; - bank transfer; - wallet; - payout; - recurring. ### `commerce.entitlement` — Entitlement Determine which products, features, capacities, or service levels a customer or actor is contractually allowed to use. A subscription is normally a composition rather than a primitive capability: ```text Subscription ├── Metering ├── Billing ├── Payment └── Entitlement ``` --- ## 7.8 Intelligence ### `intelligence.generation` — Generation Produce novel information representations from context or instructions. Profiles may include: - text; - image; - audio; - video; - code; - structured data. ### `intelligence.extraction` — Extraction & Classification Derive structured information, labels, attributes, or classifications from input. Profiles may include: - OCR; - document extraction; - entity extraction; - classification; - speech recognition. ### `intelligence.embedding` — Semantic Representation Produce machine-usable semantic representations of information. ### `intelligence.retrieval` — Semantic Retrieval & Ranking Select or rank information according to semantic relevance. ### `intelligence.reasoning` — Reasoning & Decision Derive judgments, plans, decisions, hypotheses, or action proposals from context and constraints. --- # 8. Capability Profiles Profiles specialize a canonical capability without changing its identity. A profile may constrain: - supported interaction type; - subject; - protocol; - assurance level; - delivery channel; - consistency; - durability; - performance; - regulatory context; - geography; - tenancy; - security posture. Example: ```yaml capability: identity.authentication profile: subject: human assurance: high factors: minimum: 2 federation: oidc: true ``` Profiles should remain composable and should avoid encoding particular products or vendors unless the profile explicitly represents an implementation standard. --- # 9. Capability Relationships The canon should support at least the following relationship types. ## `depends_on` The capability normally requires another capability to operate. ```text data.backup DEPENDS_ON data.object ``` ## `may_use` The capability may use another capability but is not conceptually dependent on it. ```text runtime.workflow MAY_USE integration.messaging ``` ## `composes` A higher-level capability or pattern is constructed from multiple lower-level capabilities. ```text Subscription COMPOSES Metering + Billing + Payment + Entitlement ``` ## `requires` A product, workload, service, or other landscape entity requires a capability. ## `provides` A service or provider supplies a capability. ## `implements` A technology or implementation realizes all or part of a provider. ## `consumes` A provider or implementation consumes economic resources. --- # 10. Maturity Model ITCC v0.1 uses the following maturity scale. | Level | State | Meaning | |---|---|---| | **D0** | Absent | Capability is not provided | | **D1** | Experimental | Proof of concept or exploratory implementation | | **D2** | Available | A provider exists and can be consumed | | **D3** | Usable | Documented and practically consumable | | **D4** | Production | Approved for production dependency | | **D5** | Reliable | Reliability is measured and actively controlled | | **D6** | Scalable | Capacity and operational scaling are demonstrated | | **D7** | Strategic | Governed, reusable, and deliberately evolved as a platform capability | A maturity claim should be contextual. Example: ```yaml provider: auth.prod.eu capability: identity.authentication maturity: D5 environment: production ``` A single provider may expose different maturity in different contexts: ```yaml provider: auth provisions: - environment: development capability: identity.authentication maturity: D3 - environment: staging capability: identity.authentication maturity: D4 - environment: production capability: identity.authentication maturity: D6 ``` --- # 11. Evidence and Maturity Maturity should increasingly require evidence. Suggested interpretation: ### D0 — Absent No provider exists. ### D1 — Experimental Evidence may consist of: - prototype; - experiment; - demonstration; - initial configuration. ### D2 — Available Evidence should show: - discoverable provider; - successful invocation; - basic ownership. ### D3 — Usable Evidence should include: - documented usage; - defined interface; - known limitations; - repeatable consumption. ### D4 — Production Evidence should additionally include: - production approval; - operational ownership; - security baseline; - backup/recovery posture where applicable; - production change process. ### D5 — Reliable Evidence should additionally include: - operational objectives; - measurement; - monitoring; - incident handling; - demonstrated recovery. ### D6 — Scalable Evidence should additionally include: - capacity model; - load or scale validation; - scaling mechanisms; - demonstrated operation beyond current baseline demand. ### D7 — Strategic Evidence should additionally include: - explicit governance; - reuse across multiple consumers; - lifecycle ownership; - roadmap; - compatibility/evolution policy; - cost and performance understanding. These criteria may later be specialized by capability. --- # 12. Capability Contract Each canonical capability should ultimately have a minimal machine-readable contract. Example: ```yaml id: data.backup name: Backup & Restore domain: data purpose: > Recover previously valid persisted state after loss, corruption, or erroneous modification. profiles: - database - object - volume qualities: - rpo - rto - retention - isolation - geographical_separation - restore_validation depends_on: - data.object evidence: - successful_backup - successful_restore_test - measured_rpo - measured_rto ``` The initial canon intentionally standardizes identity, semantics, relationships, and evidence hooks before attempting to standardize every feature or quality dimension. --- # 13. Resource and Cost Model ITCC separates capabilities from economic resources. The resource model is: ```text C — Compute S — Storage N — Networking I — Intelligence P — Platform ``` A capability provision may consume any combination of these resources. Conceptually: \[ Cost(capability\ provision) = C + S + N + I + P \] Examples: ```text Authentication → Compute → Storage → Networking → Platform Backup & Restore → Compute → Storage → Networking → Platform Generation via external model API → Networking → Intelligence → Platform ``` Resource consumption should attach to actual providers or implementations rather than to the abstract capability definition. This supports capability-oriented FinOps questions such as: - What does Authentication cost? - What is the marginal cost of Backup & Restore? - Which capabilities dominate Intelligence spend? - What is the cost of a capability per tenant, customer, transaction, or workload? --- # 14. Canon Graph Domains provide navigation, but the actual canon is a graph. Example: ```text Payment DEPENDS_ON → Authentication MAY_USE → Audit MAY_USE → API Exposure Backup & Restore DEPENDS_ON → Object Persistence MAY_USE → Scheduling MAY_USE → Observability Workflow Orchestration MAY_USE → Messaging & Eventing MAY_USE → Scheduling MAY_USE → Notification ``` The graph enables traversal from product need to technology and cost: ```text Product → REQUIRES Capability ← PROVIDED_BY Service → IMPLEMENTED_BY Technology → CONSUMES C/S/N/I/P ``` --- # 15. Relationship to InfoTechCanon ITCC is intended to become a capability-oriented component of the wider InfoTechCanon. A proposed conceptual ownership model is: ```text InfoTechCanon │ ├── Capability Canon / ITCC │ owns: │ What abstract IT abilities exist? │ ├── CILM — Canonical IT Landscape Model │ owns: │ What entities exist in an IT landscape? │ How are entities related? │ What state is intended, declared, applied, │ observed, historical, or assessed? │ ├── CARING │ owns: │ Specialized access-governance semantics │ and assessment │ ├── Standards ├── Profiles ├── Patterns ├── Mappings └── Validation ``` The governing principle should be: > **Import; do not duplicate.** For example, ITCC owns the meaning of: - Identity Lifecycle; - Authentication; - Authorization; - Policy; - Audit; - Compliance Evidence. CARING may import those concepts and add richer access-governance semantics. CILM may express relationships such as: ```text Workload REQUIRES Capability Service PROVIDES Capability Technology IMPLEMENTS Service ``` CILM's state model can later distinguish: - intended maturity; - declared maturity; - applied maturity; - observed maturity; - assessed maturity. That allows a provider to claim D5 while an assessment concludes D4, without corrupting the underlying capability model. --- # 16. Canon Evolution The canon should evolve conservatively. A proposed change process: 1. **Identify a repeated architectural need.** 2. **Test whether an existing capability plus profile already represents it.** 3. **Apply the canon inclusion rules.** 4. **Check for overlap with existing capabilities.** 5. **Define purpose and boundary.** 6. **Add initial profiles and relationships.** 7. **Add evidence hooks.** 8. **Introduce the capability provisionally.** 9. **Promote only after repeated practical use.** Canonical capability IDs should be treated as durable interfaces. Renaming or removing an ID should require explicit migration semantics. --- # 17. Initial Machine-Readable Source The companion file: ```text capabilities.yaml ``` is the initial machine-readable representation of this canon. It contains: - version metadata; - domains; - capability identifiers; - names and purposes; - initial profiles; - initial quality dimensions; - evidence hooks; - dependency relationships; - maturity definitions; - resource definitions. The Markdown document provides normative human-readable context; the YAML file provides a basis for tooling, validation, graph construction, and agentic reasoning. --- # 18. Example: Product Requirement and Provision A product may declare: ```yaml product: lifedesk requires: - capability: identity.authentication minimum_maturity: D5 - capability: data.backup minimum_maturity: D5 - capability: operations.observability minimum_maturity: D4 - capability: commerce.payment minimum_maturity: D4 - capability: intelligence.reasoning minimum_maturity: D2 ``` Providers may declare: ```yaml providers: - id: auth.prod.eu provides: - capability: identity.authentication maturity: D6 - id: backup.prod.eu provides: - capability: data.backup maturity: D5 ``` A validator can then determine whether the environment satisfies the product requirements. This is the intended direction: architecture as a **typed dependency and evidence system**, not merely a collection of technology diagrams. --- # 19. v0.1 Design Position ITCC v0.1 intentionally favors: - abstract ability over technology; - a small canon over exhaustive taxonomy; - profiles over proliferation of capabilities; - graph relationships over rigid hierarchy; - maturity of provision over maturity of concepts; - evidence over assertion; - stable identifiers over fashionable terminology; - machine-readability from the beginning. The baseline is expected to change through practical use. The goal of v0.1 is not completeness. The goal is to establish a coherent kernel strong enough to be used, tested, challenged, and reconciled with the wider InfoTechCanon.