Skip to main content

5. Capability Model

This section defines how capabilities are identified, specified, governed, and evolved. The capability model is the foundation that enables high velocity while maintaining architectural integrity.

5.1 Capability Identification​

Capabilities are identified based on stable outcomes, not systems, processes, or organisational structures.

A valid capability:

  • Produces a meaningful outcome that can be requested independently
  • Is reusable across multiple user journeys or systems
  • Has a clear boundary and responsibility
  • Can be implemented and evolved independently

Capabilities should be:

  • Coarse enough to remain stable over time
  • Fine-grained enough to avoid becoming monolithic

Capabilities are named using verb–object conventions (e.g. Generate Document, Resolve Entity, Extract Metadata).

5.2 Capability Contracts​

A capability contract defines the formal agreement between consumers and executors.

Each contract includes:

  • Capability name and version
  • Purpose and outcome description
  • Input schema and validation rules
  • Output schema, including confidence and provenance
  • Execution modes supported (deterministic, AI-assisted)
  • Non-functional expectations (latency class, cost sensitivity)

Contracts are:

  • Explicit and versioned
  • Technology-agnostic
  • Enforced at invocation time

Contracts are the primary artefact of governance.

5.3 Capability Inputs and Outputs​

Capabilities accept structured inputs and return structured outputs.

Inputs:

  • Are explicit and self-describing
  • Must not rely on implicit state or hidden dependencies
  • Include execution context where required

Outputs:

  • Conform strictly to the declared schema
  • Include both result data and execution metadata
  • Must signal confidence and provenance when applicable

This structure ensures predictability, auditability, and composability.

5.4 Capability Lifecycle​

Capabilities follow a defined lifecycle:

  1. Proposed
    • Outcome identified
    • Initial contract drafted
  2. Implemented
    • One or more executors created
    • Contract enforced
  3. Published
    • Capability exposed via MCP
    • Discoverable and invocable
  4. Adopted
    • Used by one or more consumers
    • Monitored for usage and performance
  5. Deprecated
    • Superseded by a newer version
    • Consumers migrated deliberately

Lifecycle management ensures change without disruption.

5.5 Capability Ownership​

Each capability has a single accountable owner.

The owner is responsible for:

  • Contract definition and evolution
  • Quality, reliability, and correctness
  • Policy compliance and risk management
  • Coordination of implementations and versions

Ownership is:

  • Aligned to domain responsibility, not system ownership
  • Independent of the executor implementation
  • Required for publication and version changes

This prevents orphaned or inconsistent capabilities.

5.6 Capability Maturity Levels​

Capabilities progress through maturity levels:

  1. Manual
    • Human-executed or semi-automated
    • Minimal guarantees
  2. AI-Assisted
    • Uses AI to accelerate or augment execution
    • Variable confidence and latency
  3. Deterministic
    • Fully automated
    • Predictable behaviour and performance
  4. Optimised
    • Deterministic with performance, cost, and resilience optimised
    • Fully governed and monitored

Maturity levels allow incremental progress without blocking delivery.