Stand-Pat: The Option to Do Nothing Is a Move

A queen-sacrificing chess bug from 2003, a warning email that sat unread for twenty-two years, and the one rule every forced-choice system keeps forgetting: score the status quo as a candidate, and let it win.

In January 2003 I entered my chess engine in a Computer Chess Tournament for the first time. It played some genuinely good games. It also, more than once, did this: queen takes pawn. Pawn takes queen. It had handed a full queen to the other side for a single pawn, for no reason a human would recognise — and the evaluation on my screen didn't so much as flinch beforehand. No warning. The score stayed calm, the engine looked confident, and then the material was simply gone.

It took me months to find the cause, because the engine wasn't broken in any way that looked like broken. It didn't crash. It didn't always lose — it finished mid-field, around 4 out of 9. It played plausibly most of the time and catastrophically some of the time, and the two were indistinguishable from the outside. When I finally found the bug, it turned out to be one missing line. And that line is the whole of this article, because I have since watched the same bug ship in retrieval pipelines, in AI agents, and in the way smart people convene AI to pressure-test their own decisions.

The bug was a missing permission, not a missing feature

Some quick chess-programming background, because the mechanism is the point and it transfers cleanly. A chess engine can't search every position to the end of the game, so it searches a few moves deep and then evaluates the board — counts material, weighs king safety, and so on. The problem is that a fixed depth can chop a position off mid-exchange. If your search stops the instant after you've captured a pawn but before the recapture, you'll think you're a pawn up when you're actually about to lose your bishop.

The fix for that is quiescence search: when you reach your depth limit, don't evaluate a "noisy" position — keep searching, but only the forcing moves (captures, checks) until the board goes quiet and the static evaluation can be trusted. You iterate through the hot options, resolving the tactics, and only then do you score.

Here's the line I got wrong. In a correct quiescence search, before you look at any capture, you first take the evaluation of the current board as a candidate — a baseline the captures have to beat. This is a real, named technique in computer chess. It's called the stand-pat score, a term borrowed straight from poker, where "stand pat" means playing the hand you're holding without drawing any cards.¹ The stand-pat is a lower bound: at least this good. Search the captures against the option of doing nothing, and take a capture only if it beats standing pat.

I forgot to put the stand-pat in. My loop generated all the captures and made me choose one of them. It never occurred to my code that you could run through every capture on the board and still say: no, I don't want any of these; I'll keep the position I've got. So the side to move was compelled to grab. Queen-takes-pawn happened because a capture existed and something had to be chosen.

The bug is a philosophy statement. I'd accidentally made captures mandatory. That's not aggression — it's compulsion. The engine wasn't playing sharp chess; it had no right to decline.

Sit with that distinction, because it's the one the whole piece turns on. From the outside, a system that always acts looks decisive. But an engine that must capture isn't being decisive — it has had its power to decline removed. Decisiveness includes the option of "no." Take that option away and what's left isn't a bolder chooser; it's a chooser that has lost the ability to leave things alone.

There's a lovely detail in the standard algorithm that makes the rule even sharper. Stand-pat is the default — except when you're in check. When you're in check you're not allowed to stand pat, because a check can be a real threat that has to be answered; you can't assume a quiet option exists.¹ So the mature design isn't "always allow doing nothing" or "never allow it." It's: doing nothing is the standing default, and only a genuine, must-answer event removes it. Hold that thought — it comes back when we talk about agents that interrupt you.

Why it hid for months

The reason a one-line bug cost me months is the most useful part of the story, because it's the same reason these bugs survive in production systems today.

First, it didn't crash and it wasn't always wrong. Mandatory-capture is a perfectly good heuristic in most positions — most captures worth having are worth making. So the engine played reasonable chess the large majority of the time and only face-planted in the specific positions where declining was the whole point. A bug that is wrong maybe five percent of the time and confident one hundred percent of the time is the hardest kind to find, because the thing that would normally alert you — the evaluation — never flinches.

Second, and this is the eerie part, the score stayed calm even during the disaster. My engine used a symmetric search: the same buggy quiescence code ran for both colours. So after my queen grabbed the pawn, it was the opponent's turn, and they were forced to recapture by the same broken rule, and the horizon landed such that my side kept assuming a forced continuation that paid it back. The bug hallucinated a phantom forcing sequence in both directions, and because it was self-consistent across moves, the score held steady right up until the tactics resolved past the search horizon and the material was actually gone. Minus nine appeared the instant reality outran the forced line.

A symmetric bug hides in its own symmetry. The eval didn't scream because the same mistake was being made on both sides of the board, and two consistent errors read, from the inside, exactly like the truth.

