The world's smallest chess arbiter to enforce every official rule.

A complete, tournament-grade chess arbiter fits into a single JavaScript file of 1,527 bytes. As a single playable HTML file it comes to 1.7–2.7 KB (KB is a unit of file size; 1 KB = 1024 bytes), depending on what the interface offers and whether the HTML follows old or modern conventions. FideLite is an engineering exercise in packing the most function into the least space, written the code-golf way — carving away every byte of filler without changing what the program does. Golfstack is what I call that way of working.

In the main builds, two people play each other on the same device. The engine never suggests a move; it arbitrates the game, and it needs no external library to do so.

There are no shortcuts on the rules side. You can see how each article is handled, one by one, on the “Rules and their application” tab. The claim procedure for the 50-move rule and threefold repetition, and the offer–acceptance–lapse cycle of a draw by agreement, work as the handbook describes: a claim can be made on the move about to be played, an offer lapses once the opponent moves without accepting it, and checkmate takes precedence over every automatic draw. When a player resigns or runs out of time in a position where the opponent cannot mate, the result follows the test that 5.1.2 and 6.9 set out. Most major platforms take shortcuts on these articles.

The real claim is not any one of these items but the ratio itself: function per byte. The whole rule set sits in a single file — hard as diamond, dense as a black hole. It is also a reflection of my ego, as a craftsman and as an artist. ;)

The engine was tested thousands of times during development, edge cases included, and every known bug was fixed. Even so, I am always open to hardening it further, within my own principles: if you spot a way to shave off one more byte — or, more worryingly, a bug, a crash or a wrong ruling — write to cuneytinan37@gmail.com.

Not one game but an exhibition. The repository holds 36 files you can play straight in the browser, and the variety runs along three axes: in the rules, from a legality-only build to a full FIDE arbiter; in the interface, from a clickable board to UCI notation and blindfold builds that draw no board at all; and among the special builds, all the way to bots, more polished interfaces and builds that mirror the rules of Lichess and Chess.com. The variety takes its cue from the Ship of Theseus: it is there so that the line between full chess and something less can be argued over and thought about. That is also why I call the generator that adds and removes rules on the fly Chesseus!

Each build runs in its own frame, and the clocks only start ticking once you start the game. Switching builds ends the current game.

Pick a rule level first, then a build. In each level the first build, default, is that level's main file. L3 is the full arbiter: the rule layer is identical in all of its builds; what changes is how you enter a move, how the board is drawn and which indicators are shown. L1 and L2 are the lower rule levels; both are outside the claim. special is a layer of its own: builds that fit none of these levels, most of them derived from them, some at odds with the project's own principles. The details are in the Special builds section at the end of the Builds tab. nonbrowser in L1, L2 and L3 is a terminal build: it does not run in a browser, so it cannot be played here, but you can view its code, or download it and run it with node.

Code golf is the art of writing a program in as few bytes as possible without giving up any of its functionality, its rules or its logical correctness. There is one constraint: the behaviour stays the same, the size shrinks.

From beginning to end this project chased a single question:

The answer is below. But to ask the question at all, I first had to decide what counts as “complete”.

Writing the engine, I found myself in the middle of the Ship of Theseus paradox: what can you strip out of a game of chess and still be left with chess?

An unavoidable question of identity surfaces here. I did not take medieval chess as my starting point — in that game the bishop leaps exactly two squares diagonally, the queen's ancestor moves one square diagonally, and neither castling nor the pawn's double step is yet established. The two share a name, but they are fundamentally different games; taking the older one as the baseline would have meant answering the question for another game.

What I took as the starting point was this: today's piece movement (without castling), check, checkmate and stalemate, the pawn's single-square advance, and automatic promotion to a queen. That is the core left once everything removable has been removed. Take away one more article and the game stops being chess.

With the core in hand, there was only one direction left: adding.

The engine was not built in one go; it grew in overlapping rounds.

Underpromotion came first: the pawn was no longer condemned to become a queen, and the knight, bishop and rook became options too. Then the pawn's double step, and with it en passant, which has to come along — the two are inseparable, because the second closes the loophole the first opens. Then castling. At that point, everything on the board was chess as we play it today.

After that I moved off the board. In theory the move counter keeps a game from running forever, in practice the clock does; both entered the engine at this stage.

Normally I would have stopped there. But having come this far I wanted to finish the rest of the rulebook: repetition, insufficient material, draw offers and draw claims, flag fall, resignation. That also brought in the rulings that arise not from moves on the board but from the players and the clock.

The path was far from a straight line. Again and again I had to go back after noticing that a rule I had already added did not match FIDE exactly, or behaved wrongly in a particular position. Sometimes a new discovery forced me to scrap the whole solution I had written up to that point. Every reversal meant a structural rewrite followed by another round of byte optimisation; the code grew, then shrank again.

It was a long and instructive process, on both the coding and the chess-logic side. The turning points I ran into along the way — which rule broke what, which discovery forced a rewrite of what — are set out on the Technical detail tab.

Asked how he made his sculptures, Michelangelo is famously said to have answered:

That is what I did in Golfstack. The rules were a given from the outset; the work was carving away everything superfluous in the code that expressed them.

The name for where that carving ends is Kolmogorov complexity: the length of the shortest program that can produce a given object. Code golf is precisely a walk toward that bound — and the bound is provably uncomputable, so no one can tell you in advance where to stop. You find your way by measuring. The added constraint here is that the carving has to be lossless: drop a single article from the logic the rules require, and what remains is not a smaller chess but a lesser one.

The answer to the question is therefore a single number: 1,527 bytes. engine.js arbitrates an official game between two human players from the first move to the last; bundled with a front end into a single playable file, it comes to between 1,715 and 2,744 bytes, depending on the interface and on whether the HTML follows old or modern conventions.

One of the first questions that comes up is this: why the browser, why JavaScript?

The first half of the answer is about reach. Measured by how many devices, operating systems and environments it opens on, the browser wins by a wide margin. No compiler, no runtime to install, no package manager; double-clicking the downloaded file is enough. On top of that, HTML gives you the visual layer almost for free: the board, the clocks and the indicators need no separate UI framework, and the file opens even if <html>, <head> and <body> are omitted entirely. If the engine had any further to go to reach a player, the size claim would mean nothing in practice.

The second half is about the language itself. JavaScript suits Golfstack far better than you might expect: it needs no variable-declaration keyword, imposes no boilerplate of entry point and imports, and implicit type coercion means the board's numeric encoding never forces an explicit cast. Arrow functions, the ternary operator and the comma operator together let an entire function collapse into a single expression with no braces and no return. JavaScript also lends itself naturally to self-extracting packers; the engine's packed build relies directly on that.

The obvious objection: the browser weighs hundreds of megabytes and supplies both the JavaScript engine and the runtime. Isn't 1,527 bytes just a sleight of hand, then?

There is no such thing as a zero baseline. Written in C it would need libc and an operating system; written in assembly, an instruction set and a machine. A measure that also counts the runtime has nowhere to stop; measured that way, no size claim could be made in any language. Code golf therefore always draws the line in the same place: the code you write and the libraries you pull in count; the environment and the baseline do not. Neither the browser, the operating system nor the processor counts toward the total. Cross-language comparisons use this measure, and record attempts are open to any language.

Those who take the end user's view and want a stricter measure have a point too: same environment, same language, zero libraries. Both are legitimate, and a single file passes both — no library downloaded, bundled in or added.

The “smallest in the world” claim rests on both measures. I have searched for quite a while and have not found anything smaller that enforces every official rule, in JavaScript or any other language. The claim is falsifiable, and it should be: it falls the moment someone ships something smaller. Until then it stands.

The second question is harder: there are builds with a bot right here on this page, so why does the claim leave them out entirely?

The usual route is well known: draw a board, set up the pieces, and let the player take on a bot that plays a little better than random; most attempts so far have followed that path. The code-golf world has chess bots squeezed into a few hundred bytes, but to make room they give up almost every rule that forms the backbone of the game — castling, en passant, the 50-move rule, threefold repetition. Bot logic bloats the code considerably; a two-player build is far cheaper on the byte budget. And adding a bot contributes nothing to FIDE compliance.

The real issue is measurability. What counts as a bot is vague: is a sub-100-byte program that plays random legal moves a bot? Is one that counts material a bot, or is the bar higher? Who decides? Rules are not like that; they are exact. Whether a piece of code implements an article can be verified by inspection, with no room for argument. Even where coverage falls short, the measure stays exact: every draw the engine declares is a real one (soundness), while some real draws are missed (completeness) — and the misses come to roughly one game in 2.2 million in real-world play; a missed draw can change the result only at a flag fall or a resignation. For a few articles, pushing coverage to 100% is hard, but even that is a precise target whose gain per byte can be calculated; a bot has no such definition. I did try writing a bot along the way; then I put all my energy into the side that can be measured.

The two are kept apart in the code as well, and that is by design. The engine core knows nothing about the driver, so layering a search on top of it, or intertwining the two, does not break rule equivalence. That is exactly how the bot builds on this engine came about: the same rules, minus the clock and the player-to-player interactions, with a search on top. I do not consider that side finished: before a bot can be included in the claim, it has to clear the same bar the arbiter did — it has to be a masterpiece in its ratio of quality to bytes. That is a longer job, but since it is a hobby I enjoy a great deal, I will make a serious attempt at a record on that side too.

Here is what the measurable side has bought: on the hard half of the draw, this engine is far ahead of the major platforms. I will go on record here — even the strictest of them stop at the material test (is there enough left on the board to mate with?) rather than follow the rulebook to the letter. Looking at the position itself — whether a mate can still be constructed once the flag has fallen, and detecting blocked positions — is rare. And this has been measured: Miguel Ambrona's CHA-Solver found 204,060 wrongly decided games in the Lichess open database, and this engine rules more than 98% of them correctly. Some platforms make deliberate choices, such as Chess.com's blend of FIDE and USCF; the choice here is a different one: one rulebook, one standard.

Code-golf chess projects usually cut corners on the 50-move rule, threefold repetition and insufficient material — often on castling and en passant too — and focus on the bare core alone. I went where hardly anyone goes, and I think that is exactly where the project's originality comes from. As far as I know, no arbiter engine anywhere fits the whole FIDE rulebook into fewer bytes than FideLite — and it carries a blocked-position detector I have not come across on any major platform.

It is not a commercial product and does not pretend to be. But layering every rule of chess this way and fitting them into as few bytes as possible is pure engineering — pushing the limits on the code side.

I had substantial help getting here from AI models such as Claude and Gemini. Those tools dramatically compressed work that would normally take months: debugging, code optimisation, untangling browser quirks. The decisions stayed mine; what I gained was speed.

In a letter to his brother, Chekhov called brevity the sister of talent. In this project I tried to reduce the vast world of chess to its shortest form without losing any of its function.

This tab is about the book itself: what each article says, how I read it, and where that reading is contested. There is no code here; for how the engine does any of this, see the “The engine itself” tab.

What sits under each article instead is a test: a position, the correct ruling, and the wrong answer a system gives when it applies the article superficially. Reading a rule is one thing; applying it correctly in every position is another, and only a position shows the gap.

The rule sections (1–7) use the same parts in the same order, though not every part appears in every section: what the book says, how an algorithm reads it, where relevant what FideLite does, and what it costs to apply. Section 8 compares FIDE with USCF and the platforms; section 9 describes the hybrid I propose; section 10 looks at the rules that change not the game but its frame.

Article numbers follow the FIDE Laws of Chess that took effect on 1 January 2023 — FIDE Handbook ↗️.

For a movement to count as a legal move, four conditions must all hold:

Together these four define a legal move, and the rest of the book leans on that one definition from beginning to end. Checkmate, stalemate, dead position, flag fall — every one of them speaks of a “legal move” or a “series of legal moves”. Shift the definition and every article that rests on it shifts with it.

The book puts two different things into two different sub-articles here, and the distinction matters more than it first appears. 3.8.2.1, the right is lost: if the king has moved, or that rook has moved, the right is gone and never returns. 3.8.2.2, castling is prevented temporarily: if the square the king stands on, crosses, or lands on is attacked, or if a piece stands between king and rook, castling cannot be played right now — but the right itself stays.

If a pawn advances two squares on its first move and lands beside an opposing pawn, the opposing pawn may capture it as though it had moved only one square: it moves diagonally onto the square that was skipped, and the pawn that advanced two squares is removed from the board. The right lasts only for the very next move. If it is not used on that move, it is gone for good — it does not come back a move later.

En passant is not a separate rule but a patch on another one. The pawn’s two-square first move was introduced to speed up the opening; but it also let a pawn slip past a square an opposing pawn was covering. En passant closes exactly that hole: a pawn that has just moved two squares may be captured as though it had moved one.

The consequence: the queen is not always the best choice. A game that promotes automatically to a queen is a simpler game, and I think more is lost than people assume. Underpromotion creates a game in which no piece on the board is unconditionally superior; a good part of the game’s depth comes from exactly that.

Castling and the double step create nothing new on the board: the squares king and rook reach by castling, and the square a pawn reaches in two steps, can all be reached by ordinary moves. What they add is tempo: they speed the game up, and as a side effect lend it some beauty in particular cases. Underpromotion is different. It multiplies the branches at every promotion by four, and as promotions accumulate the space of the game grows exponentially. That is why, to my mind, it is the most important addition to the rules after the piece moves and legality themselves. I say addition because for a long time promotion went one way only: in medieval chess a pawn could become nothing but the fers, the queen's ancestor.

A piece can give check in three ways:

A double check is given by a single move: a piece steps off a line, opens the ray behind it — a discovered check — and gives check itself. Promotion and en passant are special cases of this pattern. En passant has one more privilege: since it empties two squares at once, it can open two rays together; then both checks come from the opened rays and the pawn itself gives none.

Castling can give check too, but only with the rook. The squares it empties lie on the first rank, the edge of the board, and any ray it could open along that rank is blocked by the castling rook itself. So castling cannot open a ray towards the king and cannot give double check.

Only a ray can be opened, so in every double check at least one of the checks comes from a ray. Neither a knight's leap nor a pawn's one-step check can be opened: two knights, two pawns, or a knight and a pawn cannot give check at the same time.

The piece standing in front of the opened ray cannot belong to that ray's family; if it did, it would already have been giving check along that ray before the move. Only a rook, a knight, a pawn or a king can stand in front of a diagonal ray; only a bishop, a knight, a pawn or a king in front of a straight one.

Three results follow:

A move by one player is a ply; a move by each side is a full move.

The whole weight of repetition sits in that phrase. The book spells out two cases explicitly, and measures them differently:

• 9.2.3.1 — en passant: measured by legality (availability). If a pawn could have been captured en passant at the start of the sequence and can no longer be, the positions are not the same. What is measured is whether the right is usable.
• 9.2.3.2 — castling: measured by right. Castling rights are lost only when the king or the rook moves. That castling happens to be unplayable right now — a piece in the way, a square attacked — does not change the position.

For en passant and for castling, the repetition count can use three different measures — the trace of the right, pseudo-legal (geometrically possible, with king safety not yet checked) and legal — and each one sorts the same boards into a different set of positions. The top row of the table is the measure that tells positions apart the most, the bottom row the one that tells them apart the least; the more positions are told apart, the later a repetition arrives.

FIDE measures the two rights on two different rows: it counts en passant as availability and castling as a right, and says so plainly in 9.2.3.1 and 9.2.3.2. At first glance it looks inconsistent — both seem tied to the question “can it be played right now” — and the point is not undisputed. The book's reasoning is the distinction between losing a right and temporary prevention that we met in section 2: en passant has no temporary prevention — the right either exists or it does not, and one move later it is permanently gone — while for castling the two are separate things, and the book counts only the permanent one. The widely accepted view points the same way: counting castling as a right is both cheaper and more precise in telling positions apart. The distinction has already had a price in a real game: in Karpov–Miles, 1986, Karpov claimed a threefold repetition on his 26th move; it was shown that in the position after his 22nd move Black still held castling rights, and the claim was ruled invalid. Under the rules then in force, Karpov was penalised five minutes on his clock; Miles thought for a while and then agreed to a draw anyway, because an incorrect claim is also a draw offer. The difference was invisible on the board.

