Verification Blocks — Escepine Docs

Verification is the post-completion, pre-commit check of a step's output. Nothing a step produces becomes workflow state until verification passes — the gate sits between the executor and the Evidence Ledger's commit of the result.

The block

Field	Type	Required	Semantics
`prompt`	string	yes	Instruction to the verifier: what to check and how to render the verdict.
`criteria`	array	yes	Conditions a passing output must satisfy, checked against the step's actual output.

Evaluation contract

Property	Semantics
Timing	After step completion, before commit.
Scope	The verifier sees the step's actual input context and its output — verdicts are rendered against real inputs, not blind.
Verdict	Pass, or fail with a critique.
Evidence Ledger	Every verdict is recorded with its critique.
Back-edge	A failed verdict's critique routes back to the planner within iteration bounds.

The back-edge

planner ──▶ verifier ──pass──▶ commit
   ▲            │
   └─ critique ─┘ fail
   (bounded: iterations per attempt)

The loop is bounded per attempt by the budget hierarchy. Iterations exhausted → escalation ladder → park. There is no unbounded retry anywhere in the loop; the shape is fixed.

The zero-case rule

Verification criteria must be satisfiable by every valid outcome of the step, including an empty one. When a step's input contains zero items meeting its selection criteria — honest scarcity — the correct output is the self-attesting empty result, and verification must treat that result as success.

{ "selected_count": 0, "hypotheses": [] }

Excerpt — hypothesis-selection output shape under zero selection, competitor_deep_dive DD10.

The engine does not invent data. Criteria that cannot pass on an empty result make the step unfinishable — a retry cannot create data that does not exist — which makes it an authoring defect, not a runtime condition.

Authoring rules

Rule	Rationale
Criteria satisfiable by every valid outcome, including empty	Otherwise the step cannot complete under honest scarcity
Prompt states the zero-case exemption explicitly	The verifier must treat the self-attesting empty result as success
Criteria reference only data in verifier scope	The verifier sees step input and output; it cannot verify claims about artifacts it cannot see
Criteria check the output, not the effort	Verification judges the committed result, never the reasoning that produced it