This is the general lesson, and it's worth stating plainly because it's not intuitive: a missing null option doesn't crash your system. It biases it. There's no exception, no stack trace, no red light. The system keeps producing confident output. It just quietly leans — toward action, toward the top result, toward "yes" — and because the confidence signal stays clean, nobody goes looking until the score contradicts reality hard enough to be undeniable. By which point you've been donating queens for a while.

The exhibit: a warning that sat unread for twenty-two years

Here's where the story gets its receipts, and its holes.

Back in 2003 I wasn't building this in isolation. I was trading emails with another hobbyist, Joel Veness, and we were both trying to get quiescence search to work — neither of us had a clean one yet. (Joel went on to write serious chess engines and is now a research scientist at Google DeepMind, known for foundational work on AIXI approximation.² At the time we were just two people arguing about move generators.) Twenty-two years later, I went looking through my own archived correspondence for any trace of the bug, and I found something better than my own memory of it.

In a chatty email dated December 2003, wedged between a joke about my lazy evaluation function and a note that he'd just bought an internet chess account, Joel wrote a single line of caution: you don't want to be failing high on every capture.

"Failing high on every capture" is the bug, named as a passing worry, a year before it cost me a tournament. To fail high on a capture is exactly to have every capture beat a floor that isn't there — because there's no stand-pat holding the line. Joel wasn't flagging a defect. He was describing a symptom he happened to be thinking about, and he signed it off with an exclamation mark like a friendly aside. Nobody in that thread knew the line was load-bearing.

That's the thing I want you to notice about the exhibit. The warning has no emphasis. It's the fourth paragraph of an ordinary Wednesday email. The whole reason it cost me months is that, at the time, it looked exactly like every other line around it. The insight and the noise were typeset identically.

