The Workflow Engine · 05.06
Completion Is Not Accomplishment
The SWIFT verdict engine probes the real world after a run settles instead of trusting a self-report, distinguishing accomplished from merely completed.
A topology fact vs. a world fact
A workflow run reaching its terminal node is a fact about the graph's topology — every node fired, nothing crashed. It says nothing about whether the thing the run was supposed to accomplish actually happened in the world. An agent claiming "deployed ✓" in its own output proves nothing on its own; a 200 response from the actual deployment URL does. The verdict engine's entire job is to only ever trust the second kind of evidence.
Four stages, cheapest first
| Stage | Checks | Cost |
|---|---|---|
| 1 · Sufficiency | Anti-hollow floors, typed-empty fills, stub detection | Free |
| 2 · Expression checks | Safe conditions evaluated over the terminal output | Free |
| 3 · World probes | An HTTP probe of a deployed URL, a datastore probe, a headless browser render | Cheap, evidence-bearing |
| 4 · Judge | An LLM judge over the gathered evidence — last resort, skippable | Routed, most expensive |
Every check that passes returns real, human-readable evidence — "GET https://… → 200 (4.1KB)", or "judge 8.5/10: …" — not just a boolean. A check that can't be evaluated in the current runtime (no browser available, no judge configured) is marked unavailable rather than silently counted as passed.
Four honest outcomes, not two
| Outcome | Means |
|---|---|
accomplished | Every declared check passed, and nothing was hollow. |
failed_checks | At least one check ran and genuinely failed. |
hollow | The checks themselves are fine (or none were declared), but the actual output is empty, a stub, or violates a sufficiency floor. |
partial | Nothing failed outright, but at least one check couldn't be verified in this runtime. |
hollow is the outcome most systems don't have a name for: a run that technically produced output but the output is empty, a placeholder, or clearly a stub — and it's caught by sufficiency floors before a single expensive probe or judge call ever runs.
Settlement is a persisted two-dimensional contract
Every terminal run persists a RunSettlement. executionStatus says whether execution was queued, running, waiting, completed, failed, or cancelled. Separately, outcomeStatus says whether the objective is unverified, accomplished, partial, failed, or blocked. The record pins the workflow revision and semantic hash and carries evidence references, deficiencies, and the settlement timestamp. A workflow published through MCP returns success only when execution is completed and the outcome is accomplished.
World mutations carry receipts
A mutating operation persists a MutationReceipt with attempted, succeeded, failed, and skipped counts, per-item terminal states, and whether an authoritative reread was performed and passed. Batch success therefore means the requested final state was observed, not merely that a provider accepted the request. If later production evidence contradicts proof that was trusted, Agentis demotes the workflow and revision to regressed; historical confidence cannot remain green after reality changes.
What downstream automation is allowed to trust
Downstream business automation should normally subscribe to run.accomplished, not run.completed. The former is a verified world outcome; the latter is only a settled execution. A rule can instead wait for a typed external event such as an inbound message, approval, webhook, provider receipt, or datastore transition. This keeps workflows from advancing because an agent said it sent a message, when the real process requires a reply, consent, or delivery evidence.
Continue
The production procedure for changing a workflow without replacing the last proven implementation.
Cross-workflow activations are persisted before execution, then claimed, retried, and recovered with idempotent delivery identities.