The Rust-to-WebAssembly backtracker that runs every live demo and checks every number on this wiki. Not a record machine but a reference engine, ported four times and parity-tested byte-for-byte, built so the claims here can be re-run.
This page is about the engine behind the site you are reading, written by the person who wrote it, Raphaël Anjou. It is not a community record solver: those are studied elsewhere in this lab (Blackwood, McGavin, Verhaard). This one sits among them as a peer, and a modest one: the record solvers hold the records; this one holds the receipts.
Where the named experiments each ask a question and the shared engines are the apparatus those studies run on, this page is a third thing: the small reference engine that powers the site itself, checks the numbers the other pages quote, and animates every live demo. It scores no records. Its job is verifiability and teaching.
A small Rust crate compiled to WebAssembly, running live in your browser on every interactive page of this wiki. It implements the classics, plainly: the official 16×16 piece set, a generator that builds solvable puzzles of any size (with an optional real-E2-style mode that restricts border colours to the frame band), nine cell-visit orders, a strict depth-first backtracker, a scorer, and a break-tolerant variant of the search, a reimplementation of the break-index idea from Blackwood's solver, built so the labs here can demonstrate it.
One design choice matters more than the algorithms: the solver is a step-able machine, not a recursive function. Callers run it one bounded step at a time, one placement or one backtrack, and read the board between steps. That is what lets a web page animate a real search instead of a canned recording: the watch page is stepping this exact engine, not a video of it.
The site runs one engine: the Rust/WASM crate, the canonical reference. But the repository keeps a whole collection of faithful reimplementations of it in other languages: a pure TypeScript port (zero WASM), a C port, a C++ port, and smaller studies in Python, Lua, COBOL, even Brainfuck. Each is validated byte-for-byte against golden data the Rust crate emits: generated puzzles down to the RNG output, all nine fill paths at several sizes, and full solver runs with exact node, attempt, and backtrack counts.
That discipline exists for one reason: an interactive demo you cannot cross-check
is just an animation. Two independent implementations that agree to the last
backtrack are much harder to get wrong the same way twice, and eight are harder
still. The ports are a study exhibit, not build options (the site always runs
Rust), and they live together in the repo's engine-ports/ collection. Some of
them (the Brainfuck backtracker especially) are there for joy.
This is not a record machine, and it would be misleading to dress it as one. The strict solver carries none of the hand-tuned quota schedules or restart strategies that make Blackwood's solver the engine behind the community's best boards. The best score produced by the experiments here is 463 of 480; the community's best on the same puzzle is 470. The record solvers studied in this lab are simply better at finding boards.
Throughput is a separate axis, and one this reference engine deliberately does not chase - but a sibling experiment does. The JIT backtracker asks how fast a portable Rust search can go, and reaches McGavin-class throughput on the hard, deep boards that resemble the real puzzle - a tie with his hand-tuned C on the same machine (his C stays ~2.3× faster on easy boards). That is a speed result, not a solving one: it still plateaus where every strict backtracker does. Speed and score are different axes, and this page's engine optimises for neither - only for being checkable.
This engine's job is different: verifiability and teaching. When this wiki states a node count, a feasibility number, or a score, the claim is checked by this engine, and because it runs in your browser and its source is public, you can check it too.
Every interactive element in this research section is this engine: the live DFS demos, the fill-order races on the paths page, the break-index lab on the solver hub, the board viewer's scoring and verification, and the committed reference counts that research pages quote. The engine's own test suite cross-checks against real community boards, so a change that broke scoring or rotation conventions would fail loudly rather than silently corrupting the site's numbers.
Everything is in one repository, github.com/raphael-anjou/eternity2, and run it yourself walks through building the engine, running its tests, and reproducing the published results command by command.
The engine does not grow on its own schedule; it grows when an experiment needs something. The break-tolerant solver exists because demonstrating break indices required one; the frame-restricted generator exists because a lab needed puzzles that behave like the real E2 border. That keeps the engine small, and it keeps every feature attached to a question someone actually asked.