And here's why it stayed buried for twenty-two years even though I had it in writing the whole time. When I searched for it, my first instinct was to grep my archive for the obvious terms — "stand pat," "forced to capture," "have to capture." Those words do not appear anywhere in my 2003 correspondence. Joel and I never once wrote "stand-pat." The concept lived under completely different vocabulary. To write the search that would find the email, I'd have needed to already know the phrase — which was the very thing I was trying to recover. A keyword search can't find an idea it doesn't yet have a word for. (The thing that eventually surfaced it was a fuzzy, meaning-based retrieval hint rather than an exact-match grep — but that's a story for another article.)

Two honest holes in the record, because a ledger with holes should say so. The months of queen sacrifices exist in my memory and nowhere in the corpus — I never wrote up the disaster game, so there's no receipt for it. And the email that carried Joel's warning is itself truncated: the archived record dies mid-sentence at the word "FreeC," so whatever he said next is simply gone. The archive kept the warning and lost the disaster. That's what real records look like — not a clean story, a partial one.

The same rule, three more times

I'd have left this as a fond debugging war story, except that over the past year I kept finding the same missing line — and its fix — in places that have nothing to do with chess.

Stand-pat is the ultimate nudge: the null move that says maybe nothing here is worth doing. Strip an agent of the right to answer "none of these," and it'll manufacture a move from whatever's on offer — a chess engine sacks its queen, and a retrieval-as-oracle pipeline returns its top chunk with full confidence, because you never gave it a stand-pat either.

1. Retrieval: the stand-pat built into the hint

The most common shape of this bug in 2026 is the retrieval pipeline that always returns something. You ask a question, it finds the nearest chunk in the vector store, and it hands it over — ranked, confident, and occasionally completely irrelevant, because "the nearest thing" is not the same as "a relevant thing." A similarity search, like my quiescence loop, is a chooser with no null candidate: it will always pick the top of the list, even when the honest answer is "nothing here is close enough."

The fix is the stand-pat, and you can see it in a well-built system. In my own knowledge-retrieval tooling, every hint the system surfaces arrives with an explicit tag: advisory — verify before citing, ignore if irrelevant. That clause is a stand-pat welded into the nudge. The suggestion comes carrying its own permission to be declined. It's the difference between a retrieval layer that commands ("use this") and one that offers ("this might help; it might not"). Twenty-two years after the chess bug, the fix turned up in a prompt. If you want the fuller treatment of how a small signal earns the right to reach a decision-maker, that's the subject of a companion piece, The Nudge Doctrine.³

2. Agents: silence as a successful output

Now the harder case — an agent that watches a stream and decides when to speak. A live copilot, a triage assistant, a meeting co-pilot. Here the missing-null bug is at its most seductive, because an agent that says nothing feels like an agent that isn't working. Product managers ask for "more engagement." The dashboard wants activity. So the agent narrates the stream, flags everything, and trains the human to ignore it.

The correct design is the same rule again: the default output is nothing, and only a genuine, must-answer event earns an interruption — the "not allowed to stand pat when you're in check" rule, ported to attention. I know it's correct because I'd already built it, and forgotten I had. Back in April 2025 I put together a listening harness — a rough plan-act-observe agent that would listen to a live conversation and, when it could genuinely help, whisper a suggestion. Digging it out recently, I found the prompt discipline sitting right there in a text file: responses had to be concise and actionable, with "waiting" as the default when the model cannot add immediate value, and — the line that matters — silence treated as a successful output, because a copilot that comments continuously would become unusable.

That's the stand-pat, encoded a third time, in a .txt file, fifteen months before I had a name for why it mattered. It belongs to the same family as what I've elsewhere called negative cognition — the idea that an agent's real intelligence is in what it chooses not to surface, and that silence, given a rich enough world to judge against, is the expensive high-judgment output rather than a failure to perform.⁴ One clarification worth making, since the two are easily confused: negative cognition is knowledge-driven — it needs a baseline, a model of what's normal, to know that a given event isn't worth raising. Stand-pat is structural — it's a null candidate inside the chooser that works even with zero domain knowledge, because all it does is compare the best available move against the value of doing nothing. Same silence; different engine underneath.

3. Decision panels: the guard against your own preferences

The last appearance is the one that should worry knowledge workers and executives most, because it wears a respectable slogan. The slogan is "humans retain judgment; AI does the work." It imagines judgment as an atomic faculty — a gavel the human bangs at the end.

That's not how good judgment actually runs any more, and it's not how I run mine. When I'm working on something that matters, I don't decide alone and I don't ask the AI for a thumbs-up. I convene a panel: I'll ask an AI to critique the idea, then to strengthen it, then to gather evidence from the web and from my own archive, then to red-team it, then to offer three alternatives. Twelve small opinions, weighted and summed. Judgment turns out to be a much more complex, decomposed thing than the slogan admits — most of what we call "judgment" is option-generation, critique, and evidence-gathering, all of which are now delegable.

But there's a trap in that, and I'll name it because it's the same bug: a panel I convene, whose questions I choose, will validate almost anything I bring it if I let it. That isn't judgment distributed across twelve advisors. That's preference laundered through twelve rubber stamps. An evaluation function whose features only ever score in one direction isn't an evaluation — it's a cheer squad. The habit that keeps it honest is asking "where is this weakest?" as insistently as "make this better," so the terms fire in both directions.

The structural guard is the one from 2003: the panel needs a stand-pat. Somewhere in the twelve voices there has to be a live path to "don't do this at all" — and it has to win sometimes. If you can't remember the last time the panel killed an idea you liked, that's the eval staying suspiciously calm. And you know what comes after that.

The full architecture of chairing an AI panel — how you weight the voices, when the gathering stops, what stays irreducibly human — is a larger subject I take up separately in a companion piece on being the chairman rather than the judge. But the single load-bearing guard is this one, and it's portable: a convened panel without a real kill-path isn't a decision process, it's a ratification process wearing one.

The trust test

Pull the four cases together — chess search, retrieval, agents, decision panels — and they're one loop with one missing part. In each, something must choose from a candidate list. In each, the failure mode is the same: with no scored option for "none of these," the current position never gets to veto a bad action, and the system produces confident output that quietly biases toward doing something.

Which gives you a single test you can run against any system that offers you an answer, human or machine:

Was its disconfirmation ever genuinely on the table? A system's "yes" is only worth something if it was structurally capable of saying "no" — and does, sometimes. Trust the one that could have gone against you.

This is the deep version of the rule, and it's the one I've written about elsewhere as the tell that separates a witness from a flatterer: a retrieval or provenance system you can trust is one that will also come back with nothing, and say so cleanly, rather than confabulating into the gap.⁵ The willingness to disconfirm and the willingness to report absence are the same virtue wearing two hats. An assistant that has never once told you your idea is bad is not being agreeable. It's missing its stand-pat — and its approval, however confident, is worth exactly nothing, because it was never capable of the alternative.

So the next time you build or buy a system that chooses — an agent, a search, a scoring model, a panel of AI advisors — ask the one-line question that would have saved me a tournament in 2003: is "do nothing" a scored candidate, and does it ever win? If the answer is no, you don't have a decisive system. You have a compelled one. And it will sack its queen for a pawn while the score stays perfectly, dangerously calm.