athanor
A solver for Opus Magnum, a puzzle game about building chemical assembly machines. The part that exists is the referee.
The world model, the verifier bridge and the differential corpus test are done, and an optimiser that takes an existing solution and grinds it down the metrics runs from the CLI. The constructive solver — reaction planning, layout and scheduling, the part that produces a solution from nothing — is not built.
The shape of the problem
The game gives you a puzzle and asks for a machine that solves it, then scores the machine on four axes at once — cost, cycles, area and instruction count — which trade against each other. There is no single best answer, only a frontier of answers that are each best at something.
That makes it a search problem with an unusually clean property: the target is a discrete machine, and there is a cheap and perfect way to check whether a proposed machine actually works. Constructive search finds something that runs; optimisation grinds it down the frontier.
Trusting the simulator first
None of that search is worth writing until the simulator underneath it is right, because a search guided by a subtly wrong simulator optimises confidently towards machines that do not work.
So the current work is the referee. A native simulator is checked against the reference implementation over a corpus of about 4,500 community solutions — every one run through both and compared — and any solution the engine eventually emits has to pass that verifier before being reported at all. Every verify prints both simulators side by side, so a disagreement is visible immediately rather than at the end of a long search.
It is named for the alchemist's furnace: slow, self-feeding, meant to run unattended.