Reliable by Design · 05.01
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.
Continue
The scoring mechanics behind recall: freshness decay, trust weighting, reranking, and MMR diversification, explained with real inputs.
How a failed node recovers: deterministic rebind, capability-aware remedy, config-aware surfacing, certified structural repair, then honest escalation.