Execution Engine — Escepine Docs

The Core Execution Engine does two things: a dispatch loop that decides which steps run when, and a per-step pipeline that governs how each step runs. The pipeline is uniform across action types — HUMAN, REASONING, EXECUTION, SUB_SOP all pass the same gates; they diverge only at the executor.

The dispatch loop

Resolve the dependency graph against completed steps.
Dispatch every step whose dependencies are satisfied — parallel siblings fan out concurrently.
Run the per-step pipeline for each dispatched step.
Merge artifacts at join points; hydration pulls them into downstream context.
Persist a checkpoint at the safe boundary.
Repeat until a terminal state: complete, compensated, or parked.

The loop is data-driven: a step dispatches when its dependencies complete, never on a timer.

The per-step pipeline

hydration ........ assemble step context: artifacts + state + prior outputs
  │
strategist ....... route this entry: plan · verifier back-edge · human intake
  │
gatekeeping ...... human-participation tier for this attempt
  │
planner .......... structured output proposal against the step contract
  │
policy ........... Policy Gateway: ALLOW proceeds · DENY parks
  │
schema ........... tool-input validation — deviation fails, no call is made
  │
executor ......... REASONING model call · MCP sandbox · SUB_SOP dispatch
  │
verifier ......... output against criteria — pass commits · fail critiques
  │                   └─ critique ─▶ back to planner, bounded iterations
  │
commit ........... artifact sealed · events recorded
  │
compensation ..... on terminal failure: reverse-order rollback

Phase reference

Phase	Input	Output	On failure
Hydration	Step declaration, workflow state, artifact refs	Assembled step context	Missing context halts the step — nothing plans on absent inputs
Strategist	Assembled context	Route: plan, verifier back-edge, or human intake	—
Gatekeeping	Route, step state	Human-participation tier, or none	—
Planner	Context, step contract	Structured output proposal	Failed verdicts loop via critique, bounded per attempt
Policy	Proposed tool call	ALLOW, DENY	DENY parks; an unavailable gateway fails closed
Schema	Tool input	Validated payload	Deviation is failure — no call is made
Executor	Validated payload	Action output, or child artifacts	Tool or sandbox failure retries within budget, then compensation
Verifier	Output, criteria, input context	Pass, or fail with critique	Critique routes back to planner, bounded
Compensation	Terminal failure, completed steps	Reverse-order rollback, checkpoint reset	Recorded in the ledger; workflow parks

The verifier back-edge

A failed verdict is not a terminal failure. The critique routes back to the planner, which re-plans with the critique in context — the same loop a human reviewer creates by sending work back with comments. The loop is bounded by the budget hierarchy: iterations exhausted, escalation ladder, park. There is no unbounded cycle anywhere in the pipeline.

The verifier sees the step's actual input context, not just its output — verdicts are rendered against real inputs. The zero-case rule depends on this: under honest scarcity, the verifier can confirm the inputs truly contained nothing to select.

Checkpoints and resume

Mechanism	Semantics
Checkpoint	Persisted at each safe boundary: completed steps, artifact refs, budget consumption
Resume-from	Restart with the completed prefix seeded; the failed step re-enters the pipeline at hydration
Hard cap	The global timeout terminates the run; unconsumed HITL responses are stripped at termination

Budgets bind the workflow, not the incarnation: a checkpoint restart does not reset what the run has consumed. The full budget and recovery semantics are specified in retry and recovery.