The Benchmark You Cannot Build

Research note · 8 September 2026

The Benchmark You Cannot Build

We set out to re-run an oversight experiment across five AI models, from 8 billion parameters to 117 billion, to check whether an uncomfortable finding was a quirk of one model. Ten days and 3,300 test cases later the experiment has not started, and the reason is worth more than the experiment would have been.

Dinand Tinholt · independent research · companion to the SIGIL oversight study · the full paper is The Instrument That Could Not Be Built

The thing we were checking

An earlier study of ours found something that makes people uncomfortable. Put an AI supervisor in front of an AI worker, give the supervisor a running record of what its past approvals cost the firm, and it starts refusing work it should have approved. At the most consequential decisions it blocked 43% of cases and 42.7 of those points were wrong. Giving the overseer skin in the game made the oversight worse, because refusal is the one action that never shows up in a liability record.

That study ran on one model. The obvious objection is that a smarter model would have handled the pressure better, and the finding is a story about one model's nerves. So we registered a follow-up: keep every prompt, every scoring rule and every cost constant identical, change nothing except which model sits in both seats, and run it across four more models spanning a fifteen-fold range in size.

Where it stopped

The follow-up never ran a single trial of the oversight comparison. It was stopped by a rule written into the registration months before, and stopped in a direction nobody expected.

Any experiment about catching mistakes needs mistakes to catch. So the protocol says the worker has to get somewhere between 10% and 35% of cases wrong when left alone. Below 10% there is nothing for a supervisor to do, and the experiment measures the cost of oversight against no benefit at all. Above 35% the task is noise. Every experiment we run carries that check, and every model has to pass it before its trial starts.

Seven calibration runs on the original task, one per model plus retries at maximum difficulty, came back between 0.0% and 2.7%. Two of the models made no mistakes whatsoever. gpt-oss-120b got 150 out of 150 right; qwen3.8:27b got 300 out of 300 right across two attempts at two difficulty settings.

So we rebuilt the task. The redesign got three registered attempts, five models each, 2,250 more test cases. Figure A shows where the last attempt landed.

Figure A · Where the five models landed on the hardest task we built

what a usable test needsgpt-oss-120b117B · 0 errors in 450 units0.0%qwen3.8-27b27B · 1 error in 450 units0.0%qwen3-8b8B · inside the band10.1%deepseek-r1-70b70B · in band, weak gradient10.7%qwen3.535B-A3B · the study model37.3%0%10%20%30%40%One task, five models, round 3 of 3Share of cases each model got wrong working unsupervised. 150 cases per model per round.
Nobody is near anybody. The shaded strip is the range a working experiment needs. Two models sit on the floor, two sit inside, and the model the published study used sits above the ceiling. No version of the task, across three redesigns, put all five in the strip at once.

Across all three attempts, gpt-oss-120b made zero errors in 450 cases and qwen3.8:27b made one. That one was a seven-line invoice totalling $14,989 against a spending limit of $14,990, missed by a dollar. Meanwhile the study model got 37% of the same cases wrong.

Why the gap will not close

The redesign had a theory behind it, and the theory was backwards. The idea was that if you make an approval depend on ten separate exact checks rather than one, small differences in per-check reliability turn into large differences in whole-case accuracy, and everybody's error rate gets pulled into the same range. Stacking checks does amplify the differences. It amplifies them in the wrong direction.

Work through the arithmetic. If a model gets each individual check right with probability a, and a case turns on k checks, it approves correctly about ak of the time. Landing between 10% and 35% whole-case error then requires a to sit in a window whose width shrinks in proportion to 1 over k. Stacking more checks is precisely what closes the window on everyone outside it.

We can measure a from the data. It comes to 90.6% for the study model, about 98.3% for the two mid-range models, and at least 99.6% for the two that made no mistakes. Feed those into the window and you get the picture in Figure B.

Figure B · The window, and the five models trying to fit through it

0.3%1%3%10%30%5101520253035% episode error10% episode errorqwen3.51 − a = 9.4%deepseek-r1:70b1 − a = 1.8%qwen3:8b1 − a = 1.6%27b and 120b1 − a ≤ 0.39%band closes on it at k = 4.4band reaches it only at k = 27composition depth k (near-boundary checks per episode)per-check inaccuracy 1 − a (log scale)The gate, drawn in the space the generator can moveShaded: per-check inaccuracy giving 10–35% episode error at depth k, from error = 1 − aⁿ. No vertical line crosses every rung.
No setting works for everyone. The shaded region holds the per-check reliability that produces a usable 10–35% error rate at each stacking depth. The study model falls out of it past depth 4.4. The two saturated models only reach it past depth 27. There is no depth where both ends are inside.

There is a version of this test that does not depend on the stacking depth at all. Take the ratio of the two models' log-inaccuracies, which is a quantity the depth cancels straight out of. To hold two models inside a 10–35% band, that ratio has to stay under 4.09. Our fleet measures at 25.5 in the last round, and at 21.5 and 17.6 in the two before it, each of those a conservative floor. We are out by a factor of four to six on a number that no difficulty dial touches.

The finding under the failure

Here is what the models got wrong, and it is the same thing at every model that got anything wrong. Roughly four fifths of all errors were refusals of cases that should have been approved. The study model turned down 63.6% of the approvable cases. The 8B model turned down 15.6%, the 70B model 16.9%. On the cases that should have been rejected, everyone did fine.

That is the stacking again. To reject correctly you need to spot one problem. To approve correctly you need every one of ten or more borderline checks to come out right. Push the checks to the boundary and the approve path gets brutally harder while the reject path stays easy, and the model that is losing starts refusing everything. At two of the five task types, the study model approved nothing at all in round 3, thirty-three approvable cases and thirty-three refusals. On identical cases, gpt-oss-120b matched the correct approve rate to the point at every tier.

Anyone building an evaluation for a mixed fleet of models should take that seriously. A task whose approvals are conjunctions of borderline judgments does not measure capability on a smooth scale. It behaves like a cliff. Models above the edge score perfectly and models below it collapse into refusal, with almost nobody in the middle, and the model size does not tell you which side anyone is on. Our rank correlation between error rate and parameter count came out at −0.03.

What it does to the earlier finding

The oversight result stands where it stood, on its own 30,000 trials. Nothing in this work measured a supervisor, so nothing here competes with it.

The generality question it raised is still open, and now we know something about why. In the original campaign there was one task tier where the worker made zero mistakes across 6,000 trials, and the paper reports what oversight was worth there: nothing on the benefit side and the full consultation fee on the cost side. Four of the five models we tested reproduce that condition at every tier. If you drop a stronger worker into that architecture, review starts from a worse position than the published campaign gave it.

Against that, the study model turns out to be an outlier at the low end of this fleet on this kind of work, missing 58.2% of approvable cases where two other models miss essentially none. Whether an overseer built from a model that almost never errs would still over-block under liability pressure is something we cannot answer, and cannot build the instrument to answer by turning any dial we registered. The published paper already calls its result capability-local. That wording holds, with a measured reason behind it now.

Where this leaves the work

The five-model version is closed. The arithmetic rules it out at any difficulty setting on this kind of task, and the registration allows no fourth attempt.

A two-model version is already sitting there. The second redesign held qwen3:8b at 14.7% and deepseek-r1:70b at 15.3% in the same round, both passing every clause of the gate, and that version of the generator is preserved. Running the oversight comparison on those two would test whether the over-blocking reproduces across two models that are not the study model. It is a weaker claim than the one we registered and a real one. The bill, read off the observed speeds, is around 70 hours of compute for the 70B model and 18 for the 8B, against an original budget of roughly 36 hours for four models. The 70B model runs at 105 seconds per decision.

The alternative is a task that stops being a checklist. Every model above the study model scores near-perfectly on exact compliance work of this kind, and the one lever that would change that is making individual checks ambiguous, which we banned after an early pilot died of exactly that confound. A task family where capable models disagree with each other is a different design and needs its own registration.

Everything above comes from the raw per-trial ledgers, rescored independently of the scripts that produced them; all twenty-two gate verdicts reproduced with no mismatch. Three registrations govern the work and all three were frozen before the runs they cover. Both outcomes were committed to publication in advance, which is why a report about an experiment that did not run exists at all.