Run lifecycle

A workflow run is asynchronous and immutable once terminal. Its states:

• queued — Vault persisted the run and scheduled work against the bound source snapshots.
• running — workers are executing the stages: ingest, map, check, investigate, assemble.
• waiting_for_input — a required source is missing or stale; the run holds rather than guessing. Affected checks resolve to CANNOT_VERIFY if the input never arrives.
• waiting_for_review — a human decision is required before the run can proceed.
• completed — the workflow finished. Completion is not a verdict: the run's receipts individually record PASS, FAIL, or CANNOT_VERIFY per rule.
• failed — infrastructure, validation, or persistence failed. Retry with POST /v1/runs/{run_id}/retry, which creates a new child run and leaves the original untouched.

Each stage event carries a status (pending, running, waiting, completed, failed, skipped), an actor kind (agent, deterministic_engine, or human), and an attempt counter. Runs are triggered manually, on a schedule, on a data refresh, or as a retry.

Two properties hold across the lifecycle:

1. Model text never changes a deterministic result. Investigation and drafting can add context to an exception; only a new run with corrected inputs produces new verdicts.
2. History is append-only. Retries and reviews create new records. Existing runs, events, and receipts are never edited in place.