info-tech-canon/infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md

# 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.