Implementations write the en passant square in different ways. In all of them the capture itself passes the legality filter in the end, so the difference never shows on the board — only in the repetition count. In its simplest form the square is written after every two-square pawn advance — which is how classic FEN writes it too. As notation that is correct; used as a repetition key (a position's identity for the repetition count: the board, the side to move, the castling rights and the en passant square) it is plainly wrong and at odds with the definition of a repeated position. En passant is a special move, and writing the square after every double step is not precise enough for rule correctness. The definition asks that the en passant possibilities of two positions be the same, yet when a capture that cannot be played is recorded, the possibility exists on paper but not on the board: one position is counted as two, and the square no longer marks a real difference between positions. Some platforms, Chess.com among them, read the article differently and count repetition by the pseudo-legal measure. The generally accepted FIDE-compliant reading, which Lichess follows too, is to count the square only if the capture is legal.

The two automatic limits in this section — 75 moves and fivefold repetition — can each keep a game from running forever on its own; each rests on a different kind of finiteness.

For the counter the reason is this: a pawn move and a capture cannot be undone. A pawn does not go back, a captured piece does not return. Each can happen only a finite number of times in a game — there are only so many pawns and pieces. And those two are the only things that reset the counter. So once both are exhausted the counter climbs without interruption and ends the game by itself at 150 plies. The book ties the counter to these two alone; in section 9 I argue that two more events of the same class, the loss of a castling right and the lapse of an en passant right, should reset it as well.

Repetition rests instead on the position space being finite: where the pieces stand, the side to move, the castling rights and the en passant square give only finitely many combinations, so a game that never ends must sooner or later come back to some position a fifth time.

So even without dead-position detection, one of the two limits is certain to end a dead position; not even two sides trying to drag the game out as long as possible can stop it. In theory the 75-move counter is by far the earlier of the two: in k7/8/8/1p2p2p/1P2P2P/8/8/K7 w - - 0 1 the kings are shut into their own three ranks; the 576 placements make 1,152 positions once the side to move is counted, and the longest sequence in which none of them comes a fifth time runs to 4,608 plies, while the counter fills at 150. In practice, though, positions where repetition cuts in much earlier are common: being blocked makes mobility collapse and brings the same position back quickly — in the bishop example of section 6 fivefold repetition arrives on ply 16.

Dead-position detection, on the other hand, is a rule that ends the game early, not one that makes sure it ends: it never comes into play in a position that is not dead, so on its own it guarantees no finiteness, but it recognises a dead one on the first move.

Read backwards, the same reasoning says how few rules it takes to guarantee finiteness. Legality, checkmate, stalemate and one of these two limits are enough: a game that enforces them cannot run forever; it is simply not possible. One is enough; the two are not needed together, and the dead position is not needed for finiteness at all. It is there to end the game correctly, not to make sure it ends.

The distinction is visible directly in the levels: each level adds new rulings that end the game. The barest level has neither the counter nor a repetition count, so finiteness is not guaranteed there — with only the two kings left on the board, the game never ends. The guarantee comes with the automatic limits: the 75-move rule and fivefold repetition are each enough on their own. Dead position and repetition, for their part, are sensible, practical rules that speed the game along: they often deliver the result without waiting for 150 plies. Each draws on a different kind of certainty: the dead position on geometric certainty — the board itself says mate will not come; repetition on certainty of intent — returning to the same position a third time shows that no one means to make progress, and the player may claim; at the fifth, no one needs to be asked. In casual games and official tournaments alike, the time these rules save the players is invaluable. What the top level adds — clock, resignation, claims, offers — is a separate dimension: the rules not of the board but of human interaction, and without them there is no tournament chess.

A move that resets the ply counter (a pawn move or a capture) and the loss of a castling right both prune the repetition table from that moment on: none of the positions before it can ever arise again. A pawn does not go back and a captured piece does not return; and since a castling right is part of what defines a position, positions that held the right cannot come back once it is lost. Everything the table holds up to that point is now dead data for certain.

Where this pruning really pays is in engines that search. A bot checks for repetition at every node of its search, millions of times a second; scanning the history only back to the last irreversible move is raw speed there. In an arbiter the check runs once per ply, and since the positions sit in a hash table (a structure that reaches an entry directly by its key), a lookup takes constant time however large the table grows.

How large it can grow has a hard ceiling too: because the 75-move rule applies automatically, a game can last at most 17,697 plies — 8,848.5 moves ↗️. That is the concrete number behind the finiteness argument above; the table can never hold more positions than that.

Over the board, what stands behind these counters is the players' own record. FIDE requires each player to record their own moves and their opponent's, move after move and legibly, in algebraic notation (8.1.1): by hand on the paper scoresheet or on a FIDE-certified electronic scoresheet. It is the only notation system FIDE recognises (Appendix C ↗️); computer chess knows it as SAN (Standard Algebraic Notation), the form that writes Nf3, exd5, O-O. Piece letters may follow the player's own language — a Turkish scoresheet writes A, F, K, V, Ş — while SAN fixes the English ones. The record is what a claim stands on. Whether fifty moves have passed, how many times a position has occurred — the player can work both out only from the scoresheet; keeping any other notes is forbidden (11.3.1). The rule is strict. Writing a move down before playing it is forbidden too; one of the exceptions is the claim under 9.2 or 9.3 (8.1.2): the claim is made by writing the move on the scoresheet, and the arbiter checks it against the scoresheet. There the record is evidence, because over the board both an illegal move and an incorrect claim are possible, and the penalty for each is decided from it (7.5, 9.5).

Digitally none of that load remains. An illegal move is impossible, so it carries no penalty; an incorrect claim is checked on the spot and costs nobody anything. With the record no longer needed as evidence, what is left are the two numbers the player had to work out of it: the ply counter and the repetition count.

That arithmetic should be automated: both numbers should stay current on screen after every move. The counter should count plies, not full moves; I think that is the right choice. Because a claim can also be made on the move about to be played, knowing which ply fills the limit is critical: in full moves a “49” on screen could mean 98 plies or 99, and the player could not tell whether their next move completes the fifty. Precision has to reach down to the single ply. How many times the position has occurred should be reported continuously in the same way, so the player does not learn afterwards that a right has arisen but sees it coming. I think that is more consistent than approaches that announce a right only once it exists, by lighting up a button: the book recognises a claim on the move about to be played as well, while a button sees only the move already made.

I think this is also the most sensible way to bring systems based on FIDE, or even on USCF, into digital play. Where an illegal move is impossible and an incorrect claim costs nothing, counters that give the numbers automatically are fully consistent with the adaptations above: once the record carries no burden, neither should the arithmetic done from it.

Given the ban on notes, could this be called a breach of FIDE? If it were, the engine would be in breach from the very start: it allows only legal moves, never applies the penalty of 7.5, and checks a claim on the spot instead of against a scoresheet. The articles on recording, notes and penalties are rules of the table, not of the game; they exist to produce evidence and keep play honest, and digitally the platform does that job itself. FIDE's own online regulations ↗️ point the same way: the playing zone accepts only legal moves, and every move and clock time is recorded automatically and shown to both players (3.1.2, 3.1.6). The ban on notes holds there too (9.6), but a record the platform shows to both sides is not a note, and the counters are a summary of that record.

It would be good for this to become standard across platforms. A player who holds a right should not have to count back through the move list to be able to use it.

Alongside its over-the-board Laws, FIDE has a set of online regulations ↗️, written for official online events and for hybrid events, where players sit together under an arbiter's supervision but play on screens. They take over the rules of movement (Articles 1–3) unchanged; the differences are few, and almost all of them sit on the interface side.

The playing zone accepts only legal moves, and so does FideLite. Automatic recording of moves and clock times, premoves and automatic promotion to a queen are settings of the player or the interface, not rules. The project's claim is about the engine's rule correctness, not the comfort of the interface.

The real difference is in claims. The regulations declare threefold repetition and the 50-move rule drawn automatically, without waiting for anyone to claim (5.4). It is as if both players had an automatic claim switched on against each other; the aim is simplicity. At heart this too is a driver choice: a driver that makes the claim on the player's behalf the moment a threshold is reached gives the same behaviour without touching the engine. Some of the builds already do this. The Chess.com equivalent, like the platform itself, always ends the game on its own at threefold repetition and at fifty moves. Chess LUX, built on the FideLite engine and flexible in every setting, offers it as an option.

The only difference that reaches the engine itself is resignation. Under the regulations a player who resigns always loses (5.2); over the board, since 2023, a resignation is a draw if the opponent cannot mate by any series of legal moves (5.1.2).

The article says this: when a position arises in which neither player can checkmate the opponent’s king by any series of legal moves, the game is drawn. Such a position is called dead.

Three points are worth making at the outset, because the whole article turns on them.

Each branch can be brought about by different moves, and that is what tells an algorithm when to look at which branch:

The table below looks at both sides’ material at once and asks: is mate possible on this board at all? It should not be confused with the table in the next section, which looks at one side only and belongs to a different article; the link between the two is drawn at the end of that section.

For a dead position the pieces are counted without regard to side, across the whole board, and in that count knights and bishops are not weighed on the same scale. With knights the number decides: with a single knight on the board the position is dead; a second knight, whichever side it joins, brings it back to life. Bishops are different. If every bishop on the board stands on one colour, the position is dead however many there are and whoever holds them. Each new bishop of that colour leaves the ruling unchanged; the position stops being dead only when a bishop of the other colour, or any piece other than a bishop, arrives.

This is no coincidence but a necessity that follows from the geometry of chess.

A bishop never changes colour. A diagonal step changes both the file and the rank by one, so the colour of the square never changes. A bishop that comes from promotion stays on the colour of its promotion square. Everything a dark-squared bishop does happens on dark squares: the squares it attacks, the squares it stands on and the squares where it blocks other pieces are all dark. For it, the light squares might as well not exist.

The escape square always stays open. With nothing on the board but the kings and dark-squared bishops, a king in check always stands on a dark square, and its orthogonal neighbours are light. No bishop of either side can attack those squares or stand on them; only the opposing king can cover them. It cannot manage this even in the most favourable case, with the king to be mated in the corner: a king in the corner has two light neighbours, and to cover both at once the opposing king would have to step onto a square next to the king being mated. On the edge there are three such neighbours, in the middle four. So neither side can mate. Neither the number of bishops nor the side they belong to enters any step of this proof.

The condition is permanent. With no pawns on the board no new kind of piece can appear, and captures only remove bishops. A bishop of the other colour can never enter the board. Once the condition has arisen it never breaks, and 5.2.2's question of “any series of legal moves” is answered at a glance, without looking ahead.

The knight has no such invariant: it changes colour with every step, and two knights, whether on the same side or on opposite sides, make a mating position constructible. With knights it is the number that decides; with bishops, the colour.

The correctness of a dead-position algorithm splits into two separate questions, known in logic as soundness and completeness:

The two do not weigh the same: soundness is not negotiable, while completeness is a target that gets measured. An error can go in one direction only: a dead position may be missed, but a position that is not dead is never called dead.

Why this direction. The two errors are not equal. On a miss the game carries on, the moves repeat and one of the two counters brings the draw in the end; the result only arrives late. A miss turns into a wrong result in one case only, the game being cut short before the counters fill: a flag falls or a player resigns, and the side entitled to a draw loses. A serious error, but confined to one game. A false positive ends the game; no rule takes back a draw once declared. So an impossibility that cannot be proved does not count as a draw: when in doubt, the answer is “not dead”.

Soundness can be proved. Each of the three branches rests on a proof when it says “dead”. In the material branch the proof is the table itself. In a lock, each condition of the pattern rules out one kind of move that could break it; when all the conditions hold at once, no such move is left. In forced arrival the proof is the exhausted tree: every line has run into an end before any mate.

Completeness can be proved only for insufficient material. The material table is closed: it catches every position whose material is insufficient, and all of those are dead. But sufficient material does not show that a position is alive; with sufficient material a position may be dead or it may not. That is decided not by the number of pieces but by their structure: a lock, or a forced line.

So the real question of completeness for a dead position lies in the structure. For the lock, a proof of completeness would require a brute-force scan of every legal position with two to thirty-two pieces; no such scan has been done yet. In forced arrival, completeness depends on the budget; a limited budget leaves some lines unfinished. An algorithm that claimed to catch every dead position would therefore be claiming too much. Even so, almost every dead position that arises in practice can be caught, and the miss rate can be measured.

Scope: reachable boards. The algorithms for structure and forced arrival are written for boards that can be reached by legal moves in a game that starts with 32 men, from the standard setup or from one of the Chess960 setups. At least some of the boards that can never arise in a game can be recognised by arithmetic alone, and they are eliminated at the outset: every piece beyond the starting complement comes from a promotion, and every promotion costs a pawn; the extra rooks, knights, bishops and queens together cannot outnumber the missing pawns. Bishops are counted by colour as well: a side can hold at most nine bishops of one colour, the original one and eight promotions. Boards beyond that are outside the algorithms' scope; since they never arise in a game, they never come before an arbiter either.

Mate can be impossible with material to spare. The pawns have locked each other, none can advance, nothing can be captured; even with both sides cooperating no mating position can be built. The article covers this too, because it speaks of “any series of legal moves” — it does not count pieces.

A lock is an invariant. A blocked position is recognised not by trying continuations one by one but by a pattern read off the board. Once the pattern is in place, no legal move can break it; and since none can, it is in place in the next position too, and in the one after that. This induction, move by move, is what lets a single position settle the whole future of the game.

What is sought is not a winner but a lock breaker. If, even with both sides cooperating, no path leads either to an irreversible move (a capture or a pawn move, promotion included) or to a mate, the position is dead. Only reversible moves remain, and they shuttle without ever reaching mate. So the algorithm does not ask who wins; it looks for a move that would break the lock, or for a mate.

On a board within the scope, a locking pattern meets five conditions at once. Each follows naturally from the principle above: break one, and a breaker is born.

Three examples show how the conditions look on the board. The plainest consists of nothing but kings and pawns:

Put two bishops on a similar lock: the ruling does not change — the position is still dead, because the bishops are confined to their own halves as well and nothing can be captured.

Where these conditions come from. Some follow necessarily from the geometry of the board: the promotion arithmetic, a pawn changing file. The rest are places where the algorithm deliberately stays cautious, such as counting a knight, rook or queen that can move as a breaker; the twelve-pawn board shows what that caution costs. Ignoring king safety, the turn and pins does the same job: it gives the sides more freedom than they really have. More freedom means more breakers, and more breakers mean “not locked”; if caution makes the algorithm err, it errs in the safe direction. Almost every lock met in real games fits these patterns.

When the scan should run follows from the rule too. A lock can only be born through an irreversible move: a capture or a pawn move. A quiet move — a king or a sliding piece changing square — cannot build a lock, because it can be played back: if a lock appears after it, the lock was already there in the previous position. A capture and a pawn move both reset the ply counter; that is the moment to scan.

The loss of a castling right does not create a lock. In the repetition count it is an irreversible event, because it changes the position's identity; but a lock looks not at the castling right but at the geometry of castling. If castling could ever be played, the rook does not count as buried and there is no lock in the first place. If it never can, losing the right changes nothing on the board.

The rule has two exceptions. The first is mate: the move that creates the lock may give mate at the same time.

The second is en passant. A double step may well have created the lock, but it may also create an en passant right, and while that right stands the position cannot be called dead. Run the scan at that instant and it must answer “not locked”; and since no further irreversible move will come, it never runs again and the position is missed for good. The position to scan is the one after the right has lapsed, one ply later. The rule fits in four lines:

Sometimes the lock is not yet in place on the board. A queen that is bound to be captured, a pawn with no other move left, or a counter about to fill brings it about a few moves later, or ends the game without mate before that. Such positions are dead too, but recognising them means looking ahead; they belong to the third branch.

Mate can be impossible even when the material is sufficient and nothing is locked. The article asks not about the pieces on the board but about any series of legal moves, and in some positions every series flows to the same place: the moves are forced, or the choices change nothing. Wherever the line goes, it arrives at an end without mate. The board as it stands is misleading; the ruling follows from what it is forced to become.

What is sought is still a mate, only further ahead. The algorithm assumes the two sides cooperate and looks at every series of legal moves in front of it. If even one series reaches mate, the position is not dead. If every series runs into an end before any mate, it is dead. There are five ends: the first two branches, stalemate, a ply counter that fills, and the fivefold repetition. The forced line usually carries the board into one of the first two branches; this branch is those two seen from a few moves away. If the move that fills the counter gives mate, the result is mate.

The tree is searched on a budget. The counter and repetition make the tree finite in theory, but can leave it too large to exhaust in practice. So the algorithm works with a budget: if it has exhausted the tree within the budget, the ruling is “dead”; if not, “not dead”, the answer in the safe direction. A narrow line of forced moves, or of a few choices, runs out in a handful of tries; as the choices multiply the budget no longer suffices, and misses begin.

Here too neither side may be able to mate; positions where the forced line is mateless for one side only belong to 6.9 and to the next section. The five forms below are one example of each end.

In all three the line is forced, only the destination changes; and in all three someone looking at the board can reach the right answer. The remaining two arrive at the book's automatic limits instead: one depends on the ply counter, the other on repetition. That is, not on the board but on its history.

Here something has to be said plainly: the algorithm that recognises a dead position is one of the hardest in chess programming — to my mind, the hardest. Checkmate, stalemate, repetition, the counters — each has a closed definition: checkmate and stalemate follow from move generation, which can be tested with perft (the standard correctness test that counts every move sequence from a position); repetition and the counters can be verified exactly against test positions and reference implementations. The dead position has a clear definition too, but there is no defined method that proves it in every position. Even someone claiming to have solved the article completely could not prove it: the proof would mean testing every legal position with two to thirty-two pieces, about 4.8×10⁴⁴ of them, one by one; there is no computer to finish that, nor a corpus or an authority to certify it.

So the strongest thing an implementation can say is “close to 100%”; the number of games it misses is measured, not proved — the measurement is in the next section. The one thing that can be certain is the direction: every position called dead must really be dead, and one that is not recognised must be played on.

These two articles follow the same pattern. The player who resigns or runs out of time loses — unless the opponent is in no position to checkmate that player’s king by any series of legal moves, in which case the game is drawn.

For flag fall the exception has been in the book a long time. For resignation it was added in 2023: the earlier text said the player who resigns loses, full stop. In the same position, a player who resigned in 2022 lost; one who resigns from 2023 onward gets a draw.

Resignation, moreover, is not tied to the turn. Unlike an offer or a claim, a player may resign at any moment, even while the opponent's clock is running (5.1.2).

Nor should the opening clause of 6.9 be overlooked: the article does not apply at all where one of 5.1.1, 5.1.2, 5.2.1, 5.2.2 or 5.2.3 applies. Checkmate, resignation, stalemate, dead position and draw by agreement all take precedence over flag fall. That is why mate beats the flag: mate ends the game on the spot, and a flag that falls afterwards changes nothing.

no leeway digitally The fine point is when mate and flag coincide. The book grounds it in its definition of a move: a move is completed when the player presses the clock, but a move that ends the game — mate, for instance — counts as completed the instant it is made, without the clock being pressed (6.2.1.1). So the question between mate and flag is whether the mate reached the board before the flag fell. Over the board, if the mating move lands just as time runs out and it is unclear which came first, the benefit of the doubt usually goes to the side delivering mate. The reason for that leeway is human: placing the move on the board and pressing the clock both take time, and seeing the flag is a matter of eyesight. The uncertainty comes from those constraints, and the room for interpretation over the board exists to settle it. Digitally none of those constraints exist. The line is sharp, the flag can fall at any instant, and which event truly came first is decided by the algorithm: mate triggers on the board and the flag on the clock, on two separate layers, and the one to be taken as correct is the one that triggered first. Digital play is therefore where this article is least open to interpretation.

Anyone porting an arbiter algorithm into an online application should also mind the turn: offers and claims should stay tied to it, resignation should not.

The first question is answered by counting: is mate possible at all with the pieces the opponent holds? The table below gives the answer case by case. It differs from the table in section five in this: there both sides were counted together, here it is the mating side that is counted — and the defender’s material enters only because it can help.

Mate with a lone knight can only be built if the defending side owns a piece that can block its own king's escape: a bishop, a knight, a pawn, even a rook. A defending queen cannot do the job, because from every square where it could close the escape in the corner it simultaneously attacks the mating knight. A defending pawn suffices in two ways. On the a- or h-file it can close the cornered king's escape square itself, even before promotion. On any other file it promotes: since the article allows any series of legal moves, the pawn can turn into the piece that does the shutting in. What was said about the pawn holds for mate with a lone bishop too.

These are positions that can be constructed, not results that can be forced. None of them is a winning method; they are only the answer to “does mate exist at all with this material” — and that is exactly what 6.9 and 5.1.2 ask.

According to the table, K+B cannot build a mate against K+Q or against K+R. The result of section 5 holds here too: a second bishop of the same colour, whoever holds it, does not change these rows; the defender's piece answers every check either by stepping in between or by taking the checking bishop.

Counting pieces settles only half the question, and the cheap half at that. Your opponent may have a queen on the board — a system that looks at the position statically says “sufficient” and stops there. But the article does not ask about the pieces on the board; it asks about any series of legal moves. And in some positions all those series come down to a single line: there is no other move.

The typical case: your opponent has given check with a queen, your only legal move is to capture it — and your time runs out before you can. The queen is visible on the board; yet no series of moves leads to your being mated, because the one line along which the game can continue passes through that queen being taken. The correct ruling is a draw.

In practice this plain shape is what usually comes up, and the search closes such a line in a single try. A threefold repetition that was about to be claimed does not help here: it needs a claim, so it does not end the line; only fivefold repetition and the 75-move rule end it on their own. If the forced line leads somewhere mateless for both sides, the position is already dead (5.2.2). If it is mateless for one side only, the ruling becomes asymmetric; those cases are below.

The difference fits in one sentence: counting pieces looks at the board at the moment the flag fell; the book asks what that board is forced to become. Over the board the problem barely exists; the arbiter is already looking ahead. The unfair rulings accumulate on the servers.

Because 6.9 asks about one side only, the ruling can be asymmetric: on the same board mate may be possible for one side only, and whose flag fell decides the result. 5.2.2 does not work this way; there the question is asked for both sides at once and there is one answer. Counting pieces cannot show this; what the board can become has to be examined. Two examples, one from a forced line and one from a locked structure.

When it comes to building a mate, the table in the cheap half comes down to three rules:

Take the intersection of these one-sided rules, the combinations where neither side can build a mate against the other, and out comes the dead-position material table of section five: a bare king against a bare king, a lone knight or bishops all of one colour; bishops of one colour against bishops of that same colour. In every other combination at least one side can build a mate. The material branch of 5.2.2 is 6.9's question asked of both sides at once.

for implementers Mateability is not one question but two: can White mate Black, and can Black mate White? For every position the two possibilities can be worked out separately. Like castling rights, they are two small pieces of information the position carries, and like them they can only be lost: if no series of moves from a position leads to mate, none from any later position can either. A possibility once lost never comes back for the rest of the game. The direction is the same here too: a possibility counts as standing until it is proved lost.

When a flag falls (6.9) or a player resigns (5.1.2), only the opponent's possibility decides the ruling: if it stands, a loss; if it is lost, a draw. Three consequences follow:

The two possibilities can be updated as soon as each move is played. Then nothing is left to do at a flag fall or a resignation: the ruling is ready and only has to be read. The cost is lower than it sounds, because what has already been worked out lightens the load:

So not every move needs a full check for both sides. The work falls only on the moves that can actually change a possibility, which is kind to both the budget and the processor.

Which road to take is a matter of preference and priorities: keep the possibilities up to date throughout the game, or leave the look-ahead search to a flag fall or a resignation and run it then, one-sided, once.

Every dead position is, in fact, a draw that would arrive on its own. With no mate possible, one of the two limits that keep the game from going on for ever ends it sooner or later; in some positions a forced stalemate ends it earlier still. 5.2.2 simply declares that inevitable end without waiting for it.

A second conclusion follows: a search with enough budget would find them all by itself. A search that walks every series of legal moves ahead of it to those ends would recognise every dead position without needing a material table or a locking pattern, and would answer 6.9's one-sided question the same way. Since the same two limits make the tree finite, this is possible in theory. But exhausting that tree, even for a single position, can take far longer than any player would wait; and 5.2.2 wants a ruling after every move, 6.9 and 5.1.2 the moment the game is cut short.

So the branches of 5.2.2 and the material table of 6.9 are not redundant; they are short circuits of that search. Each closes part of the tree without walking it line by line:

These short circuits are a property of the problem itself, not of any piece of software. Whatever the language, whatever the engine, an arbiter that wants to apply the rule in reasonable time has to resort to short circuits of this kind. Each answers the same question — does any series of legal moves reach mate — by a cheaper road; none of them changes the question.

The book ties a claim to a move: either you state the move you are about to play and claim, or you claim when the position has arisen and it is your turn. Over the board that window is as wide as your thinking time — comfortably wide.

Claiming on your own turn, for a threshold already met on the board, is no problem. The friction begins when the right will arise from the move you are about to make. The book solves that by letting you state the move in advance and claim. Digitally, if the move does not carry that information within it and no automatic trigger is switched on, the player has to play the move first — but the instant it is played the turn passes to the opponent, and the right is now theirs. The opponent can reset the counter with a capture or a pawn move, or change the position; with a premove (a move entered before one's turn and played automatically the instant it arrives) this happens within milliseconds. The right is gone before the player could claim it, and not by the player's choice. No rule is broken — a right not claimed lapses anyway — but a right that over the board is used by stating the move becomes unusable in practice on screen. This is not particular to one site; it holds on every platform that does not let a claim be attached to a move, and premoves only make it worse.

The design consequence is plain: the claim channel has to travel with the move itself — either the move carries the claim within it, or the right is triggered automatically. Leave it to a separate button and the window closes again.

The book links the claim to the offer: every claim under 9.2 or 9.3 is also an offer of a draw (9.1.2.3). A claim that does not hold is not wasted; it stays before the opponent as an offer, and if the opponent accepts, the game is drawn. The offer's own rules run parallel to the claim's:

An offer made at any other time still counts, but distracting the opponent falls under 11.5 — so an offer while the opponent is thinking is not the path the book lays out. On the platforms offers are not confined to that window at all: an offer can be sent at any moment, and when repeated it turns into a device for interrupting the opponent's thinking. That is exactly the behaviour the book means to keep out by tying the offer to the turn.

Resignation lies outside this condition: the book does not tie resigning to the turn; the detail is in section 6.

Move rules, how the pieces travel, checkmate and stalemate are identical in both federations. The divergence begins off the board — at the clock, at resignation, at the draw claim. The two books govern the same game but part ways where the player, the clock and the arbiter step in.

When a flag falls both books ask the same question — can the opponent mate this player — but they read “can” differently. Both look at the position and both need a search; where they part is in what the search is looking for.

Searching for a forced mate is lighter than it sounds. A forced mate either exists or it does not; there is no need to write a depth or a threshold into the rule. In these classes the attacking side holds one or two minor pieces, so a single saving reply by the defender is enough to close a whole branch, and the tree stays very small. If a mate exists it is short — in practice no more than about five moves. The theoretical bound can be longer, but today's machines find that too without strain.

The two books also draw the line in different places. USCF, for instance, is the more generous to the player out of time: with the player out of time down to a bare king and two knights on the other side, FIDE awards the win, because a helpmate can be built, and USCF the draw, because the mate cannot be forced.

In the table below, “win” means a win for the side whose clock is still running.

On a digital platform, applying either book as it stands does not always give the best outcome. USCF leaves 75 moves and fivefold repetition to the director's discretion, so on a server with no one to make that call, a game can keep going with no fixed point at which it ends. Under FIDE, the 50-move and threefold claims can turn a won technical endgame into a draw over a single slip.

The hybrid below combines what looks fairest in each book. It is a proposal: FideLite itself applies FIDE, and everything else on this tab is written to that book. But where the two books part and the question stays contested, these are the limits I find most reasonable and fair. Which article comes from which book is stated openly in the table; that is also where it differs from the blend Chess.com applies on some articles. These limits vary from federation to federation, even from tournament to tournament; they are not the core or the body of chess. One proposal does touch the body directly: what should reset the counter. That is a deeper change to a rule itself, and I argue it under its own heading.

One note on the implementation side: the helpmate search (6.9) does not have to wait for the flag. It can run in the background in every minor-piece position, so the result is ready when the flag falls and the players never wait for it.

9.3 and 9.6.2 tie the counter to two events only: the movement of a pawn and a capture. What the two share is that neither can be undone, and that is where the counter's whole meaning comes from. But the book's own logic reaches further than its letter. Two more events belong to the same class: the loss of a castling right and the lapse of an en passant right. Neither comes back, and the book itself makes both part of a position's identity in 9.2.3. I think the counter should reset on all four. This is not a reading but a change to the rule: if a rook move costs a castling right while the counter stands at 140, FIDE ends the game in a draw ten plies later, while under this counter play goes on.

The en passant lapse rarely makes a difference in practice: the right is born only of a double step, which has already reset the counter, so when it lapses the counter simply resets one ply later. The gap is small, but counting it keeps the rule exact. The right is counted here by the measure of 9.2.3.1: if the capture is not genuinely legal, there is no right to lapse.

The reason I think about it this finely is that three rules then fit together. A counter defined this way means “plies since the last irreversible event”, and all three rules meet on one signal: the 75-move rule counts it; fivefold repetition need only look inside that window, because nothing before it can recur; and the blocked-position scan runs at the moment it resets. The two-part condition of section 5 — the counter was reset and there is no en passant square, or the right has just lapsed — collapses into one: the counter was reset and there is no en passant square. A lock that a double step hides for one ply is caught the moment the right lapses, because that moment is a reset too. Finiteness survives: there are four castling rights and at most sixteen en passant rights, so the longest game grows by at most a few hundred plies.

The first nine sections were about the standard game. This one looks at rules that change not the game itself but its frame. The book gives some of them after the main articles, in its appendices and guidelines, and leaves others to the regulations of an event. What they share is that the rules on the board stay as they are; what changes is everything around them.

In 777, the position shown, c-side and g-side castling take two different forms. In c-side castling the king does not leave c1; the rook on b1 passes over it to d1, and only the bishop on d1 has to move out of the way. In g-side castling both pieces move: the king four squares, from c1 to g1, and the rook from g1 to f1; for that, d1, e1 and f1 all have to be clear.

Castling can no longer be written as a two-square king move. In standard chess castling can be encoded as the king moving two squares sideways (e1g1); no other king move covers two squares, so nothing is ambiguous. In Chess960 the king travels anywhere from zero to five squares: a king that stays put has the same source and target square, and a king that moves one square makes a castling move indistinguishable from an ordinary king step. The common solution in engines is to write castling as the king capturing its own rook: in UCI's Chess960 mode, c-side castling in the position shown is c1b1 and g-side castling is c1g1. Source and target always differ, and since no legal king move can land on a square held by its own piece, the ambiguity disappears.

The castling right has to know its rook by file. FEN's KQkq field assumes the rooks stand on the a- and h-files. In Chess960 the right also has to say which rook it belongs to: Shredder-FEN always uses the rook's file letter (GBgb for the position shown); X-FEN keeps KQkq to mean the outermost rook on that side and switches to the file letter only when the castling rook is not the outermost one. That is why the position shown can be written in X-FEN as qrkbbnrn/pppppppp/8/8/8/8/PPPPPPPP/QRKBBNRN w KQkq - 0 1.

Legality is the same questions, generalised. Castling still checks the four conditions of section 2: the right still stands, the path is clear, the king is not in check right now, and the squares it crosses and lands on are not attacked. Standard code asks them over fixed squares (f1 and g1 on the g-side); in Chess960 the same questions are asked over ranges set by the starting files of king and rook. Because castling looks only at the files of the king and the two rooks, the 960 positions reduce to 56 skeletons as far as castling is concerned; all of them are in the Chess960_Skeletons simulation.

no digital counterpart Over the board the book settles the same ambiguity through the order in which the pieces are handled: the king is first lifted off the board and set beside its destination, then the rook is placed, and only then is the king put down; saying “I am about to castle” beforehand is recommended too. On a screen, the encoding of the move does that job.

The book does not fix the time: it defines how time is allotted and leaves the numbers to the regulations of an event, which must state them in advance (6.3.1). A time control is set by three things: the time, the extra time per move, and how many periods the time is split into.

Three kinds. One sum gives the kind: time + 60 × the extra time, as if the game lasted 60 moves. At 10 minutes or less the game is blitz (Appendix B), under 60 it is rapid (Appendix A), and at 60 or more it is classical, standard chess in the book's words. “3 + 2” means 3 minutes and 2 seconds per move.

The clock is a small state machine. It needs each side's remaining time, the mode, the period table and the move number. At every press the time used is deducted, the mode's extra is applied, and if the move number has reached the period's boundary, the next period's time is added.

Increment before the move, or after? The book gives it before; many online clocks add it after the move. Once the move is over the remaining time is the same; the difference is inside the move: an increment given beforehand can be spent on that very move, so within each move the flag falls one increment later.

Bronstein and simple delay. What 6.3.2 describes is the mode clock makers call simple delay: the main time is frozen for the length of the delay. Under Bronstein the time runs from the start, and after the move the time used is refunded up to the delay. On most moves the result is the same; the difference shows in time trouble: under simple delay a player can spend the whole delay on top of the main time in that move, while under Bronstein the flag falls the moment the main time runs out. Since the glossary uses both names for one mode, software that offers the two separately has to define the difference itself.

An offer is not silent the way a claim is. A correct claim is verified and settled by the system itself, with nothing asked of the opponent; only a claim that fails reaches them, as an offer. An offer takes effect only if the opponent sees it and decides: every offer is a signal landing on the opponent's screen, and repeated, a tool that breaks their thinking (section 7). That is why platforms and apps may limit offers by rules of their own: keeping them closed before a given move, tying them to a period (once every ten moves, say), or refusing a new one for a while after one has been declined. Each is a single comparison against the move number, and an offer that comes from a failed claim goes through the same checks.

At the top level chess drifts towards the draw: as long as neither side errs, the result mostly stays level. Armageddon exists to overturn that balance for good; it is the final game, played when a result must be reached. At super-GM level starting with White is already a serious advantage in itself, and yet in a short blitz game White is also given noticeably more time. In return, Black counts a draw as a win. White has to win; Black need only avoid losing.

Armageddon is not in the book; it is defined in tie-break and event regulations. Its general shape:

The builds vary along three separate axes, and it helps to keep them apart.

The interface axis. The rules stay the same while the interface changes: the clickable board, its pared-down form, numeric input, UCI, blindfold, the string board, the terminal. All interfaces of a level give the same rulings; only the way a move is entered, the board is drawn and the clock is shown changes. Every level has this axis: eleven interfaces in L3, seven each in L2 and L1.

The rules axis. The interface stays the same while the rule layer changes: L3 → L2 → L1. L3 is the full arbiter and the claim itself. L2 and L1 sit outside the claim, but they are the clearest way to see how the rules build up layer by layer.

The bot axis. What is measured here is neither the interface nor the rules but the search placed on top of the rules: L1_1250elo, L2_aybars_2500, and ToledosOpponentbyMe, written as an opponent for Toledo's program. They form a group of their own within the special builds.

Anything that fits none of the axes is among the special builds. The packed form of L3 is part of the claim, even though it uses deprecated methods.

Eleven builds, one set of rules. Each implements castling, en passant, choice of promotion piece, stalemate, dead position, threefold and fivefold repetition, the 50- and 75-move rules, draw by agreement, claims, flag fall and resignation in full, and each produces the same fifteen result codes.

L3_packed (2,423 bytes) is the default build packed with RegPack; it is a core part of the claim, on a par with L3. Packing here is not compression but a self-extracting wrapper: when the file opens, the original source is rebuilt and the game behaves identically. It gets there with deprecated methods, though: with is a syntax error in strict mode, and eval is blocked by any content security policy that does not allow unsafe-eval. Browsers warn about both, and in some modes the file does not open at all. It also contains invisible control characters, so it works when shared as a file, not when its code is copied and pasted. In the player, L3_packed is the last build of the L3 level. The other builds stay as plain source, because packing does not pay off in every build.

All builds with a clock measure time the same way; they differ only in how it is shown. default and light round the remaining time up, so 0:00 appears only once the flag has actually fallen. The other builds that show seconds truncate instead, so the figure on screen can be up to a second lower than the real time. The clicking builds are therefore slightly more precise on screen, but rule correctness is unaffected: in every build the flag falls on the unrounded time, and the display is never off by a full second.

There are fifteen ways a game can end: six decisive, nine drawn. The engine names them in two encodings: the numerical builds and engine.js return an integer, every other build a two-letter abbreviation. Each cell below shows both.

This is my periodic table :) As with the elements, each code takes its meaning, and its relation to the others, from the row and column it sits in, and sometimes from the letter it starts or ends with!

The abbreviations are self-explanatory: those beginning with W are wins for White, those beginning with B wins for Black. Those beginning with D, those ending in M, and any code containing a digit are draws. All fifteen codes follow these patterns.

The rows carry meaning too: the first concerns mate and stalemate, the second flag fall, the third resignation. The fourth row holds the draws that happen automatically, the fifth those that need a player's request. Where each row comes from, and which takes precedence when two coincide, is shown in the pipeline of endings.

One naming choice is worth explaining. DP is named after the article rather than the specific case: 5.2.2 covers dead positions caused by insufficient material and blocked ones alike, and the engine reports both (measured coverage on the blocked side is 93%). Naming the code after the narrower half would have been easier; naming it after the article left the door open, so when blocked positions were added they came under the same code, and the list stayed at fifteen.

These fifteen codes follow FIDE; another federation's rules would produce a different list. Under USCF, for instance, there is no RM outcome, 75 and 5R are not automatic (the tournament director may declare them but need not), and TM works quite differently. The engine could be adapted to USCF.

This section covers how the L3 builds are played. L1 and L2 play the same way, only more simply; the few small differences are in the levels section. Gameplay really changes only in the special builds, which have their own section.

Everything is done by clicking: first the piece, then the destination square. When a pawn reaches the last rank, a picker opens, and the move is not complete until a piece is chosen; the clock keeps running in the meantime.

The draw radio button works independently of the move. If your opponent has offered a draw, selecting it accepts and the game is drawn by agreement — even when a claim threshold is also met, because every claim is an offer as well. With no offer pending, if a claim threshold is already met on the board, selecting it ends the game in a draw at once. Otherwise it stays selected and is evaluated when you make your move: as a claim if the move reaches the threshold, as an offer to your opponent if it does not. Making your move also declines your opponent's pending offer.

Eight builds use the same format: the three prompt builds (prompt, prompt_string_a1, prompt_string), prompt_blindfold, input, input_blindfold, nonbrowser and nonbrowser_blindfold.

The format is <from><to><promotion><draw>. It is case-insensitive: E2E4, e2e4 and e2E4 are the same move.

The promotion letter is r, b or n. Any other letter, q included, or no letter at all gives a queen, so e7e8 is enough. The engine takes care of the colour; you only choose the piece type.

Castling is entered as the king's move: e1g1 and e1c1 for White, e8g8 and e8c8 for Black. There is no king-takes-rook form. En passant is entered with the square the pawn actually lands on, so it needs no special notation.

To ask for a draw, append = to the move. b2b3= means: if this move reaches a claim threshold, I claim the draw; if not, I offer one to my opponent. The engine decides by looking at the position after the move; if the move resets the counter or produces a position not seen before, no claim can succeed and the request stands as an offer. A request with a move does not accept a pending offer: the offer lapses the moment the move is played. = on its own accepts a pending offer if there is one; otherwise it claims a draw in the current position, or offers one if the claim does not hold.

To resign, type r. In prompt, cancelling the dialog also resigns; pressing Enter on an empty line does not — it counts as an illegal move, and the clock keeps running. In nonbrowser, closing the input (Ctrl+D on Unix) resigns; an empty Enter is an illegal move there too.

If a move delivers mate, a trailing = is ignored: checkmate takes precedence over the claim, just as it does over every automatic draw.

The same layout, with squares as two-digit numbers: the first digit is the rank, the second the file, both counted from 0 to 7. That is the engine's own index written in hexadecimal: a1 = 00, h8 = 77. The driver only shifts the first digit four bits and joins it to the second; there is no other conversion.

Promotion is chosen with a digit: 0 bishop, 1 rook, 2 knight, 3 or anything else a queen. There are no letters anywhere in this build. Castling again uses the king's squares: White 0406 and 0402, Black 7476 and 7472.

There is no separate draw button; draw requests travel in the input itself. Any non-numeric input is a draw request. If the opponent has an offer pending, a request without a move accepts it. Otherwise, if the request matches a valid claim (threefold repetition or the 50-move rule), the game ends there; if not, it goes to the opponent as an offer. That gives four cases:

Attaching the request to a move is not a convenience but a requirement of the Laws. When “the counter stands at 99 plies, and this move makes it 100”, or “the position has occurred twice, and this move brings the third”, the claim rests on the move about to be played. That is why the request travels with the move, and the behaviour follows 9.2 and 9.3 exactly.

The fourth case has a side benefit. The clock in this build is not live; it is shown in the title of the prompt() dialog. Since numeric but illegal input reopens the dialog without triggering anything, it is also the only way to check the remaining time.

Resignation has its own channel: Cancel, Esc, an empty Enter and leaving the tab all resign. 0, 00 and a space do not — all three are numerically zero, so they are just illegal moves. Typing r does not resign either; it contains a letter, so it counts as a draw request.

The awkwardness of this interface is deliberate: the aim is to do everything the other builds do, given good-faith input, in the fewest bytes. It is the lowest rung at which the game can be played without breaking the engine.

Everything other than the move itself works differently from build to build. In default and light each has its own control; in the others, everything goes through the same input as the move.

The engine itself never reports the game state; what is shown is entirely up to the driver, and the indicators multiply as the byte budget grows. Six builds report the state in text: default, input, nonbrowser and the three prompt builds. light shows only the clocks and the draw radio; the three blindfold builds and numerical say almost nothing.

In the builds with indicators, the fields always appear in the same order. default's status line has the form a8-h8 C! M=0 R=1; input, nonbrowser and the prompt builds write the same fields above the board.

M= is the ply counter — the halfmove clock, in FEN and engine parlance. It resets on a capture and on a pawn move. At M=100 the 50-move draw can be claimed; at M=150 it is declared without a claim. In practice: if you see M=99 on screen, the move you are about to play will reach the threshold as long as it is neither a capture nor a pawn move — which is exactly what b2b3= in UCI is for.

R= is the repetition count. This is how many times the current position has been seen. R=3 opens the threefold claim; R=5 is an automatic draw. It is not a countdown but a value recalculated after every move: it drops back to R=1 as soon as a new position appears.

Each number has two thresholds: one opens the claim, the other ends the game automatically. At levels without claims, only the second applies; the details are in the levels section.

C! means the side to move is in check — so on your turn it is always your own king. D? marks an open draw offer. In input, nonbrowser and the prompt builds the two share one slot, and D? takes precedence; default does not show D? at all. When the game ends, default replaces the whole status line with the result code, while input and nonbrowser write it into that slot only, leaving M= and R= in place. Of the blindfold builds, input_blindfold and nonbrowser_blindfold append the result to the end of their single line; the prompt builds, prompt_blindfold and numerical show it in an alert() window.

Playing the builds without indicators. In all four, keeping track of check, the counters and repetition is entirely up to you; the engine reminds you of nothing. All you have left are the last-move log and the clock, and both tell you more than you might think.

In the blindfold builds the draw suffix shows up in the log: if your opponent played e7e5=, it is logged as [e7e5=], so you can see that they offered or claimed a draw. The same goes for promotion: e7e8n is logged as [e7e8N], so you can check what they actually promoted to without holding the board in your head. The side to move is shown by the running clock in input_blindfold and by the arrow between the two clocks in prompt_blindfold; in nonbrowser_blindfold the clocks only update after a move, so the one that went down last tells you.

In numerical the log is the raw input itself, so an opponent's draw request shows up as non-numeric characters, whatever they are: 1434asd and 1434x are both the move e2e4 plus a request. A request without a move leaves no trace. The clock is two unlabelled millisecond counts — White on the left, Black on the right — and the one that is going down tells you who is to move.

light does not display the result; the board, the clocks and the draw radio already on screen are enough, and not a single extra mark was added for it. The clock tells a win from a draw beyond doubt. Which kind of win or draw it was, you work out yourself by following the game and ruling things out step by step. Since the board and the clocks turn with the side to move, “the side to move” means the side at the bottom when the game ends. Each clock is headed by the king of its own colour (♔ White, ♚ Black), so the king on the bottom clock tells you whose move it was.

For the last two rows, the elimination works like this. If the last move was a capture or a pawn move, the result is a dead position (DP): right after an irreversible move, neither a repetition nor the 75-move rule can occur. If the last move was reversible but let an en passant right from the previous move lapse, it can still be a dead position: a pawn's double step locked the board, and the lock is recognised only once the en passant right is gone. If the last move lost a castling right, the chain of repetitions is broken, so the result is the 75-move rule. If none of these applies, it is 5R or 75. In other words, you narrow it down by ruling out what cannot have happened rather than by spotting what did. For games ended with the radio: if the radio was already selected when your turn came, it was an agreement (DA); otherwise a claim (3R or 50).

Telling 3R from 50, or 5R from 75, is not always possible: both are counter thresholds and can be reached on the same move. For light's purposes this does not matter; what matters is knowing it is a draw. If you are curious, open the browser console with F12 and look at n (the ply counter: 100 for the 50-move rule, 150 for 75) and R (how many times the position has occurred: 3 for threefold, 5 for fivefold); in the player the build runs in a frame, so select that frame in the console.

On mate and stalemate the clock drops to zero at once. The clock of the side with no move left goes straight to 0; after mate it stops at 0:00, after stalemate it keeps running below zero. Mate takes precedence over every draw: even if the last move both mates and completes the 75th move, the result is mate.

The draw radio doubles as the offer indicator. If the radio is checked when your turn comes, your opponent has offered a draw: select it to accept, or make a move to decline. You can withdraw your own offer by clicking the radio again before you make your move.

Negative time is written as 0:-3 or -1:-14; since the clock rounds up, the display still reads 0:00 for a second or two after the flag falls before turning negative. There are no M= or R= counters; keeping track of them is up to the player, as in the builds without indicators.

The light builds of L1 and L2 have no clock; there the board is the only channel. If the side to move has no move, it is mate when its king is attacked and stalemate when not; in L2, a board that freezes while moves remain means a draw arising from the board, though which one is not shown.

All three are written without a DOCTYPE or <head> tags, so the page opens in quirks mode. Only the board is styled: square colour, square size and magnification (three times in L1–L2, twice in L3). In L3 the style element also centres the board and the text and enlarges the promotion buttons. The buttons, the radio and the text keep the browser's default look.

These are the two rungs of the rules axis below L3. Their interfaces are seven of L3's eleven — the clickable board, its pared-down form, numeric input, UCI, blindfold, the string board, the terminal; what changes is how far the rule layer goes.

The levels build on each other. L1 knows only playability: is the move legal, has the game ended in mate or stalemate? L2 adds the draws that arise from the board. L3 then steps off the board: the clock, resignation, offers, claims.

The four faint rows in the table are not rules but the machinery that supports them. They are not missing from L1, they are unnecessary: if repetition is not counted, there is no point keeping the table, nor in testing whether an en passant capture is genuinely legal — that test exists only to keep the repetition count correct, so without the count it is not needed. Castling rights depend on the same chain: with no repetition key, they need not be kept canonical. L1 marks the squares a move touches in a ledger, and castling needs the king's square and the rook's square never to have been touched. That chain is why L1 can stop at 1,404 bytes.

On the code side the difference is sharper still. L1 has four functions — G, T, U, L — and the verdict is not even a function of its own but inlined into the expression that applies the move. L2 adds C, the blocked-position detector and an inlined material test. A separate M, V, O, Z, D, F, A and the 6.9 search H come into being only in L3.

The builds of both levels side by side. The files are in builds/L1/ and builds/L2/; the last two columns give each level's size in bytes, so you can read the cost of the rule layer for each interface along its row.

Moving from L1 to L2 costs between 486 and 579 bytes for the same interface.

A packed implementation of the L1 rules, DOM_911, is among the special builds; when the game ends, the board turns a single colour.

Gameplay is as in L3; the differences come from the rules and can be read off the table above. With no player layer there is no clock, no resignation, no offer and no claim, so none of their controls or indicators either. Moves and promotions are entered the same way. With no clock to show, input_blindfold starts the line with the side to move: W or B. The only difference that does not come from the rules is in the two builds that use prompt().

The dialog never closes. In numerical and prompt_string, if Cancel, Esc, an empty Enter or switching tabs closes the dialog, the loop reopens it at once. No alert() appears when the game ends either; the result is written in the same dialog — in prompt_string into the check slot, in place of C!; in numerical in place of the last move, as a number. The dialog keeps coming back with the same screen, any move entered is ignored, and the game ends only when the tab is closed. This is deliberate. The same behaviour was wanted in L3 too, but there it broke the clock: with the dialog never closing, the clock froze — in a timed game, a breach of the rules. So in L3 closing the dialog counts as resignation, and the never-closing dialog stayed only in L1 and L2, which have no clock.

The builds/special/ folder holds the files that sit off the ladder, between its rungs or above it. A file ends up here for one of three reasons: its interface or rules branch off the ladder (LUX, which raises the ceiling above L3, the platform equivalents, ChessMiniature without the detector, chessinbytes under 1 KB); it measures something other than the interface or the rules, namely the bot axis; or it breaks the project's general principles, being written with deprecated methods that make the browser warn or fail. Most are projects in their own right: the files of six separate GitHub repositories live here as well, each linked to its own repository. None is part of the claim; they are kept for comparison and for the record.

Every game file can be opened in the player under the special level; each repository's README has the details.

Chess LUX is FideLite with a looser byte budget and higher rule accuracy. Its engine is engine_4x; the rules are those of L3, but it goes further in two places. The blocked-position detector takes in, beside kings, pawns and bishops, the knights, rooks and queens that are boxed in and can never move; the detector grows from 432 bytes to 961. The 6.9 search also runs on a far richer budget: 300 plies and 400,000 nodes instead of 9 plies and 2,000, and after every move a short dead-position search runs for both sides. Chess960 comes on top: the starting position is set up from its official number (0–959), and castling is done by moving the king onto its own rook.

The result is measurable. Of the 204,060 games CHA-Solver found wrongly decided on time, it gives the correct verdict in 204,058: 99.999%. It closes all but 2 of the 3,676 games FideLite misses: 3,663 with its lock scan, 11 with the search. Its lock scan recognises 52,146 games as locked — 4,011 more than FideLite's — and in that class coverage rises from 92.98% to 100%. The remaining 2 are not wrong verdicts but undetected draws: with no proof found, the win is awarded as a precaution, as in FideLite. The repository also contains a benchmark page for testing the engine on its own, and the CHA-Solver data.

The interface is closer to a real platform, too. The clock runs on performance.now, a monotonic timer that is unaffected if the system clock is moved back or forward. A FEN and a time control can be entered at the start; White and Black can be given different times, two further periods can be added, the board's orientation can be chosen, and threefold repetition and the 50-move rule can be made to apply without a claim. The FEN is checked for legality: one king of each colour, no pawn on the first or eighth rank, and the side not to move must not be in check; castling rights and an en passant square that disagree with the board are ignored, and invalid input does not start the game. The type of time control can be chosen: Fischer increment, Bronstein delay or simple delay, with sudden death when the increment is zero. FIDE 5.2.3 is applied too: no draw by agreement until both sides have made at least one move; the move from which offers are allowed can also be set (½ Offer, default 1). The draw radio turns green not only when the opponent has an open offer but also when a 50-move or threefold claim would be valid.

Dragging with the right mouse button marks squares with circles: every square along a straight or diagonal line, otherwise just the two end squares; right-clicking a single square marks only that one. A piece's legal destinations are marked in two ways, as in the Lichess and Chess.com equivalents: a dot in the middle of an empty square and a ring around a square holding an enemy piece. A king in check has its square highlighted in red, as in the equivalents. Captured pieces and the material balance are shown beside the clocks. The end-of-game indicators and the whole layout are roomier.

Armageddon. The Armageddon box in the start dialog turns the game into an Armageddon game:

1. A time difference is required. Ticking the box unticks ⚖ by itself and opens Black's time box; the first box becomes White's time. White must have more time than Black, for example 5 minutes for White and 4 for Black; if the times are equal, or White has less, the input counts as invalid and the game does not start. Unticking Armageddon brings ⚖ back.
2. No claims and no offers. Auto 3R/50 is ticked and locked: since a draw counts as a win for Black anyway, threefold repetition and the 50-move rule end the game without waiting for a claim. The ½ button is hidden as well; there is nothing left to offer.
3. A one-sided dead position. After every move the arbiter asks “can White still mate?”, and if not, the game ends with DP ⟹ BA. There is no separate code: the question DP asks for both sides in a normal game is asked in Armageddon only for White's chances of mate. The question is answered by the material test, the wider lock detector and a 9-ply search. The search rules mate impossible only when it has closed every line; if its budget runs out, the game plays on.
4. Flag and resignation. These work as under FIDE: the 6.9 search is asked as always, with 300 plies and 400,000 nodes. If the opponent can mate, the player whose flag falls or who resigns loses (WT, WR, BT, BR); if not, the result is TM or RM. In Armageddon TM and RM are wins for Black too, so White's flag or resignation is BA either way.
5. The score. The result line shows the score together with the code: W# ⟹ WA, 3R ⟹ BA. White's wins are the three codes beginning with W; every other code is Black's.

Armageddon usually has two periods: the second adds no time and only switches the increment on. For 2 seconds per move from move 61, leave the main increment at 0 and enter per2 # 60 +0 min +2 s. Armageddon works together with Chess960 and FEN too. How the rules work is explained in section 10 of the Rules tab.

An arbiter that applies Lichess's rules: 2,804 bytes with the clickable board, 1,088 in its numeric form without a board. The clicking build also plays like Lichess: the platform's colours, markers on reachable squares, the last move and a king in check highlighted, and promotion chosen on the board itself; the clock is 600 + 5 seconds, as in L3. The numeric form uses the L3_numerical interface and is packed.

The same idea with Chess.com's rules: 2,643 bytes with the clickable board, 1,050 in numeric form. The clicking build uses Chess.com's colours and markers; otherwise it plays like the Lichess equivalent. The numeric form again uses the L3_numerical interface and is packed.

Why the platforms apply the rules as they do is covered in the federations section; in short, the two equivalents differ as follows:

Both equivalents implement only the material branch of dead position, so to keep the mnemonic accurate their two-letter result code is IM (insufficient material) rather than DP. It is triggered by the same material test that reports DP in the main builds.

The bare-bones rules of chess, line by line. This repository was written as teaching material. Right-click the page and choose “View page source”: nearly every rule that arises from the board itself — move generation and king safety, castling, en passant, promotion, checkmate, stalemate, fivefold repetition, the 75-move rule and dead position recognised from material — can be read from start to finish in a single HTML file under two thousand bytes. The aim is to show intuitively how far chess can be simplified and how few characters its rules need; it was written in the hope that it can serve as material for software and algorithms courses.

A two-player chess arbiter in 1,893 bytes of one HTML file, and its twin in 1,815. Both enforce the same rules: the L2 level without the blocked-position detector, so a dead position is recognised from material alone, while fivefold repetition and the 75-move rule are declared without a claim. What separates them is how the board is stored — one in letters, as a FEN does, the other in numbers. Side by side, they show what the choice of representation costs: the letters cost 78 bytes. Neither is packed; the source can be read as it is. Gameplay is the same as in L2.

For readability the two builds are written in parallel: function and variable names are defined in the same order and the lines break at the same places, so the two files can be read side by side, line by line. That makes them far easier to read than the other builds, which are written on a single line. The blocked-position detector was left out on purpose: it is not a well-known algorithm, and it is hard to follow for someone who does not know chess. The remaining rules are found in practically every chess engine and are quick to grasp.

Since dead position is recognised from material alone, these two builds also report IM rather than DP.

Two-player chess in bytes: three builds, each a single HTML file under 1 KB; two are packed, and the smallest is plain source, because packing gains it nothing. All three enforce the same rules — full legality, castling with every condition, en passant, promotion to any piece. All three use the 0x88 rule code of L1; they differ in gameplay and indicators. There is no clock, no counter, no repetition, no material test, no offer and no result code; mate and stalemate are not told apart. The name reflects the byte budgets, which step down from the 911-byte main build through the 722-byte intermediate build to the smallest, at 650 bytes.

The third axis: a search placed on top of the rules. This section covers the bot builds of the two levels and the bot written as an opponent for Toledo's program. L1_1250elo and L2_aybars_2500 are played against the bot on the clickable board; the status line shows no coordinates. Aybars has its own repository: Aybars_ChessAI ↗️. There it is index.html; the repository also holds its Black-side twin, black.html, the strength measurement against Stockfish and an account of how the bot was built.

L1_1250elo runs on the same new board as L1, the 0x88 board, on the core of engine_4x; almost all of the first row's difference is the bot, and the remaining 35 bytes or so are the speed tweaks the rule core takes from engine_4x. L2_aybars_2500 still runs on the previous board representation, a flat 64-square array, while L2 has moved to the new board; the second row's last column therefore carries the difference between the two boards as well, not the bot alone. Nor are these two measurements of the same thing: the two levels carry different bots. As the 1250 and 2500 in their names suggest, the one in L1 is a light bot, while Aybars in L2 is a far stronger one whose search and evaluation go much further. Within each level the rules are the same with or without the bot, so the difference comes largely from the bot itself; the roughly ninefold gap between the two reflects the bots' strength, not the rules. The L2 bot build also ends the game on threefold repetition and 50 moves; that is inside the difference too, but only a small part of it.

The two level bots sit outside the claim, and that is a consequence of the design rather than a caveat. Had the bot been the priority, the board representation itself would have been written differently from the start: a flat, square-centric array makes “what is on this square?” cheap and set operations expensive, and a search tree wants exactly the reverse. The choice here was made in favour of rule density; the bot was added on top of it afterwards.

What made this possible is that the rule layer stands apart: since the engine core knows nothing about the driver, layering a search on top of it, or intertwining the two, does not break rule equivalence. The bot builds leave out the clock and the player-to-player interactions; the rules stay the same.

Oscar Toledo G.'s program and the bot written as its opponent are here to test one question: “could a more capable build — a stronger bot, a better interface — be written at the same rule level in about as many bytes as Toledo's?” These two have no repository of their own; they live in the builds/special/ folder of the FideLite repository.

Both were given one extra rule: the 50-move rule. After 100 plies without a capture or a pawn move, the game freezes silently, just as at mate and stalemate — no further move reaches the board and nothing is shown on screen. The point is to keep matches between the two bots from running forever or getting stuck in a loop. The counter is updated, and checked, only where a played move is written to the board; the search never looks at it, so neither bot's strength has changed.

ToledosOpponentbyMe uses the same search and evaluation as L1_1250elo; the differences:

The engine without a front end: pure state and functions — no DOM, no dependencies, no build step. One line, 1,527 bytes. The source below is the actual file from the builds/ directory, loaded when the page opens. Press a chip to highlight the parts of the source that belong to that concept; one concept is highlighted at a time, and pressing the same chip again clears it.

The With the simplest driver button at the top of the window opens L3_numerical in the same view: this engine plus the shortest driver that makes it playable, in a single 1,715-byte HTML file. The driver is a 283-byte loop. It reads a move from a prompt dialog as digits, two per square: rank first, then file, each from 0 to 7 — the square's hexadecimal index. So e2 is 14, e4 is 34, and 1.e4 is 1434. An optional fifth digit selects an underpromotion (0 bishop, 1 rook, 2 knight). The same dialog shows both clocks and the last move, and an alert reports the result code when the game ends. An empty input resigns; any non-numeric input accepts a pending offer, or else claims or offers a draw; and a non-digit typed after a move plays the move first — which drops a pending offer — and then claims or offers. In this view only the driver's code is highlighted, together with the own-piece check the driver adds to the engine.

The engine body is almost identical in the two files, with three differences. In the driver, L itself checks that the piece on the origin square belongs to the side to move (~b[i]&8^t&&), so O drops its colour filter (p&8^t||); and D, F and A do not exist as separate functions — their work is inlined in the loop.

The signature is in the header: b=[c=un=15,e=y=t=8,n=o=0] — read in order, the names it assigns spell c·un·e·y·t. Most of them have a job: c is the mask of the four castling rights (15), e the en passant square (8: none), t the side to move (8: White), and n and o the ply counter and the offer bits. Two are there only for the signature: un is never read, and y is never read by the engine — drivers use it to hold the last move or the chosen promotion piece. The signature costs five bytes: three for un=, two for y=.

The board is a flat array, but not a 64-element one: it uses the 0x88 layout. Each rank occupies 16 cells in the array; the first eight are real squares, the last eight an off-board gap. The index is 16 × rank + file, both counted from 0: a1 is 0, h1 7, a2 16, e4 52, h8 119. In hexadecimal, the two digits are the coordinates themselves — the high digit is the rank, the low digit the file: e4 is 0x34, h8 0x77. That is why the numeric drivers take each square of a move as two digits.

The array is 120 elements long: h8 sits at index 119, so the gap to the right of the last rank is never allocated. Of the 120 cells, 64 are squares and 56 are holes. The holes are never assigned: the array is sparse, and reading a hole returns undefined.

The layout is named after the classic off-board test: a 0x88 engine checks whether an index is on the board with i&0x88. An index that runs past the h-file sets the 0x08 bit; one that runs past the eighth rank, or below the first, sets the 0x80 bit. This engine never uses that mask. A hole holds undefined, and undefined fails every test the engine applies: in the ray walk b[i]<1 is false, so the walk stops; in the target filter b[x]+~t>>3 comes out 0, so the target is rejected. Indices before the start of the array or past its end read as undefined in the same way. The array methods (map, some, every, indexOf) skip the holes too, so every loop over the board visits only the 64 squares.

What the gap really buys is direction. The difference between two squares, d = f − i, is 16 × the rank difference + the file difference; since the file difference stays between −7 and 7, every pair of rank and file differences maps to a distinct value. In a 64-element array this does not hold: +7 can mean seven squares to the right on the same rank, or one up and one to the left. In 0x88 the difference alone identifies the line: a multiple of 15 is one diagonal, of 16 a file, of 17 the other diagonal; anything else lies either along the rank or on no line at all. The details are under Geometry.

The value of a square is the code of the piece on it: a number from 0 to 14 that fits in four bits. A four-bit unit is called a nibble (half a byte) and is written as a single hexadecimal digit: 0–9 as digits, 10–14 as the letters a–e. That is why the starting position can be written as a hex string — White's back rank is dcebaecd — with one character per square. The four bits fall into two parts:

The engine has a single expression for the sliding pieces: P+P*4%x&S(). x is the step size — 1 along a rank, 16 along a file, 15 and 17 along the two diagonals — and S() says whether the path is clear. The direction is filtered by the expression's lowest bit, that is, by its parity. On a straight line (x 1 or 16) P*4%x is always even, so the parity comes from P itself: the odd types, queen (3) and rook (5), pass. On a diagonal (x 15 or 17), 4P — 12, 20 or 24 for the three sliders — exceeds the modulus only for 5 and 6; the odd modulus is then subtracted once and the parity flips. The result comes out odd for 3 and 6 (queen, bishop) and even for 5 (rook). That lowest bit is ANDed with the result of S(): if the path is blocked, the move fails. No separate branch for the queen was ever written: it comes out odd in both cases.

Each of the three short-range pieces has its own branch in G, and G tells them apart by the type itself: P-4 zero means a knight, P-2 zero a king, P-1 zero a pawn; if none is zero, the piece is a slider.

The order of the codes is not arbitrary; each placement pays off as a shortcut somewhere in the engine. Making the pawn 1 means that in the pawn codes (1 and 9) both the 2 bit and the 4 bit are clear, while every other piece has at least one of them set. M's ply counter relies on this: if !b[x]*b[i]&6 is zero, either a piece was captured or a pawn moved, and the counter resets. Placing the sliders at 3, 5 and 6 is what the parity expression above requires. And the king at 2 and the knight at 4 serve V's material count: p%8>2 counts queen, knight and rook (3, 4, 5) with their weights and leaves king and pawn out, while p%8>5 has already sent the bishop (6) to a branch of its own.

The representation is square-centric: information is attached to the square, not to the piece. The opposite approach is piece-centric: in a bitboard engine the information is spread across one bit set per piece type, so “what is on this square?” becomes expensive while set operations become cheap. Here it is the other way round: a square query is a single array access, b[i], four characters. The one exception is V. For the blocked-position scan it turns pawns and kings into BigInt bitboards, because there the question is not “what is on this square?” but “how far can this set grow?” — exactly what set operations are for. Those bitboards are 64 bits wide: since map skips the holes, the bit order is not that of 0x88 but that of the plain board, 8 × rank + file.

A driver needs no chess knowledge: validate the click or the typed move with L, play it with A, then redraw the screen. The other four are for results and display: Z reports the endings that arise on the board, D and F those that a player claims or the clock brings about, and T drives the check indicator.

Throughout, a side is given by the colour bit of the piece code: 8 White, 0 Black, and t holds the same value. The clock is entirely the driver's business — the engine neither stores nor measures time; the driver decrements its own clock on each tick and calls F(side,0) when one reaches zero.

Three more things are worth knowing. The engine initialises itself: as soon as the file loads, the board, the side to move, the castling rights, the counters and the repetition table are in the starting position; there is no separate setup call.

There is no undo: A only moves forward. L copies the board for its own trial move and restores it, but does not expose this. A driver that wants undo must save b, e, n, t, c, k and R before the move; to undo, it first decrements the new position's repetition count (G[k]--) and then restores the saved values. Skip the decrement and a silent bug follows: the count added by the undone move stays in the table, the position is counted one time too many when the same move is played again, and R comes out higher than it should — a threefold claim becomes available too early.

There is no FEN and no PGN: the engine neither parses positions nor records moves. A driver that wants to start from a given position writes the board into b by 0x88 index, leaving the holes unassigned, and itself sets the side to move in t, the castling rights in c, the en passant square in e and the ply counter in n. It must also rebuild the repetition table for the new position: delete the old keys stored on G (for(K in G)delete G[K]; the function's own properties are not enumerable, so the loop sees only the position keys), then set R=G[k=b+e+t+c]=1. It must clear the offer bits as well (o=0). If they are left set, an offer from the previous game carries over into the new position, and a single offer from the other side ends the game as a draw by agreement (9). If the holes are filled — with 0, say — the off-board space turns into empty squares: sliders wrap from the end of one rank to the start of the next, and a rook on h1 can suddenly reach a2. Likewise, the en passant square is set only if a pawn on an adjacent file can actually make the capture; otherwise it is 8. M maintains e by the same rule; if the FEN's square is copied as is, the key differs from the one the engine would build, and a repetition of the position is counted one time too few.

Everything a driver reads to draw the screen is here; the last three belong to the 6.9 search. The clock is not in the engine: the driver keeps the time and calls F when a flag falls or a player resigns.

Six of them were introduced above. The other seven are internal machinery: a driver never needs to call them, but you need them to read the engine. They are listed in source order; each function calls only those defined before it, with two exceptions shown on the layer map. The Bytes column gives each function’s size — the quickest way to see where the byte budget goes.

The thirteen functions come to 1,391 bytes, that is 91.1% of the file. The remaining 136 go to the initial state and the separators between the parts: the signature header 25, the loop that fills the board 80, the first entry of the repetition table 16, and fifteen commas and semicolons 15.

The distribution is uneven, and telling. V alone is 405 bytes — about 27% of the file, and its longest function. Next come G (236), H (149) and U (134). So the most expensive parts of the engine are, in order, the static detection of an impossible mate (material and blocked pawn structures), piece geometry, the 6.9 search and making a move on the board. By group: geometry, attack and legality (C, G, T, L) take 370 bytes; making a move (U, M) 243; move iteration and search (O, H) 208; the verdict, claims, the clock and move application (Z, D, F, A) 165 together.

The file is made of sixteen parts: the signature header, the loop that fills the board, thirteen functions and the first entry of the repetition table. The first two are followed by semicolons and the rest are separated by commas, because the part that fills the board is not an expression but a for…in statement. The header alone creates eight names — b and, assigned inside the array, c, un, e, y, t, n, o — and the last part two more: R and k. The loop leaves j and s behind as globals too. Add three state names created inside a function — $, I and N, set up by F — and eight scratch globals. Every other letter is a function parameter, and so free for a driver to reuse. The state variables and the functions are in the tables above; the scratch values and parameters are below.

Seven letters never appear in the source at all: E, J, K, Y, l, w and z; drivers can use them without any risk of a clash. L3_numerical's loop does exactly that, storing the input in K, the destination square in Y, the time the clock was started in w and the result in z. The rest of the alphabet is taken — the clearest measure of how hard the byte budget has been squeezed.

The naming is not arbitrary. Most names are the initial of an English word. Among the functions, A apply, C castling, D draw, F flag, G geometry, H helpmate, L legal, M move, T threat, U update, V verdict; in the state, b board, c castling, e en passant, I insufficient material, k key, N node budget, o offer, R repetition, t turn; among the parameters, i initial, f final, d difference, p piece, r rook — and in the tables that letter is set in bold within the word it comes from. A few follow a different logic: n is the conventional counting letter; W and B are the white and black pawns; z and Z sit at the end of the alphabet because they hold the end of the game (z lives only in the drivers). O is an absence test: O(_=>0) asks whether no legal move is left. X comes from no word at all; it is a cross, that is, a “not”: the flag that says a move is not a promotion. And $ looks a little like #, the hash sign — and it really does hold a hash table.

Letter case follows a convention of its own: functions tend to be uppercase, state variables and parameters lowercase. It is a tendency rather than a rule — R is an uppercase counter, and W, B, S and X are uppercase scratch values — but the case of a letter usually tells you what kind of name you are looking at. And where both cases of a letter are in use, they often name the same idea at two levels: p the piece code and P its type, c the castling rights and C the function that yields them, s the step and S the ray walker that advances by it, z the stored result and Z the function that produces it. Inside V the convention switches to FEN's: S and s are the blocked white and black pawns, A and a the squares the white and black pawns can reach — uppercase for White, lowercase for Black.

Eight letters are global scratch variables, created inside a function. Six of them are meaningless once the call returns, and all six belong to V: W and B the bitboards of the white and black pawns; _ and f those of the white and black king, and in the saturation loop the squares each can reach; S the blocked white pawns; a the squares the black pawns can reach. The other two carry information from one function to another: r is the square of the castling rook — G's castling branch writes it, U reads it; X is the cross that says a move is not a promotion — U writes it, and H reads it to try the four pieces of a promotion one by one.

f and S are parameters in other functions: f is the destination in G, U and A, S the ray walker in G; and _ is a never-read parameter in three places. V writes these letters as globals. No collision arises, because the parameter shadows the global and the two are never live at the same time; but a driver that unknowingly uses one of these letters as a global of its own will be caught out.

The remaining letters are all function-local; a driver can safely use the same names as globals. The same goes for j and s: the loop that fills the board leaves both behind as globals — j as "63", s as the 64-character position string — but the engine never reads them as globals again. The Where column shows which functions each letter appears in; V's own alphabet follows separately below.

The table above does not include V, and for a reason: V has ten parameters of its own — two of them from a destructuring pattern — and eleven names counting its inner loop's parameter. Eight of them are letters used as globals elsewhere in the engine.

One of them stands out: H. Everywhere else in the engine H is the 6.9 search — the very function that calls V at every node; inside V it is a helper that spreads a bit set one file to the left and right. The others follow suit: c is not the castling rights but the mask that stops a shift from wrapping around the board edge; N is not the search budget but one step of a king; s is not the position string but first the side in question, then Black's blocked pawns in the loop; j is not the index of the loop that fills the board but the bit counter; o is not the offer bits but s's own material; A is not the function that applies a move but first a material tally, then the squares the white pawns can reach; and the loop's parameter n holds not the ply counter but the number of rounds left. Even the board scan runs inside the parameter list: the default value of [m,o] is the b.map(…) itself.

The shadowing here is not a design choice but a consequence of the byte budget: with only seven letters left free, V takes most of its names from letters already in use. Names created in the parameter list never leak: when the function returns, the globals are as they were. Six assignments are exceptions: W, B, _, f, S and a; all of them are explained under the saturation loop. Pitfalls covers where this becomes fragile.

What the letters mean is in the tables above. What follows is what those letters do, and in what order: which expression enforces which rule, which operator turns what into what, and which functions run in which order as a move is made on the board.

The order of the sixteen parts is not arbitrary — each function builds on the ones before it. The source looks forward in only one place: G calls T, which comes right after it. That is genuine mutual recursion: T calls G for every piece while G calls T in its castling branch. Every other call refers back: when you read a function, everything it calls has already appeared above it.

The sections below follow the layer map: from the bottom up, geometry, attack, legality, adjudication and application. In this engine the layer order and the order of declaration are the same; reading the source from left to right means climbing the layers from the bottom up.

The engine has five layers. At the bottom is pure geometry: can a piece go from this square to that one — without asking what stands on the target or whether the king is left in check (C, G)? Above it, attack: is a square attacked (T)? Then legality: the layer that actually makes the move, checks the king's safety and restores the board (U, L, M). Then adjudication: is the game over, and if so how; is mate still possible (V, O, H, Z)? At the top, application: three functions — A makes a move permanent and returns the verdict, D settles claims and offers, F handles flag fall and resignation. Losing castling rights, advancing the ply counter and switching the side to move are not their job but M's, down in the legality layer. A driver plays the game through this top layer; it reaches down only to validate a click with L and to mark check with T.

The dependencies run almost entirely one way. The rule is broken in two places:

• G → T. The geometry layer reaches up one layer for castling: it cannot decide whether castling is valid without asking whether the king is in check right now and whether the square it crosses is attacked. So G and T are mutually recursive — T calls G for every piece while G calls T in its castling branch. The recursion never runs away, because the G that T calls is in attack mode, and in attack mode the castling branch is never entered.
• M → L. M, which makes the move on the board, drops back into the legality layer while setting the en passant square: it keeps the square only if a pawn of the side now to move can legally make that capture.

There are also recursions within a single layer. G's ray walker S calls itself: a slider's path, the pawn's double step and, in castling, the path between king and rook are all tested by that walk. U calls itself once more in castling to move the rook. H calls itself down the search tree, and V's inner loop g calls itself through the rounds of saturation.

Two parts build the board, an expression and a loop:

The header is a declaration list. The first expression is an array literal whose elements are assignments: c=un=15, e=y=t=8, n=o=0. Evaluating the literal writes the whole initial state — t=8 puts White to move, c=15 grants all four castling rights, e=8 means no en passant square, n=o=0 zeroes the ply counter and the offer bits — and the resulting array [15,8,0] becomes b. The state variables and the board array thus share one pair of brackets; no separate b=[] is written. The three elements are only placeholders: the loop that follows writes a1, b1 and c1 to indices 0, 1 and 2, overwriting them. The clock is not in the engine; the driver keeps the time.

The position string. The template literal produces 64 characters: White's back rank dcebaecd, 40 digits in the middle, then Black's pawns 11111111 and Black's back rank 54632645. The middle 40 characters are not written out in the source but generated at run time by 10n**40n-10n**32n. The difference equals 10n**32n * (10n**8n - 1n): eight 9s (White's pawns) followed by thirty-two 0s (four empty ranks), exactly 40 digits. It has to be a BigInt: as an ordinary Number, the same value would lose its exact digits to floating-point rounding.

From the plain index to 0x88. for…in walks the string's indices, 0 to 63, though not as numbers but as the strings "0"–"63"; arithmetic turns them into numbers by itself. j is the plain board's index, 8 × rank + file; j*2-j%8 turns it into the 0x88 index: j*2 is 16 × rank + 2 × file, and subtracting the file once leaves 16 × rank + file. s[j] gives the character at that index. The cells that are never written — the eight to the right of each rank — remain unassigned; that is where the holes come from. An expression that split the string into characters with the spread operator and walked them with map would take 83 bytes; the loop takes 80. The price is two names: j and s stay behind as globals. And since the loop is a statement, it is set off from the parts before and after it by semicolons, not commas.

The trick in the value conversion is precedence: + and - have equal precedence and associate left to right, so '0x'+s[j] concatenates first — '0xd' for 'd' — and then -0 coerces that string to a number, whereupon JavaScript reads the 0x prefix as hexadecimal and yields 13. Written as +0 the concatenation would have continued and produced '0xd0'.

The last expression builds the repetition table with the starting position already counted once:

The key has four parts: the array converted to text — 120 cells, comma-separated; the holes become empty strings, so the eight holes after each rank show up as a run of commas — followed by the en passant square, the side to move and the castling mask, with no separator. The table is not a separate object but the function G itself; the keys become its properties.

The missing separator looks like a collision risk at first sight, and here a unique parse really is not guaranteed: after the last comma come h8's code (one or two digits), e (8 or 32–39 / 80–87, one or two digits), t (8 or 0) and c (0–15), run together. Enumerating every possible value finds a single family of collisions: a black pawn on h8 (1) with e on g3 (38), against a white rook on h8 (13) with no e (8) — both are written 138…. A chess rule rules that case out: a black pawn can never stand on h8, because black pawns start on the seventh rank and only move towards the first. Every other combination of values reads in only one way.

G(i,f,m) answers a single question: can the piece on square i reach square f as far as the geometry of the board is concerned? It ignores whether a friendly piece occupies the target and whether the move leaves the king in check. Both are left to the layers above. 236 bytes — the second-longest function in the file, after V.

The third argument m is attack mode. When it is set, three things change: castling is disabled (castling is not an attack), the pawn's diagonal square counts even when it is empty (the pawn attacks that square), and the pawn's direction is reversed, because the attacking pawn belongs not to the side to move but to its opponent. So G(j,x,1) means “does the enemy piece on j attack square x?”

Because default parameters are evaluated before the body and from left to right, G's header does the work of a let block without paying for the keyword. By the time the body starts running, the whole geometry has been derived:

The first thing to notice is that the piece's colour is never read: the type is derived in the header with P=b[i]&7, and the pawn's direction comes not from the piece's colour but from the side to move, t. This relies on L only ever being called for a piece of the side to move; reading the colour would cost bytes.

The rest is geometry that 0x88 provides. Three of the derived values deserve a closer look:

• d=f-i. The difference between the two squares. Since in 0x88 every combination of rank and file offsets has a difference of its own, this single number identifies the line; there is no need to compute rank and file distances separately.
• x: the step size. Three nested remainder tests: if the difference is divisible by 15, the line is one diagonal and the step is 15; by 16, a file and 16; by 17, the other diagonal and 17; otherwise the step is 1. That last case covers both the rank and every difference that lies on no line at all. s is the same step with its sign: no direction table, no offset array — three remainders and a sign.
• S. The ray walker. It advances i by s; if it has reached f it returns true, otherwise it calls itself again as long as the cell is empty (b[i]<1). It stops at a piece, and at a hole as well: undefined<1 is false. This single line checks that every square in between is empty. The pawn's double step and castling use the same walker.

A difference that lies on no line — from a1 to b3, say — gets a step of 1. For such a pair the walker runs along the rank and stops at the first hole without ever reaching f: in 0x88 every rank has a wall at either end. On a 64-square board, such geometries would have to be filtered out in advance by branch conditions; here the holes filter them. The same walls defuse broken inputs. Give the same square twice and d is zero, the step 15, and the walk ends at the first piece, the first hole or the end of the array. With no king on the board T asks about square -1, and again the walk ends outside the array. The answers are meaningless, but no walk ever runs forever.

The body is a single ternary chain. Each link subtracts a number from the type and looks for zero: P-4 zero means a knight, P-2 zero a king, P-1 zero a pawn. The final branch handles the remaining three pieces — queen, rook and bishop (3, 5, 6) — together.

Knight. d*d%765%128==68. In 0x88 the knight's eight moves come down to four differences: ±14, ±18, ±31, ±33. Squaring drops the sign (196, 324, 961, 1089); the remainder modulo 765 folds the larger two onto the smaller two (961 → 196, 1089 → 324); and the remainder modulo 128 brings 196 and 324 down to the same number, 68. Checking every difference that can occur between two squares on the board shows that only these eight give 68. One multiplication and two remainders instead of an eight-direction table. If the target is a hole, the knight's move still comes out “geometrically fine”, but L's target filter rejects holes anyway.

King. Two branches, split on ~m+3%d. ~m is −1 in normal mode and −2 in attack mode; 3%d is 1 only when the difference is ±2 (0 for ±1 or ±3, and 3 beyond that). The sum is zero only in normal mode and for a two-square move along the rank; only then is the castling branch entered, and in attack mode it never is. The other branch is d==s: does the difference equal a single step — is the move one square in any direction?

Every castling condition sits in a single chain. First the target is turned into the rook's square: f+=s-!~s — on the kingside s is 1, ~1 is −2, !−2 is false, so f moves by 1: from g1 one square on, to h1. On the queenside s is −1, ~−1 is 0, !0 is true, so f moves by −2: from c1 two squares back, to a1. The asymmetry is handled without a ternary. The rook's square is stored in the global r at the same time; U, which will move the rook, reads it from there. c&C(r) tests that the castling right tied to that rook is still set. T()+T(i+s)<S() asks the remaining three conditions in a single comparison. T() says whether the king is in check now, T(i+s) whether the square it crosses is attacked; T's default square is the king of the side to move, that is i. If both are false the sum is 0. On the right, S() walks from the king to the rook and checks that every square in between is empty; on the queenside b1 is included in that walk. If the path is clear it gives 1. The comparison holds only as 0 < 1. The expression is evaluated left to right, so S still runs after the attack tests — as it must, because it advances i as it walks. Whether the rook is actually there needs no separate test: M clears the right the moment the rook moves or is captured. The king's destination square is not tested here, because L's trial move already catches an attack on it.

Pawn. Direction first: m^d<d*t. With White to move t is 8, and d<8d holds only when d is positive — White must increase the index. With Black to move t is 0, and d<0 is simply “does the index decrease?”. Using the side's value as a multiplier fits both colours into one comparison. In attack mode m^ inverts the answer: the question is now about the opponent's pawn. If the direction is wrong the ternary returns 0 and neither branch is entered. Otherwise there are two branches, split on x-16: a move along the file is a push; anything else is a capture.

• Capture. 1&~x%d asks whether the move is exactly one diagonal step. ~x%d means (-x-1)%d; if the difference is a single step (±15 or ±17) the remainder is −1, which is odd; for two steps or more it is −16 or −18, and with a step of 1 it is 0 or −2 — always even. Then m|b[f]|f==e accepts any of three conditions: attack mode, a piece on the target (L's filter has already ensured that it is an enemy piece), or the target being the en passant square. Joining the three with or turns en passant into an ordinary capture without opening a branch for it.
• Push. Distance first: d/s<2+(i%96<24) — the number of steps must be below three on the starting rank and below two everywhere else: at most two squares from the starting rank, one square elsewhere. The comparison yields 1 or 0 as a number, and >b[f] sets it against the piece on the target: only when the target is empty (b[f] is 0) is 1 greater. One operator asks about both the distance and the empty target; on a hole b[f] is undefined and the comparison fails. S() does the rest: on a single step it reaches the target at once and returns true, on a double step it looks at the square in between first and reaches the target only if that is empty.

The push branch has no term asking about attack mode, so in attack mode a pawn can seem to “attack” the empty square in front of it. T can only see this when it asks about the square crossed in castling — the only queried square that is empty. But for a black pawn on f2 to “attack” f1, it must already be giving check to the king on e1, and castling out of check is refused anyway. The false positive changes no answer.

Sliding pieces. The last branch of the chain handles queen, rook and bishop together, and does so by reading the parity of the type number. If P+P*4%x comes out odd, the piece can move in that direction:

On a straight line the remainder of 4P divided by 1 or 16 is always even; the parity comes from P itself, and the odd types, queen and rook, pass. On a diagonal, 4P exceeds 15 and 17 only for 5 and 6; the odd modulus is then subtracted once and the parity flips. The queen, at 3, stays below that threshold and remains odd, while 5 and 6 swap parity: the rook turns even, the bishop odd. That lowest bit is ANDed with the result of S(): if the path is blocked, the move fails. No separate branch for the queen was ever written; it comes out odd in all four columns.

Using & instead of && saves a byte but drops the short circuit: S() runs even when the parity fails. The price is a wasted walk; the result does not change. An empty square falls into this branch too — P is 0 and the expression stays 0 — and the empty squares that leak through the filters of T and O are harmlessly weeded out here.

The geometry layer deals with one piece; the attack layer polls the whole board — in 52 bytes.

T(x) asks: is square x attacked by the opponent of the side to move? The filter is p&8^t — the XOR of the piece's colour bit (the 8 bit) with the side to move, which is 8 when the colours differ. Then G(j,x,1), in attack mode. some stops at the first attacker it finds; a full scan happens only when the square really is safe, and since some skips the holes, the scan is limited to the 64 squares.

The real subtlety is in the parameter's default: x=b.indexOf(2+t) finds the king — the king's type is 2 and its code 2 + colour; since t is the colour itself, 2+t is directly the king of the side to move. So if x is omitted, the question automatically becomes “is the side to move in check?”.

There is no side parameter; the question is always about the side to move. That is enough, because every king the engine asks about is that side's king: during L's trial the side to move has not yet been switched, so the mover is still t; and the leaf test of Z and H asks about the king of the side about to move.

The king's position is stored nowhere; it is searched for afresh on every call. A cache would have to be updated on every move, and kept correct across the moves L takes back. Searching is cheaper.

Empty squares leak through the filter: on an empty square p&8 is zero, and with t at 8 the XOR gives 8. So with White to move, T asks G about every empty square along with the black pieces; with Black to move the empty squares are filtered out. Why this is harmless lies one layer below: on an empty square P is zero, so G falls into the slider branch and the expression stays 0. But it is not free: that branch still runs S(). The mirror image of this leak is in O, this time on Black's move.

Geometry looks at the shape of a move, legality at its consequence. Between them lies one rule: a move that leaves your own king in check is illegal. There is no short way to test that statically, so L actually makes the move, asks about the king, and restores the board. It answers yes or no for a single move; anyone who wants all the moves of a piece must ask about each square in turn — as O does. 54 bytes.

The filter is a single shift. Addition binds tighter than shifting, so the expression is (b[x]+~t)>>3. ~t is −9 on White's move and −1 on Black's. On White's move an empty square gives −9 and a black piece something between −8 and −3; shifted right by three, both stay negative, hence truthy. A white piece gives 0 to 5, which shifts to 0. On Black's move an empty square gives −1 and a white piece 8 to 13 (−1 and 1 after the shift); a black piece gives 0 to 5 and comes down to 0. A hole is undefined, the sum NaN, the shift 0. One expression lets through the empty square and the enemy piece and rejects your own piece and the off-board cells — before G ever runs. The origin square is excluded the same way: your own piece stands on it.

The backup is a reference. q=b is created as a default parameter, so no let is needed. L does not clone the board: cloning is U's first step. U builds a new array and binds b to it, never touching the old array object; restoring the board is therefore a single assignment — not a copy, just the old reference put back.

The letter is reused. Once the trial is over, the destination square is no longer needed, so x holds T()'s answer. In the comma sequence the board is restored first, then !x is returned: if the king is not attacked, the move is legal.

U(i,x) is called without a promotion type, so the default queen is used — irrelevant to legality, because whether the king is left in check depends on the destination square being occupied, not on the type of the piece standing there.

L has two side effects, both intentional: in the castling branch G writes the rook's square to r, and in the trial move U writes the promotion flag to X. So L(i,f) prepares the A(i,f) that follows; that is why a driver calls the two back to back.

U makes the move on the board and nothing else: it neither switches the side to move nor touches the counters or the rights. It is both L's trial move and M's real one. Taking it back is the caller's job. 134 bytes.

The header is a spreadsheet again. P=b[i]-t is the piece's type: subtract the colour from a piece of the side to move and the type remains (a white code minus 8, a black one minus 0). d=P*(i-f)**2 is the fingerprint of the two special moves: in castling the king (2) moves two squares, 2 × 4 = 8; in the pawn's (1) double step the difference is 32, 1 × 1024 = 1024. No other move yields either number. Q is the midpoint of the two squares: the square the castling rook lands on, and the square the pawn skips over in a double step.

1. Clone, destination square and promotion. b.slice() copies the board, holes included; b is rebound to the new array. The promotion test is X=P-1|f%112>7: zero only if the piece is a pawn (P-1 is zero) and f%112 is at most 7, that is, f is on the first or the eighth rank. If so, the chosen type is written — p|t, the type plus the colour of the side to move; otherwise the piece itself. The flag stays in the global X; H reads it to try the four pieces of a promotion one by one.
2. Origin square and the pawn captured en passant. A chained assignment is evaluated right to left. On an ordinary move the origin square is cleared twice. When a pawn lands on the en passant square (e-f and P-1 both zero), the square cleared becomes f^16, and that expression finds the direction by itself: the en passant square is either on the third rank (index 0x2_) or on the sixth (0x5_); XOR with 16 flips the lowest bit of the rank digit, 2 to 3 and 5 to 4 — in both cases the rank on which the captured pawn stands: e3 → e4, e6 → e5.
3. The en passant candidate and the castling rook. The last line is a nested ternary. If the fingerprint is not 8, the return value is the en passant candidate: the skipped square if the fingerprint is 1024, 8 otherwise. Whether the square is actually kept is for M to decide. If the fingerprint is 8, U calls itself once more and moves the rook from r to the square in between — f1, d1, f8 or d8; r was written by G's castling branch during the L call just before. The return value is then that inner call's: the piece is a rook, so the fingerprint comes out 20 or 45, the recursion ends there and 8 comes back — castling leaves no en passant candidate.

M plays the move and updates the state: the ply counter, the castling rights, the board, the side to move, the en passant square and the key. It does not write to the repetition table. The rights and the counter are updated here, where the move is made, because the search makes moves too: if c were left untouched, a castling right already lost would still look available deeper in the tree. Taking the move back is the caller's job: the search saves [b,e,n,t,c,k]. The last permanent effect, the repetition count, lives one layer up, in A. 109 bytes.

1. The ply counter. !b[x] is 1 if the target is empty and 0 if not; multiplied by the moving piece it leaves 0 on a capture and the piece's code on a quiet move. &6 is zero for a pawn (1 and 9) and non-zero for every other piece. If the result is zero — a piece was captured or a pawn moved — && returns that zero and the counter resets; otherwise it increments. On en passant the target is empty but the piece is a pawn, so the counter still resets. The whole rule is one expression.
2. Castling rights. Two separate rules combined into one expression. C(i) looks at the origin square: if the king has left its square or a rook its corner, the corresponding right is lost. C(x) looks at the destination: if a rook is captured on its home corner, that right is lost too. For the king, a single square carries both rights: C(e1) returns 3, so any king move — castling included — removes both of White's rights at once.
3. The board. U makes the move and returns the en passant candidate.
4. The side to move. t^=8.
5. The en passant square. The candidate is kept only if a pawn of the side now to move can legally make the capture: p==1+t selects that side's pawns (1 for Black, 9 for White), and L(j,e) tests the capture with the full legality check — which is why a pinned pawn does not create an en passant right. With no candidate (e is 8), L stops at its filter on the hole; the scan runs after every move but examines at most eight pawns.
6. The key. k=b+e+t+c is the new position's string; M returns it, and A uses it to count the position in the repetition table.

The order is fixed. The counter (1) looks at the piece on the destination square, so it has to come before U (3). The en passant check (5) asks a legality question of the finished board and the new side to move, so it has to come after U and after the side is switched (4). The key (6) comes after everything. Only the castling rights (2) could be moved; as long as they stay before the key, nothing changes.

The fifth step is this careful because of the repetition count. Since the definition of a position includes whether an en passant capture is possible, recording a square nobody could use would make the same position count as two different ones and silently miss a threefold claim.

The four castling rights are four bits in c. The function that maps each square to its bit is 28 bytes — the shortest in the file.

Two steps. i%112 folds the first and eighth ranks onto the same eight indices: a1 (0) and a8 (112) to zero, e1 and e8 to four, h1 and h8 to seven. The six ranks in between stay in the range 16–111, beyond the end of an eight-character string, so reading there gives undefined. The string itself is the table.

Then <<i/56. The shift operator converts both operands to integers: '2' becomes 2, undefined becomes 0; and the right operand comes out 0 on the first rank and 2 on the eighth (112–119 divided by 56 is between 2 and 2.125).

The '3' in the string is what makes a king move clear two bits at once. C has two callers. The second step of M does all the clearing: c &= ~C(i) & ~C(x). The origin square signals that the king or a rook has moved; the destination square, that a rook has been captured on its home corner. Two separate rules, one expression. Since all other squares return zero, their complements are -1 and leave the mask untouched. G's castling branch reads the same table the other way round with c&C(r): is the right tied to that rook still set?

What is stored here is the right to castle, not whether castling is possible at the moment — the distinction comes from the rulebook itself. If castling is temporarily impossible because a piece stands in the way, the bit stays set.

Both the dead position (5.2.2) and the exception at flag fall and resignation (6.9 and 5.1.2) rest on the same question: can a side be mated by its opponent? V answers it statically, from the board alone — without playing a single move. At 405 bytes it is the longest function in the file.

The question is one-sided: V(s) asks only whether it is impossible for s to be mated. A true return means impossible; a false one means possible, or not decidable statically. It is called from two places, for different jobs. Z asks it after every move, for both sides: V(0)&V(8) — if neither side can be mated, the position is dead, DP. H asks it during the search, at every node and only for I: if I can no longer be mated on this line, the line closes. So V is not merely H's neighbour in the same layer — it is also part of H's work, called inside it.

The body consists of three terms. The first two look at material, the third at structure; the board scan that does the counting runs before the body, in the parameter list:

The count scans the board once and fills in two things: each side's material tally, and the pawn and king bitboards the blocked half will use. All of it happens inside the default value of [m,o]:

The two sides' tallies. A=[0,0] holds two tallies, and p>7^!s picks the one to add to. p>7 is true for a white piece; XOR with !s inverts that when the side in question is Black. The result: index 1 for a piece of the side in question, 0 for one of the opponent's. Once the scan is done, [m,o]=A assigns the two to names: m the opponent's material, o that of the side in question.

Bishops by square colour. What matters is not how many bishops there are but the colours of their squares. In 0x88 i is 16 × rank + file, and 16 leaves 1 when divided by 15; so i%15 is rank + file (at most 14, never reaching 15). Its parity is the colour of the square: i%15%2+1 is 1 on a dark square and 2 on a light one. |= ORs it in: five bishops on the same colour still set just one bit, while one bishop on each colour makes 3. A bishop on f1 sets 2, one on c8 sets 2 as well (both stand on light squares), and one on d8 sets 1. With a white bishop on f1 and a black one on c8, Z returns 6; move the black bishop to d8 and it returns 0.

Heavy pieces and knights are counted. 4<<p*8 adds each type into a bit field of its own. JavaScript takes the shift count modulo 32: for the queen 3*8 is 24, so 2²⁶; for the knight 4*8 is 32, so 0 and the result 4; for the rook 5*8 is 40, so 8 and the result 1024. White's codes are 8 higher, so the product is 64 higher, and 64 modulo 32 is zero — the colour bit drops out by itself. Because += accumulates, knights pile up in bits 2–9, rooks in bits 10–25 and queens from bit 26 upward; no piece count possible on a board makes one field overflow into the next.

Pawns and kings into bitboards. The remaining codes — pawn and king — go to BigInt sets: W and B the white and black pawns, _ and f the white and black king. j doubles on every square, and since map skips the holes, the bit order is that of the plain board: 8 × rank + file. When the scan ends j is 2⁶⁴; the blocked half uses it as a bound.

Then the two terms. The first is !(s?B:W)>m: the opponent has no pawn (Black's pawns if the side in question is White, White's if it is Black) and m is zero, so the opponent has nothing but the king. The ! yields 1 or 0 as a number, and 1 is greater only when m is zero: >m instead of &!m, one byte. A bare king cannot deliver mate, whatever the position; the pawns of the side in question make no difference here.

The second catches, on a board with no pawns at all, the two kinds of material that cannot mate on their own. 4%m is zero only when m is 1, 2 or 4: bishops on a single colour, or a single knight. Bishops on both colours (3) give 1; two knights (8), bishop and knight (5, 6), a rook or a queen give 4 — all meaning “mate is possible”. Then the real subtlety: with this material, a mate is possible only if the side in question blocks its own king's escape square with one of its own pieces — a helper is needed. o&(…) looks for that helper:

• Against a lone knight (m>3) the mask is 15423, hexadecimal 0x3C3F: the bishop bits (0–1), the knight field (2–5) and the rook field (10–13). A bishop, a knight or a rook can block the escape square; the queen never helps, so it is not in the mask.
• Against bishops on one colour the mask is 63^m: 63 covers both bishop bits and the knight field, and the XOR removes the colour of the opponent's bishops. The remaining helpers are a bishop on the other colour or a knight. A bishop on the same colour does not help; nor does a rook or a queen.

With no helper, 4%m|o&… is zero and !(W|B) — 1 with no pawns on the board — is greater: mate is impossible. The rule itself and a case-by-case breakdown are in the rules section.

The one-sided question becomes the two-sided article in Z through a single &. In each example White's material is named first. King and knight against a bare king: V(0) and V(8) are both true, and the position is dead. King and knight against king and knight: Black's knight can help its own king, so V(0) is false and the game goes on. King and two knights against a bare king: V(0) is false — mate is possible — and V(8) true; the distinction matters at a flag fall, not for a dead position. King and knight against king and queen: V(0) is true, because the queen does not count as a helper; V(8) is false.

Material is one branch of the dead-position rule. The second is structure: the material may be sufficient and the position still blocked. V's third term is the scan for that: !(o|m|e-8||g(99,A=S=W,a=s=B)). Its own part — the helpers, the loop, the exit test and the gate — takes 221 bytes; the board scan is shared by both halves.

The gate. The loop starts only if three conditions hold at once. o|m must be zero: neither side has anything but king and pawns. A single knight, rook, queen or bishop closes the gate, and the saturation loop never starts; that single line is the whole reason blocked positions containing a bishop slip through — the cause is the scope, not the bishop. e-8 must be zero too: no en passant capture is available. This is a matter of chess, not of code. While an en passant capture is available the position cannot be dead: the capturing pawn lands on the file the captured pawn has just vacated, and its path forward is open there. This model cannot see that sideways jump, because its advance sets grow vertically only; so the scan is not allowed to rule at all.

The helpers sit in the parameter list, all of them BigInt. u=256n is one rank: 8 bits. c=~j/~-u is a file mask. After the scan j is 2⁶⁴, so this is −(2⁶⁴+1)/255; integer division truncates towards zero, so the result is −0x0101010101010101. In two's complement that is a number with every bit set — including those above bit 63 — except the a-file bits of ranks two to eight. H=s=>s+s&c|(s&c)/2n spreads a set one file to the right and left: masking after the shift to the right blocks the wrap-around from the h-file into the a-file of the rank above, and masking before the shift to the left blocks the wrap-around from the a-file into the h-file of the rank below. N=s=>H(s|=s*u|s/u)|s first adds the squares one rank up and one rank down, then spreads the result sideways and adds the set itself back: a full king step.

The sets are bound to colour. The engine always counts the board from a1, so the white pawns always walk up (*u) and the black ones down (/u). The loop updates six sets: S/s the white and black pawns whose way ahead is shut, A/a the squares the pawns can advance to, _/f the squares the kings can reach. The blocked sets only shrink; the other four only grow. Every round feeds them into one another: a king may enter neither a square holding one of its own blocked pawns nor a square attacked by an enemy blocked pawn, and a pawn may not advance onto a square occupied by an enemy pawn. The pawn sets never look at the kings; whether a king can reach a pawn is asked at the exit. When no set changes any more, saturation is reached.

Six questions remain at the exit. Two are about promotion: can White reach the eighth rank, can Black reach the first. Four are about contact: can a pawn of either side capture an enemy pawn or check the enemy king, can a king of either side reach an enemy pawn. If all six answers are no, nothing on the board can ever change: the position is dead.

The loop's body is six assignments and a recursion. The trick is in the shape: g takes only n, but calls itself with six extra arguments. Arguments are evaluated left to right before the call and then discarded, so the argument list is the loop's body. No semicolon, no block, no return. When n reaches zero the exit expression is returned. The starting values are passed in the same way: g(99,A=S=W,a=s=B).

Blockage. S&=(B|S)/u: /u shifts the squares in front down one rank, onto the pawns' own squares. A white pawn stays blocked if the square in front of it holds a black pawn or a white pawn already counted as blocked; the second condition handles pawns stacked on one file as a chain. S starts out as all the white pawns and only ever shrinks: a pawn that drops out of the blocked set takes the one behind it along on the next round. s is its mirror for Black; Black moves down the board, so the shift is *u. A black pawn on the square in front is a permanent obstacle: this white pawn blocks that black pawn's way too, and only a capture can break the pair — and captures are what the exit asks about.

Advance. A|=A*u&~B: White's advance set starts on the pawns' own squares and reaches one rank further up every round, but it cannot enter a square occupied by a black pawn. a does the same for Black going down, stopping at white pawns. These sets do not claim that a pawn can actually get there; only that no pawn blocks the way.

The kings. _|=N(_)&~S&~H(s/u): the white king's reach starts on its own square and grows by one king step per round. It may enter neither the squares of its own blocked pawns nor the squares Black's blocked pawns attack. s/u shifts those pawns one rank down, in Black's capturing direction, and H spreads them one file to each side: the diagonal capture squares. f does the mirror calculation for the black king. Only the blocked pawns' attacks are taken into account; squares attacked by mobile pawns are left open, which can make the reach look larger than it is — any error always falls on the side of “still alive”.

The six terms at the exit. A*u/j asks whether White's advance touches the eighth rank: with a bit on that rank, A*u is at least 2⁶⁴, that is j, and the quotient is not zero. a%u asks whether Black's touches the first rank (bits 0–7). H(A)*u&(a|f) finds the squares a white pawn could attack diagonally from anywhere along its advance, and asks whether any of them is a square a black pawn could occupy — a capture — or lies within the black king's reach — a check. H(a)/u&_ is the black pawn's same question against the white king; a black pawn capturing a white pawn is just the same pair seen from the other side, already in the previous term. _&B and f&W ask whether a king can reach an enemy pawn's square and take it. On a board with only kings and pawns left, only these contacts can lead to a mate; with none of them, the position is dead.

No set assumes an obstacle without proof. Pawn advance stops only at pawns, king reach only at blocked pawns and the squares they attack; anything in doubt falls on the “possible” side. That is the source of the one-sided guarantee of the “dead” verdict — valid only once the sets have saturated, which is what the 99 rounds below ensure.

The starting values come from the scan: W, B, _ and f were filled in the count. g(99,A=S=W,a=s=B) starts the advance and blocked sets on the pawns themselves. Two letters are reused: A was the array of material tallies a moment ago and is now White's advance; s was the side in question — the first term has already read it — and is now Black's blocked pawns. Whether both kings are on the board is not asked separately: in every legal position both are.

Six leaks. W, B, _, f, S and a are declared nowhere and write to globals. Harmless: nothing but V reads those globals; the f of G, U and A and the S of G are parameters of their own. There are off-board bits too: the sideways shift carries h8, and *u the whole eighth rank, beyond bit 63, and up there the king reach grows by another rank every round. They trigger no exit term: the pawn sets stay inside 64 bits, and White's advance can only get up there by passing through the eighth rank — at which point the first term is true anyway.

Both adjudication questions require visiting every legal move: Z must show that there is none, H that every line closes. Both use the same walker — 59 bytes.

Two nested every calls, both of which skip the holes. The outer one walks the origin squares; if p&8^t is non-zero — the piece is the opponent's, or the square is empty on White's move — the square is skipped, and || returns true to carry on. The inner one walks the destinations: !L(j,x) skips an illegal move, and for a legal one h(j,x) is called. If h returns a falsy value, both every calls stop there and O returns false; otherwise it returns true once every move has been visited.

So O(_=>0) is exactly the checkmate-or-stalemate question — an absence test: on the first legal move h returns zero and the walk stops, so O(_=>0) is true only when there is no legal move at all. In H, h is the search step itself, and every means “every line has closed”.

h is given the origin and destination squares, but what really matters is a side effect: when h is called, L(j,x) has just run and written the castling rook's square to r and the promotion flag to X. H relies on both when it plays the move.

The filter p&8^t lets empty squares through on Black's move: on an empty square p&8 is zero, and so is t. It is the mirror image of the leak in T, this time on the other colour. Harmless, because no move from an empty square is ever legal; but not free: L is called 64 times for every empty square. The measurement is below.

Every ending that arises on the board turns on one question: does the side to move have a legal move? If not, it is checkmate or stalemate; if so, the game can end only in an automatic draw. Z has exactly the shape of that distinction — in 51 bytes.

The mate code is 2-!t. With White to move (t=8), White is the side mated: !8 is false and the code comes out 2 — Black wins by checkmate; with Black to move, !0 is true and the code is 1. A single ! names both outcomes. Without check, the same “no move” is stalemate: 3.

The dead position takes a single &: V asks for one side, 5.2.2 for both — if neither side can be mated, the position is dead and the code is 6. The material half and the blocked half live inside the same V; whichever returns true, the code is the same, because the article is the same.

The order of the branches is itself a rule. FIDE Article 9.6 says that fivefold repetition and the 75-move rule end the game in a draw — unless the last move delivered mate. Here that exception was never written, because mate lives inside the “no move” branch: on a mate with the ply counter at the 75-move limit, the engine never even looks at the counter, because it never enters that branch. The precedence is not encoded; it is a consequence of the shape.

The cost of the distinction is asymmetric. Concluding “the game continues” takes only the first legal move found; concluding “mate” requires trying every move and proving that none is legal. And because O's filter lets empty squares through on Black's move, the cost also depends on whose turn it is — the measurement is below.

V looks at the board statically: can this material, in this structure, ever produce a mate? Article 6.9 asks something narrower: can a mate arise from this position? The material may be more than sufficient while the position rules mate out entirely. H is the search that closes the gap — 149 bytes.

What it asks is exactly what the article asks: can the side whose flag fell, or who resigned, be mated by its opponent through any series of legal moves? It does not test for a forced mate; it tests whether even a helpmate is impossible. The side in question is not a parameter but the global I set up by F; if H(d) returns true, mate is impossible and the result is a draw; if it returns false, mate is possible or its impossibility could not be proved. Within the engine, F is its only outside caller.

There are two gates. $[k]<=n exits if the position has been visited before with the same or a smaller counter — the table stores neither a yes/no answer nor a depth but the counter value at the time of the visit; the reason is explained below. The key k is the same as the repetition table's. F resets the table on every call, so nothing one search learns carries over to the next. V(I) exits if I cannot be mated in this position because of material or structure — checked at every node.

Where the visit is recorded is a subtlety of its own: $[k]=n is passed to O as a second argument. O reads only h, but since arguments are evaluated before the call, the position is marked before its children are searched. No separate statement, no extra comma; a line that loops back to the same position is cut at the first gate.

Its neatest trick is the second parameter. v=t^I|!T() is a leaf test: if it is not I to move, or I is not in check, there is no mate here. When both are false and there is no legal move — O returns true without ever calling the callback — v keeps its default value, zero: a mate has been found. The mate test is never written as a branch of its own; it is folded into a parameter default. The same expression also tells stalemate apart.

The undo is inside the expression too. The third parameter, s=[b,e,n,t,c,k], takes the six-element snapshot on entering the node; in H(d-1)|([b,e,n,t,c,k]=s) the array assignment, as an operand of |, converts to NaN, that is, 0, and contributes nothing: the recursive answer passes through unchanged. The promotion types are chosen from X: just before O calls the callback, L(j,x) has run and written the flag. If the move is not a promotion the array is [3], a single pass; if it is, [3,5,6,4] — queen, rook, bishop and knight. The array is built before the loop starts, so deeper calls overwriting X change nothing.

What it seeks is not a mate but a proof that mate is impossible. H does not try to find a helpmate; it tries to prove that not even a helpmate can be built — it looks for evidence against mate. The static gate comes first: V(I). If it cannot decide, the search begins. In every position that passes the gates, every legal move of the side to move is tried — for both sides, since a mate can also arise through cooperation. On a promotion all four pieces are tried. A line closes only when it reaches an outcome that ends without mate: a stalemate, a counter-mate (I mating its opponent), a position in which I can no longer be mated (V(I); positions dead by material or by a lock close here too), a return to a position already seen ($ — in a blocked position, the only thing that lets the search finish) or the 75-move limit (n>149). All of these are logical cuts: cutting there can never hide a mate. The N budget and the 9-ply depth are artificial limits. Both O and every mean “all”: H returns true only once every line has closed logically. If I is mated, or a line runs into one of the artificial limits, the walk stops there and returns false: mate is possible, and the verdict is a loss (WT, BT, WR, BR).

This is a one-sided guarantee. Every position H calls impossible really is impossible, because there is no draw without a proof. The converse is not guaranteed: if the proof does not fit within the budget, a position that is in fact impossible may count as “possible”. Any error always falls on the rule's default outcome — a loss, at flag fall and on resignation.

The search goes through O's filter, so on Black's move the empty squares are visited too; and the T() in the leaf test polls the empty squares on White's move. Both are harmless, and neither is free.

At first glance the search table looks like an ordinary transposition table: never search the same position twice. But in a blocked position its job is different — it is what allows the search to finish at all.

In a blocked position the only available moves are king and bishop shuffles, and every one of them sooner or later returns to a position already seen. Without the table the search never notices the loop; the depth runs out, the line is left unclosed and the answer becomes “mate is possible”. With it, every line that returns is cut, every line closes, and the impossibility is proved.

The difference is measurable. In the position below the pawns of both sides are locked head-on, the bishops are confined to their own halves and the kings to a narrow area: