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:

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:

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:

identity.authentication

3.2 Profile

A specialization or constrained form of a capability.

Examples:

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:

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:

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:

provider: auth.prod.eu
capability: identity.authentication
maturity: D5

Incorrect:

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:

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:

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:

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.

data.backup
    DEPENDS_ON data.object

may_use

The capability may use another capability but is not conceptually dependent on it.

runtime.workflow
    MAY_USE integration.messaging

composes

A higher-level capability or pattern is constructed from multiple lower-level capabilities.

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:

provider: auth.prod.eu
capability: identity.authentication
maturity: D5
environment: production

A single provider may expose different maturity in different contexts:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.