20 systems. 196 machine checks. Our gated pool matched the best on correctness, beat every frontier lane we profiled on maintainability and runtime, and did it at $0.0063 a task. The most expensive frontier model never even finished. It's not the model. It's a gate.
We spent months arguing that the AI industry optimizes the wrong number, and this month we finished the benchmark that settles it for us. 20 systems. 5 algorithmic tasks. 196 machine checks, 63 of them hidden from every builder. The system that produced the best code by the objective measures we ran, and matched the best on correctness, was not a frontier model. It was a pool of low-cost models wrapped in a machine gate, running a loop we call the gated climb. Its bill: $0.0063 per task. The frontier lanes that matched its correctness charged 2.5 to 29 times more. The most expensive frontier model in the lineup never finished at all.
Run the arithmetic at production volume and it stops being academic. 1,000 accepted-grade tasks a day costs about $6 on the gated climb. The frontier lanes that hit the same correctness bar cost $16 to $183. Per day. Same tasks, same checks, same finish line.
Quality is the part that surprised even us. This is not a budget option that's respectable for the price. Once we normalized formatting and measured substance, the gated pool's code had the highest maintainability and the fastest runtime of the 4 leading lanes we profiled, above the frontier models, with clean security findings. Better code. Fraction of the bill.
The number that decides an agent stack is not cost per token. It's cost per accepted task, weighted by what the accepted work is actually worth. Everything below is mechanism, war stories, and receipts.
Forget prompt engineering, loop engineering, and graph engineering for a minute. The taxonomy is real: prompts design the exchange, loops design the cycle, graphs design the organization, and each hype cycle moves the design problem up a level. But every rung of that ladder is a way to spend compute. Not one of them tells you when to stop spending. The loop needs an exit test. The graph's controller needs "good enough." The layer that decides has no name in any of the threads, and it's the only layer with a measurable ceiling.
The honest objective function is cost per accepted task: everything you spent, divided by the number of outputs that actually passed acceptance. Failures, retries, and evaluator time go in the numerator and add nothing to the denominator, which is how a stack that looks inexpensive by token prices turns out to be a money pit by the only number the business feels. Cost per token is what the pricing page shows you because it's the number that flatters the seller.
So the question that decides your stack is: what test does an output have to pass before you accept it and stop paying? That test is the gate. Gate engineering is the design of that acceptance test: what it checks, what it costs to run, how hard it is to fool, and what the system does when it fails.
A gate gets used two ways. You can score what comes back, or you can climb it. The gated climb is our method, the Anvil method, developed at Ferrox Labs: draft with a low-cost model, run the gate, repair the named failures, keep a change only when it strictly improves, escalate only where the low-cost pool is stuck, stop at green. Gate engineering is the discipline. The gated climb is our method within it. Anvil is our production implementation of the method. 3 terms, 3 layers, and we'll be precise about which one each claim belongs to.
Gates are not new and we won't pretend otherwise. Counterexample-guided synthesis has iterated against verifiers since before LLMs. Test-suite-based program repair is a decade-old research field. Synthesize-execute-debug loops were published in 2020, and AlphaCode was filtering thousands of candidates through test gates in 2022. What we're contributing is narrower and, we think, more useful: the outcome-cost accounting, the strict-subset ratchet, per-check escalation instead of per-task escalation, and verification receipts, measured together as a system against the frontier. And a name for the discipline, because you can't budget for something that doesn't have one. "Prompt engineering" did that job once. We're proposing "gate engineering" does it here.
The claim, made falsifiable: your system is never reliably better than its gate. Outputs can exceed what the gate measures; the gate just can't certify the excess, which means you can't bank it. The gate is the assurance ceiling. Improve the loop, the graph, or the model and you reach that ceiling faster. Only improving the gate raises it.
A blacksmith doesn't trust the hammer. The hammer is enthusiasm. The anvil is where the work gets tested: you strike, the metal answers, and the metal doesn't care how expensive your hammer was. We named the executor Anvil because that's the whole philosophy in one word. Don't admire the output. Bend it and see if it breaks.
Here's the method, and notice how boring the loop is. The intelligence lives in the gate.
One low-cost model, one attempt. Clears the gate → done. Most easy tasks end here, at fractions of a cent.
Machine-run checks. Score plus failing check IDs. The builder never sees the gate's source or expected values.
Surgical repair aimed at one failing check. Score never decreases; ties accepted only if the failure set strictly shrinks.
Frontier model called only for the specific check the low-cost pool is stuck on. Per check, not per task.
All checks pass → stop. Deterministic tooling polish (format · lint · security), re-gated, non-regressive.
For the record, and for the paper to formalize, the whole method fits in 10 lines:
The probe is the economics. One low-cost model gets one clean attempt, and the gate decides. Green means finished: no ensemble, no critic, no frontier call. Watch it live:
$0.0007 for a solved task is what task-adaptive spending actually looks like. The system spends more only when the gate says it must, and on the second trace you can watch the spending logic operate: probe fails, a small ensemble of low-cost models takes a swing, then surgical repairs target one named check at a time until green. The frontier never got a phone call.
The ratchet rule sounds obvious and isn't, and we know because we shipped the wrong version first. Our first acceptance rule was "keep any repair with fewer failures." We watched it ping-pong, live, between two wrong answers. Version A failed checks 3 and 7. Version B fixed those and broke 4 and 9. Then version A came back. Equal counts, different failures, metered spend, zero progress. The fix is one line: the score must strictly increase, and a tie is accepted only when the new failure set is a strict subset of the old one. Fixed at least one thing, broke nothing. Note the precision, because it matters: a strictly higher score can still trade failures, so the tie rule is what carries the non-regression guarantee at the check level. That one clause is the difference between a climb and a coin flip.
The repair payload is deliberately starved. What goes to a repairing model: the spec, the current best candidate, the name of the target check, and the names of up to 8 other failing checks. What never goes: the gate's source, its expected values, its assertion logic. If a candidate comes back and the gate scores it worse, it's discarded without appeal, and the model that produced it is never re-asked about a check it already fumbled while that check still fails. Models that land repairs move to the front of the queue. Bookkeeping, not intelligence, and it's what stops the loop burning budget on a model that has proven it doesn't understand check 12.
Escalation is per check, not per task. Only when every low-cost model has had its shot at one stubborn check does the loop hand that check, that one check, up the escalation ladder to a frontier model. That's where the cost curve comes from, and it hands you something the graph-engineering threads call an open problem: credit assignment. When a run needs the frontier, the climb log names exactly which check needed it.
And the budget is a bound, not a boast. The whole climb is capped at about 12 calls, then it stops: green, budget, or plateau, always. We'll make the modest claim and not the grand one: a 12-call loop bounds how much a builder can learn about the gate's blind spots per task. It does not make the gate ungameable, and §06 is honest about what does and doesn't. What the cap certainly buys is the halting guarantee. The loop cannot thrash, because it isn't allowed to.
Output can exceed what the gate measures, but you can't bank what nothing certifies. Invest in gate fidelity before loop cleverness or model pedigree.
Score strictly up, or same score with strictly fewer failures. Nothing else lands. Progress is monotonic by construction, at the check level, not just the score level.
Frontier models are a scalpel for the one check the low-cost pool can't clear. That's the entire cost curve, and failure localization comes free.
The design brief for the benchmark was density, not breadth. 5 tasks, on purpose: small enough that every task could carry an unusually deep gate. 133 visible checks builders could climb against, plus 63 hidden mutation checks no builder ever saw, the overfit detector. That's 196 machine-checkable verdicts across 5 tasks, which is a very different instrument from 1,000 tasks skim-checked by exact-match. Single-file Python is the friendliest terrain for machine gates, and we chose it for exactly that reason: prove the ceiling where gates are strongest, then earn the harder domains one gate at a time. We'd rather you read that as a design choice here than discover it as a caveat later.
Provenance, because the method is most of the argument: this began as a lab harness to test our own premise before we bet our stack on it. We wrote the tasks, we wrote both check sets, and our executor is one of the 20 lanes. The gates and the method were developed in the same lab, and we won't insult you by claiming a firewall we can't prove. What we can prove: every gate was validated against a known-good reference that must pass and a known-bad mutant that must fail, before it scored anything. The same gates scored every lane, frontier included. No builder saw the hidden checks. And the whole fold is public, so the strongest form of trust is available: run it yourself, or write a hostile gate and break us.
The obvious question about hidden checks: aren't they the visible ones reworded? Both sets ship in the repo, so measure the overlap. And the solo lanes dropped hard from visible to hidden, which only happens when the two sets catch different failures.
Scoring ran 3 ways: visible gate, hidden gate, and a 3-model cross-provider judge panel on a locked rubric. Then a 4th pass on the 4 leading lanes: normalize formatting with an auto-formatter so nobody wins on prettiness, then measure lint findings, security findings, cyclomatic complexity, maintainability, and actual runtime. One thing to be clear about before the table: the machine gates are deterministic and we trust them. The judge panel is heuristic, we include it because the industry uses judges, and one of this benchmark's findings is precisely how badly a judge can mislead. Deterministic gates and model judges are not the same kind of instrument, and this article never pretends they are.
Here's the whole experiment in 5 sentences. We took one low-cost model, the one our executor probes with first, and ran it bare: 87.6% on the 133 visible checks, 83.8% on the 63 hidden ones. Then we ran models of the same price class through the gated climb: draft, gate, repair the named failures, accept only strict improvement, stop at green. The pool finished at 100% visible and 98.4% hidden. On the task that cracked the bare model hardest, 48% visible and 27% hidden, the climb finished 100/100.
The hidden number is the one to stare at. A system that climbs visible checks will pass visible checks. That proves nothing; it's by construction. But climbing the checks it could see fixed failures on checks it could not. To be precise about what we measured: the whole method moved, gate plus climb plus escalation together. Splitting out each piece's contribution is ablation work, and it belongs to the paper we're preparing. What this benchmark establishes is the system-level result, and the system-level result is not close.
The complete fold, split by who cleared every visible check, cheapest first. Anvil is the cost baseline.
| TABLE A · CLEARED ALL 133 VISIBLE CHECKS (10 lanes) · ordered by cost per task | ||||
|---|---|---|---|---|
| # | lane | hidden % | judge /10 | $ / task (× Anvil) |
| 1 | Anvil (the gated climb) | 98 | 7.85 | $0.0063 · baseline |
| 2 | gpt-5-6-luna | 100 | 8.10 | $0.0160 · 2.5× |
| 3 | deepseek-v4-pro | 99 | 7.27 | $0.0265 · 4.2× |
| 4 | opus-4-8 | 98 | 7.47 | $0.0388 · 6.1× |
| 5 | fugu | 100 | 8.73 | $0.0399 · 6.3× |
| 6 | gpt-5-6-terra | 100 | 8.35 | $0.0427 · 6.7× |
| 7 | gpt-5-6-sol | 100 | 8.88 | $0.0799 · 12.6× |
| 8 | claude-sonnet-5 | 98 | 8.10 | $0.0807 · 12.7× |
| 9 | kimi-k3 | 100 | 8.82 | $0.1744 · 27.5× |
| 10 | gemini-3-1-pro | 100 | 7.90 | $0.1829 · 28.9× |
Every row on this table reached the same finish line. The bill is the only real difference: 6 lanes matched or edged Anvil on the hidden gate, and every one of them paid 2.5× to 28.9× more per task to do it.
| TABLE B · FELL SHORT OF 100% VISIBLE (8 lanes) · ordered by correctness | ||||
|---|---|---|---|---|
| lane | visible % | hidden % | judge /10 | $ / task (× Anvil) |
| glm-5-2 | 99 | 100 | 7.55 | $0.0191 · 3.0× |
| grok-4-5 | 99 | 98 | 8.05 | $0.0263 · 4.1× |
| claude-haiku | 95 | 89 | 6.17 | $0.0091 · 1.4× |
| minimax-solo (Anvil's probe model, bare) | 88 | 84 | 6.72 | $0.0019 · 0.3× |
| fugu-ultra | 80 | 79 | 6.82 | $0.1046 · 16.5× |
| mistral-large | 78 | 66 | 6.35 | $0.0022 · 0.3× |
| qwen-plus | 61 | 56 | 6.03 | $0.0230 · 3.6× |
| openrouter-fusion | 59 | 58 | 8.75 | $0.3191 · 50.4× |
Correctness isn't bought. The bottom row is the most expensive lane in the entire fold, 50.4× Anvil's bill, and it passed 59% of the checks. Note its judge score: 8.75, higher than 8 lanes that got everything right. That's finding 3, sitting in plain sight.
hermes, a mixture-of-agents product, was invoked on every task and never completed one: each run hung past our timeout with no output, including a trivial warm-up task, at $0.000 measured spend. That reads as a pipeline failure on its side of the wire, not a capability result, and we didn't diagnose a third party's outage on benchmark time. fable-5, the most expensive frontier model in the lineup, returned empty output behind a content filter on 4 of the 5 security-probing specs; on the 1 spec that ran, it posted a perfect gate score. Neither earned a zero. Neither got to compete. Both stay out of the tables so their absence is a fact, not a statistic. Full detail on the Fable case below.
Then there's the lane we had to flag instead of score. Fable 5 didn't make the cut, and "folded" means something specific: its output came back empty behind a content filter on 4 of the 5 specs, so there was nothing to evaluate and the lane is flagged, not counted as a zero it earned. The benchmark pokes at security behavior on purpose. Malformed input, path traversal, open-redirect tricks. The filter saw the content, not the intent. On the one spec that ran, it posted a perfect gate score. A safety filter is a gate too, and a miscalibrated one doesn't make anyone safer. It just leaves a very good model outside the arena.
One claim per chart. Every chart is generated by a committed script from the raw results; regenerate and diff them at will.
10 lanes reached 100% on the visible gate. Here's what each one paid to get there. This is the whole cost-per-accepted-task argument in one picture: when correctness ties, price decides, and it isn't a contest.
We took the 4 leading lanes, normalized formatting so nobody wins on style, and measured substance. The gated pool didn't just hold its own. It produced the most maintainable and the fastest-running code of the 4, with clean security findings. Beyond the frontier lanes on the quality axes we measured, not merely near them.
| lane | correct (visible) | maintainability ↑ | runtime ↓ | avg cost/task ↓ |
|---|---|---|---|---|
| Anvil (gated pool) | 100% | 51.6 | 103 ms | $0.012 |
| claude-opus-4-8 | 100% | 47.5 | 139 ms | $0.251 |
| gpt-5-6-sol | 100% | 42.7 | 157 ms | $0.453 |
| gpt-5-6-luna | 97% | 44.0 | 349 ms | $0.082 |
Same price class of model, method on versus method off. Bare: 87.6% visible, 83.8% hidden. Through the climb: 100% and 98.4%. The worst solo crack, 48/27, finished 100/100.
Fusion products attack the same problem from the opposite direction: blend many models' opinions and trust the consensus. Respect where due: fugu hit 100% on both gates, including a hidden score above ours, and it's the only rival that did. It paid 6.3× our bill for it. The rest of the category didn't survive contact: fugu-ultra at 80% for 16.5×, and openrouter-fusion at 59% for 50.4×, the most expensive lane in the entire fold with barely half its checks passing. Consensus is expensive and it isn't verification.
Our judge panel is 3 models from 3 providers scoring against a locked rubric, about as hardened as an LLM judge gets. It still handed openrouter-fusion, 59% correct, a higher style score than 8 lanes that got everything right. Pretty code broke the judge. That finding is why the objective re-score exists, and it's why the machine gates, not the judges, are the method's foundation. If your gate is a model's opinion, your ceiling is a model's taste.
| running 1,000 tasks/day | per task (fold run) | per day | per month |
|---|---|---|---|
| Anvil (the gated climb) | $0.0063 | $6.34 | $190 |
| least expensive frontier lane at 100% (gpt-5-6-luna) | $0.0160 | $16.02 | $481 |
| most expensive frontier lane at 100% (gemini-3-1-pro) | $0.1829 | $182.91 | $5,487 |
All 3 rows from the same run (the 20-lane fold), where every lane completed 5/5 tasks: the per-task figures carry no hidden failure costs. Model inference spend only; gate execution for these tasks is a subprocess that runs in milliseconds for effectively $0.
Every AI engineer eventually builds the critic loop. Generate, critique, refine, repeat. It feels rigorous. It demos beautifully. So we built 2: a single post-green polish pass, and a full critic-guided refinement loop on top of it. Multi-round review, quality scoring, the works.
The judge panel loved the output. Scores went up.
The hidden checks did not move. The polish tiers cost multiples of the base climb and gave back nothing on the measurements that matter, and polish-stage rewrites are exactly where a regression can slip in behind a green visible gate. So every transform in our stack now has to re-pass the full gate before it's kept. A rewrite that drops a check is discarded. No appeal.
Then the genuinely annoying part. We ran a free deterministic formatter over the plain output, the kind of tool that changes zero execution behavior, and most of the judge's perceived quality gap closed on its own. We had been about to charge tokens for what a formatter does for nothing. We cut our own feature and kept the free one: after green, run the language's canonical format, lint, and security tooling, re-gate, keep only if nothing regressed. Deterministic. Un-gameable. $0.
If the gate is the assurance ceiling, the obvious attack is on the gate itself. Here's the trust boundary, drawn as a picture:
The model has to actually fix unary-minus handling, because there is nothing else to overfit to. Judge and generator stay separate for the same reason a student doesn't grade their own exam, and the strongest gates use no model at all.
We attacked our own gates, and we'll tell you what happened. A candidate that monkeypatches the test harness at import time can flip checks green. That's not a hypothetical: our own red-team probe did it. So the claim boundary is exactly this: our gates detect ordinary defects and known-bad mutations. They are not tamper-proof against a deliberately adversarial submission. Real containment, running candidate code with no path to the gate process at all, is an architecture problem we're solving in the runtime layer, not a prompt problem. Gates catch mistakes. Sandboxes catch malice. A production system eventually wants both, and pretending the first covers the second is how verification gets a bad name.
The obvious objection to all of the above: code has tests, most work doesn't, so this is a coding trick. We think that's a failure of gate imagination, and this section is the part we most want stolen. Nearly every domain admits a gate. The craft is choosing the strongest gate the domain admits instead of the weakest one that's easy to build. Our working taxonomy, strongest to weakest:
| tier | gate | domains | how it checks |
|---|---|---|---|
| 1 · Executable | run the artifact | code, SQL, web UI, agentic tool-use, infra, numeric math | tests pass, the query returns the right rows, the side effect actually happened |
| 2 · Formal | proof / schema / solver | structured output, logic, proofs | schema validation, constraint solver; fails closed, near-free |
| 3 · Reference | diff vs. golden | extraction, translation, classification | field-level ground truth, round-trip reconstruction |
| 4 · Grounding | every claim entailed by a cited source | research, RAG, long-form | claim decomposition → per-claim entailment → support score |
| 5 · Consistency | agreement / round-trip | cross-cutting | inexpensive pre-filter only, never the final word |
| 6 · Judge | model panel, locked rubric | writing, design, conversation | cross-provider judges on an evidence-anchored rubric; the only tier that reward-hacks, so it's the fallback, not the plan |
(This is the gate taxonomy. It's a different ladder from §03's escalation ladder, which orders models by price. 2 ladders, 2 jobs.)
A worked example, because the table undersells it. Take an agentic task: book the meeting room and email the team. The weak gate asks a judge model whether the transcript looks successful. The tier-1 gate ignores the transcript and checks the world: does the calendar API now return the booking, did the email land, does the end state match the spec? "The agent said it did something" is worth nothing. "The world changed" is worth everything.
Or research, the domain everyone writes off as unverifiable. Tier 4 says: decompose the draft into atomic claims, require every factual claim to cite a source, check each claim against the passage it cites, score the support, climb on the failures. Research isn't ungateable. It's grounding-gated, and once you see it that way, "you can't test prose" starts sounding like "we haven't written the gate yet."
This week we ran that conviction through the production executor. 3 tasks, 1 verb, only the domain label changed. We'll characterize the result honestly: these demonstrate the gates, the routing, and the loop's plumbing across domains. All 3 went green on the first probe, so no cross-domain climb was exercised on a working gate. The multi-task, deliberately-failing version of this is the paper's job.
| proof task | domain | gate tier | gate score | hidden | rounds | wall clock |
|---|---|---|---|---|---|---|
| release manifest (JSON) | structured-gen | 2 · schema | 16/16 | n/a | 1 | 115 s |
| cited research brief | research | 4 · grounding | 14/14 | n/a | 1 | 64 s |
| toposort (code parity) | code | 1 · executable | 18/18 | 10/10 | 1 | 61 s |
Every final artifact re-scored independently outside the executor, same numbers. The code row matches the original benchmark lane exactly: 18/18 visible, 100% hidden.
And since "you can't test prose" deserves a body, not a hand-wave, here is the actual grounding gate the research brief had to pass. 14 machine checks. A deterministic grounding proxy: citation discipline, number-level grounding, required coverage. The full entailment version, where a model verifies each claim against its source, is the production path; this is the offline-reproducible subset.
Change one digit in the brief and the gate goes red on exactly the checks that guard digits. There's a joke buried in here too: the research task we gated was a brief about this very benchmark. The gate held our own claims to account. Honest work.
One run earned a footnote we're oddly proud of. On the first code-parity attempt, a broken gate harness (our bug, a Python loader issue, since fixed and revalidated) meant no candidate could ever pass. Watch what the climb did against a gate that could never go green:
9 rounds, the full escalation ladder, honest surrender. If you're going to trust a loop with your money, this is the trace to demand from any vendor: what does it do when winning is impossible? Ours stops and says so.
The limits, plainly, because half of gate engineering is deciding what you're not entitled to claim. The headline benchmark is 5 single-file Python tasks with unusually deep gates: dense, but narrow, and chosen because it's the terrain where machine gates are strongest. The cross-domain proofs are 1 task per domain, all first-probe green: they prove the gates and the plumbing, not cross-domain climbing. The comparison measures the whole method against bare models; it does not isolate which component does what, and anyone who wants that ablation is asking the right question. It's the centerpiece of the paper in preparation. The gates are operator-authored, which puts our blind spots inside the assurance ceiling. Goodhart pressure is permanent: any gate a system can see, some system will eventually satisfy in letter rather than spirit, which is why the hidden checks, the starved repair payload, and the call budget all exist, and why none of them adds up to tamper-proof. And yes: run it on SWE-bench is a fair demand. Dense micro-gates were this benchmark's design choice. Big-bench terrain is the next campaign.
We didn't build this for an article. We benchmarked it because we were betting our stack on it, and the stack is live.
Ferrox Factory, our agentic build system, has a lineage that matters here: it's the tool we used to build Wayland and Wayland Core. As of this month, the gated climb is its default executor. Every increment declares a domain, the Factory selects the strongest gate tier that domain admits, gateable work climbs, ungateable work goes to a judge council, and everything still faces the same fail-closed merge gate as any human diff. The factory that built our products now refuses, by default, to ship work nothing verified. 714 machine checks run green on the Factory itself before any of this shipped.
FluxRouter, our model router, runs the loop server-side. The design principle is the one we build everything around: don't make me think. Send an ordinary API request; the router probes low-cost, gates, climbs, escalates only where the gate demands, and returns output with a verification receipt: which checks ran, how many passed, how many attempts, and what the same result would have cost at frontier list prices. The open engineering problem there is the gate source. Caller-supplied checks are iron-clad. Server-derived checks are the server grading homework it also wrote, and they need holdouts and cross-checks before the receipt can be honest about its own confidence. That's the frontier of this discipline.
Wayland Core, our primary agent, runs the climb in its agent engine and holds the taxonomy's last tier: Crucible, its cross-provider council, is the hardened tier-6 judge panel everything falls back to when no stronger gate exists. Agent does the work, council judges the work, gate decides. Nothing in our stack ships on vibes anymore, and the 3 products enforce that on each other.
A claim like "your system is never reliably better than its gate" deserves a gate of its own. The full benchmark is public: task specs, both check sets, every result record including the generated code for all 18 objectively re-scored cells, and the scripts that emitted every chart above from the raw JSON. One command re-runs every gate against the shipped outputs and confirms the recorded scores reproduce:
A formal write-up is in preparation for arXiv: the ablation that splits the method into its parts, the accounting standard for cost per accepted task, and a versioned "Gate Card" spec so a gate's rigor can be cited the way a model card is. Until then the repo is the working paper, and it takes challenges: author a hostile gate, break our numbers, send the receipt. Somebody will. That's the discipline working exactly as designed.
The hype cycle will name something new next quarter. Meanwhile the gates for research are younger than the gates for code, the self-derived-check problem is open, and the cost-per-accepted-task number in your own stack is either going down or it isn't.
Ferrox Labs builds gate-first AI systems: Ferrox Factory (agentic delivery), FluxRouter (verified model routing), Wayland Core (agents with a judge council). Benchmark method, limits, and lane-by-lane reproducibility notes live in the gatebench repository, including which lanes reproduce with a public API key and which ship as static evidence. We'd rather you re-run it than believe us.