Technical Report 3: Governed Capability Model

1. Purpose

TR‑003 defines the constitutional rules governing how knowledge becomes capability. It establishes identity, specification, contract formation, manifest generation, lifecycle, dependency, registry, resolution, and architectural invariants.

Out of Scope

• Domain logic or capability implementations
• Scheduling or orchestration algorithms
• Retry or routing strategies
• Multi-runtime execution tactics
• Implementation details of Resolver or Registry

2. Constitutional Principles

1. Capability ≠ Knowledge — Knowledge answers questions; capability performs actions.
2. Capability is a Governed Contract — No logic inside. Only identity, version, constraints, and governance requirements.
3. PU → Capability → Runtime Pipeline — Clean separation between knowledge, capability, and execution.
4. Immutability — Once approved, capability contracts cannot be modified.
5. Traceability — Every execution must trace back to governed knowledge.
6. Governance Precedes Execution — Runtime may execute only approved manifests.
7. Eligibility is Mandatory — No capability may execute without eligibility evaluation.
8. Deprecation is Irreversible — Deprecated capabilities cannot be reactivated.

3. Capability Identity Model

Every capability has a stable identity:

• capability_id — Unique, immutable identifier
• canonical_name — Official name for governance records
• semantic_name — Human-readable name for documentation
• namespace — Grouping for organizational structure
• owner — Governance accountability
• authority_scope — What authority delegates to this capability
• classification — Governance tier or domain
• version — Immutable versioning from approval

Identity is immutable once approved.

4. Capability Specification (Design-time)

The Specification defines the intended behavior of a capability.

Includes:

• Identity (as defined in Section 3)
• Purpose statement
• Required Process Units (PU)
• Required knowledge (from TR‑002)
• Expected inputs and outputs
• Dependency graph (Directed Acyclic Graph)
• Constraints and limitations
• Domain semantics

Execution: Specification is not executable.

5. Capability Contract (Governance-time)

The Contract is the governed form of the Specification. It is the constitutional commitment that binds approval to execution.

Includes:

• Stable identity
• Semantic version
• Required policies (governance gates)
• Required permissions (authority delegation)
• Required runtime (from TR‑001)
• Autonomy level (how much discretion is permitted)
• Risk classification (governance tier)
• Governance approval status
• Provenance anchors (links to knowledge)
• Immutability enforcement rules

Execution: Contract is immutable once approved.

6. Capability Manifest (Runtime-facing)

The Manifest is the only artefact the runtime may execute. It is derived entirely from the approved Contract and contains only constitutional governance information necessary for runtime execution.

Includes (Constitutional Only):

• capability_id — Identity from Contract
• version — Semantic version from Contract
• required_runtime — Runtime profile (from TR‑001)
• required_inputs_spec — Reference to input specification
• expected_outputs_spec — Reference to output specification
• dependency_list — Other capabilities required
• required_policies — List of governance policies to enforce
• constraints — Constitutional boundaries and authority limits
• evidence_hash — Cryptographic digest of the approved Contract
• eligibility_requirements — Reference to eligibility criteria

7. Capability Lifecycle

Capabilities follow a strict, irreversible lifecycle:

1. Creation — Specification is drafted and documented
2. Validation — Specification is reviewed for constitutional compliance
3. Governance Approval — Contract is approved by authority
4. Activation — Manifest is registered and runtime-ready
5. Deprecation — Capability transitions to inactive state

Deprecation Modes (Constitutional):

• Manual — Human-initiated, requires governance approval
• Automatic — Triggered by constitutional events
• Timeout — Activation window expires automatically
• Rollback — Governance-directed reversal due to execution failure

8. Capability Registry

The Registry is the immutable, append-only store of all capability versions, manifests, dependencies, deprecations, and provenance entries.

Stores:

• Capability versions and their state
• Approved Manifests
• Dependency relationships
• Deprecation records
• Provenance entries (audit trail)

Constitutional Responsibilities:

• Index capabilities by identity, name, and namespace
• Maintain aliasing (canonical to semantic name mappings)
• Track compatibility across versions
• Record supersession relationships

Registry Invariant: Registry is append-only and immutable.

9. Capability Resolver

The Resolver is responsible for determining capability versions and dependencies at execution time.

Constitutional Responsibilities:

• Determine which capability version satisfies the request
• Resolve PU version requirements
• Verify runtime compatibility
• Identify required policies
• Construct complete dependency chain

10. Architectural Invariants

11. Summary

TR‑003 v1.2 establishes the Governed Capability Model — the architectural layer where knowledge becomes executable capability under constitutional governance:

Core Model:

• Capabilities are governed contracts — Not logic, not prompts, not tools
• Derived from Process Units — Governance flows from knowledge
• Three immutable layers — Specification → Contract → Manifest
• Manifest is sole runtime artefact

Constitutional Rules:

• Immutability once approved
• DAG dependency model
• Runtime feedback loop
• Mandatory eligibility evaluation
• Irreversible deprecation

Foundation for Next Phases:

• TR‑004 — Eligibility Constitution
• TR‑005 — Provenance Ledger
• TR3+ — Domain-specific capability implementations