This is the one document in the reference that names the engine's runtime components. The placement is deliberate: the platform's contract — what you author, what executes, what the Evidence Ledger records — is specified at the phase level in the execution engine, and none of it references the libraries beneath. Composition is an implementation detail, disclosed here once, in full.
Hybrid runtime composition
| Component | Provides | Does not provide |
|---|---|---|
| Durable execution primitives — Temporal | Workflow state persistence, failure recovery, durable timers, checkpoint discipline | Any governance: no policy gate, no verification, no compensation semantics, no evidence chain |
| State-graph patterns — LangGraph | Branching, conditional routing, multi-agent coordination structure | Deterministic governance: no budgets, no circuit breaker, no ledger |
| Custom execution runtime — Escepine | The entire per-step pipeline: hydration through verifier, Policy Gateway evaluation, both schema gates, Saga compensations, budget hierarchy, circuit breaker, Evidence Ledger integration, HITL gates | — |
The composition exists for one reason: deterministic execution with the flexibility of agentic reasoning. The hybrid approach lets Escepine combine the reliability of durable execution with the flexibility of state-graph orchestration, while adding the governance layer the components lack. Strip the components and the guarantees must be rebuilt; strip the governance runtime and there is no product.
What the custom runtime owns
Every guarantee documented in this reference is enforced by the custom runtime, not inherited from a component's default behavior:
| Guarantee | Owner |
|---|---|
| Cedar evaluation before every tool call | Policy Gateway — custom |
| Tool-input and output schema gates | Custom |
| Saga compensations, reverse order | Custom |
| Budget hierarchy binding the workflow, not the incarnation | Custom |
| Circuit breaker against deterministic-failure storms | Custom |
| Checksum-chained, append-only Evidence Ledger | Custom |
| HITL one-shot consumption and fresh-iteration resume | Custom |
This ownership table is the answer to the only question this file exists to settle: the components carry execution mechanics; the plane's value is entirely in the governance runtime wrapped around them.
Substitutability
The integration contract is implementation-agnostic by construction:
| Contract surface | Defined in | References the runtime? |
|---|---|---|
| SOP JSON | SOP reference | No |
| Cedar policies | Policy Gateway | No |
| MCP tool definitions | Integration requirements | No |
| HITL signal semantics | HITL gates | No |
| Event and artifact formats | Ledger formats | No |
Swapping a component for an equivalent — another durable-execution engine, another graph runtime — changes no contract, no event, no guarantee. The pipeline is specified at the phase level, not the library level, and the phases are what the guarantees attach to. A wrapper's contract is the wrapped system's API; this plane's contract is its own, which is the structural difference between the two categories.
NOTE — Runtime component names appear in this document and nowhere else in the reference. The architecture, the schema, the reliability model, the governance model, and the operating model are documented without them, because none of those contracts depend on them.