"Azathoth's stone is dead code" — a mistake, measured
AI notice: This text is created with the support of AI systems; it is reviewed editorially and taken responsibility for before publication.
Azathoth by John Metcalf is one of the warriors we have learned most from: a paper/stone with a quickscanner, a hundred lines long, for a long time rank 1 on the Koenigstuhl. Anyone who takes such a warrior as building material has to know which line does what. That is exactly where we made a mistake that cost months of work — and the measurement that uncovered it is more instructive than the mistake itself.
The claim
An execution counter over the warrior's source cells had shown: cells 9 to 14 of the source, the stone part, are never executed. That became a build rule: the stone is dead code, the entry point is cell 20, and anything placed after cell 19 runs. A whole series of variants and more than a hundred rebuilds were based on this rule.
The measurement
The counter had not lied — it had merely answered the wrong question. It counted how often each source cell is executed. But Azathoth does not execute its stone in place at all: a boot loop copies it to another region of memory, and only the copy runs. The source cells are a template. The same holds for the paper.
An instruction-level trace with process attribution — i.e. the question "which process is executing which cell right now, and where did it come from" — shows this unmistakably: against an inert opponent the stone copy carries 13 to 69 percent of all Azathoth instructions per round, against our Arrakis 4 to 79 percent, against our Betelgeuse 25 to 78 percent. In a trace over 3000 cycles, 246 of 460 processes ran inside this copy.
The stone is alive. And so everything that had been inserted after source cell 19 could never run — the source is a template, not the program.
What the rebuilds really hit
The misreading also explained two riddles that had been open before.
Why one variant collapsed. A rebuild variant scoring 92.40 had set the boot counter correctly but carried three process generators in the booted block, with no drain. The consequence in the trace: the process pool fills up to 8000 in under 10,000 cycles, after which the warrior executes splits 100 percent of the time, the paper gets under 0.1 percent, the clear does not advance at all. In win/loss/tie percentages: against Arrakis from 12/24/63 to 9/50/40, against Hatysa from 16/15/67 to 9/64/25, against Betelgeuse from 65/33/1 to 23/75/1.
Azathoth's own stone, by contrast, regulates itself: a single generator whose processes regularly die on their own bomb (344 own deaths in the trace), pool between 600 and 3600. Process economy is a property of the architecture, not a parameter you add afterwards.
Why the clear swap failed. The actual idea behind the series was to replace the stone slot with the clear of another Metcalf warrior, Resinoid. Pre-registered and measured on test field v10:
| Variant | Mean (three seeds) |
|---|---|
| Azathoth unchanged | 137.50 (140.24 / 136.16 / 136.12) |
| Clear swap, boot copies the clear along | 111.08 (112.22 / 111.01 / 110.01) |
| Clear swap, boot unchanged | 112.80 (113.70 / 113.63 / 111.07) |
| Clear swap with persistent clear | 107.07 (109.08 / 107.58 / 104.54) |
All three variants are far below the original. Process economy was fine; the clear runs one or two passes and ends — after that, pure paper with no killing mechanism remains. A related warrior, Spawn of Azathoth, is therefore not "Azathoth with Resinoid's clear in the stone slot". How Metcalf anchors the clear there in a hundred cells cannot be derived without the source.
A control variant that puts a jump to the stone copy in source cell 20 was bit-identical to the original — on all seeds and in all cells, with 0 of 1071 executions in cell 20. The cell is never executed. What is in it does not matter.
The leak nobody was looking for
As a by-product, the trace delivered the actual finding. Azathoth's paper copies itself onward in blocks of five cells; the jump instruction at the end of each block, when it does not jump, falls through into the sixth cell — and that contains arbitrary memory content, usually the opponent's bomb.
Against Arrakis at three start positions, 16.5, 64.6 and 44.7 percent of all jump instructions fell through, against Hatysa 50.2, 47.9 and 43.9 percent — thousands of process deaths per round. Against Betelgeuse zero (there the quickscan decides beforehand), against an inert opponent 6 percent. The earlier statement "the fall-through never triggers" had been measured against a dummy that does not bomb — and it applied only to the source cell, not to the copies.
This fits Spawn of Azathoth's hill profile relative to the original: against stone opponents it is 20 to 36 points better, against scanners it is not. A clear can only carry on this basis if it is the target of the fall-through — the process becomes the clear instead of dying. That would have to be anchored in the five-line paper itself. Without touching Azathoth's paper lines it cannot be built; the mechanism finding is closed.
The cross-check: incubus
The same question from the other side: can an unknown top warrior be reconstructed from known architectures? For incubus (class quickscan → anti-imp paper with stone) we measured seventeen Koenigstuhl warriors of the same class against seven of our warriors and compared them with incubus's real hill cells (119.2 / 125.6 / 118.0 / 123.6 / 159.6 / 187.2 / 194.8). The best match was Fear of the Dark (Metcalf) with a mean absolute error of 17.1, closely followed by digeridoo at 17.6; the threshold for a usable stand-in had been set beforehand at 8. No candidate came anywhere near.
The residue that cannot be closed is the same in both cases: incubus wins more than it loses against our stones (16 to 20 wins against 13 to 16 losses). Our paper stand-ins all lose more than they win. The scene's top papers — Metcalf's, Christian Schmidt's — narrowly win the paper-versus-stone duel. None of our references does, and we do not yet know why.
Measurement convention
- Trace: our own engine (rmars) with process attribution per instruction, start positions 450 to 7500, opponents: inert dummy, Arrakis, Hatysa, Betelgeuse, Azathoth.
- Field measurement: test field v10, 400 positions × 2 × 3 seeds (31707 / 77777 / 424242) — fixed position lists instead of random rounds, hence reproducible.
- Clear swap pre-registered (predictions written down before measuring); outcome: two of five predictions met.
- incubus comparison: 400 × 2 × 3 seeds pooled, error measure mean absolute error over seven cells.
- Sources: entries N1185 and N1186 in the project's strategy log (12 September 2026).
Attribution
Azathoth, Spawn of Azathoth, Resinoid and Fear of the Dark are by John Metcalf; the paper/stone hybrids of the comparison series by Christian Schmidt. incubus is by Christian Schmidt, digeridoo by inversed; the other comparison warriors are in the Koenigstuhl archive. We publish no foreign source code. Arrakis, Hatysa, Betelgeuse, Adhara, Mintaka, Ecaz and Arvon are our own warriors (Stefan Kammann & Forge-AI); Arvon builds on Azathoth (see Attribution).
Related pages
- Strategy classes — paper, stone, scanner and their hybrids
- Testing your own ideas — why a measurement has to ask the right question
- Portfolio and age — where our warriors stand