do

Execution

What binds the run

Work toward the manifest's Deliverables in the order listed. Acceptance Criteria and Global Invariants are the binding layer — they are what the run owes, and gates are the only thing that can hold it open. Process Guidance is advisory: recommendations on how to work, weighed rather than enforced, and set aside when the work is better for it — name every departure on whichever terminal path the run takes — completion summary, escalation payload, or pending summary — and in the execution log too when a log is being kept, since advisory only stays safe while departing stays visible. The Initial Approach and the Deliverable order are likewise plan, not contract: pivot either when reality diverges, and name the deviation the same way a departure is named. Resequence when execution changes what the order was built on — a real dependency the order missed, or a shift in which Deliverable is now least proven, since proving the leading approach is exactly what ordering by uncertainty is for. Every judgment the run weighs rather than obeys — departing from Process Guidance, pivoting the Initial Approach, resequencing, choosing what stays below a bar on a terminal path — steers by the manifest's Intent: better than the Problem's baseline story, within the size the Appetite says the problem is worth, comparing down to that baseline rather than up to an ideal.

Running gate evaluations

Resolve execution policy before implementation starts. --verification accepts per-gate, consolidated, or self and defaults to per-gate; after resolving that default, load exactly one matching reference: references/per-gate-verification.md, references/consolidated-verification.md, or references/self-verification.md. The selected reference owns evaluator topology, evaluator provenance, and mode-specific evidence wording for completion and unattended backstops. --verifier-model <model> is optional and applies to the independent modes: when supplied, use it for every verifier execution and reject the policy before work if the active host cannot honor that selector; when omitted, verifier executions inherit the invoking context's model choice. The selected mode, the verifier-model provenance, and whether --exhaustive-verification is in force are fixed for the run and never change in response to cost, elapsed rounds, findings, or model preference. A later invocation changing any of them — including adding or dropping the flag — starts a new run with a fresh gate ledger rather than mixing evidence provenance. None of them is written into the Manifest.