Three entries that played no games

Every number below comes from the public data contract: register.json and epochen.json in the snapshot of 2026-09-05, with the register ID named beside it. The three entries discussed here publish zero test stages; where no measurement exists, none is inferred.

Some register entries pass without a single game. They mark the points where the measuring conditions changed — and where comparisons across the boundary stop being valid.

A register of engine tests is expected to contain measurements. Three of its entries contain none: T-0056, T-0062 and T-0070 each publish zero test stages and carry the proof type epochenwechsel — epoch change — instead of a sequential test (register.json). They passed without a single game being played.

That is not a gap in the record. It is what the record is for.

What an epoch boundary marks

The number an engine measures is a property of the pair (engine, measuring conditions), not of the engine alone. Change the toolchain that builds it, or the machine conditions it runs under, and the same code can produce a different number without a single line having been touched.

Rather than pretend such a change did not happen, the register marks it. Each boundary gets an anchor entry naming the reason, and results either side of it belong to different series (epochen.json):

Two things about that table. The last column counts the register entries that fall inside the epoch, not stages run by the anchor entry — the anchors themselves publish none. And T-0054 appears as the anchor of epoch 1 but is not one of the three entries discussed here; it opens the series rather than marking a change of conditions within it.

The dates are the observed ends of each group, not an operating log: they say when the recorded entries of that epoch fall, not that the machine ran continuously between them. They are UTC calendar days, truncated from the timestamps the export carries.

What the boundaries do not say

An anchor records that conditions changed. It does not record what that change was worth, and the register holds nothing that would let anyone find out.

There is no measurement spanning a boundary. To know whether epoch 3 measures systematically higher or lower than epoch 2, one would need a build tested under both sets of conditions — and no such test exists in the export. The anchors themselves contribute no games at all.

So the test log on the current state page is not one series. It is four, laid end to end, and the seams are marked. Reading a trend straight through them assumes exactly the thing the anchors were placed to deny.

Why a change of conditions can move a number

The project’s own decision records — cited here as qualitative reasoning, not as measurements — name some of what was adjusted: test parameters, the machine’s power profile, which cores games are pinned to, and the fingerprint by which a measuring setup is identified. The export does not map these onto individual boundaries, and they are listed here as examples rather than as an assignment. None of them touches an engine hypothesis.

The current published parameters give a sense of what is being held fixed within an epoch (methodik.json):

Sixty games run at once on one machine. A change in how those sixty share it can change the computing power available per unit of clock time — the clock itself stays at 8+0.08, but how much search fits inside it does not. A time-based test measures whatever the machine managed in the time allowed, not what the code could have done with more of it.

That argument has a gap, and it is worth naming rather than hiding. These tests are comparative: both sides play on the same machine under the same conditions. A change that slows both equally may cancel out of the difference between them, in which case it would not move the measured number at all. Whether it cancels depends on whether both sides lose search in the same proportion, and nothing in the export answers that. The boundary is drawn because the effect cannot be ruled out, not because it has been shown.

This mechanism also fits only part of the picture. It applies to the two boundaries drawn for measuring conditions. The toolchain boundary works differently — a changed toolchain can produce different code from the same source, which can change the search itself rather than the time it gets. Both are reasons to stop comparing across the line; they are not the same reason.

The export does not carry a full parameter history, so which of these values applied in which earlier epoch cannot be reconstructed from it. The table above is the current state, not a timeline.

What this does not say

It does not say the epoch changes improved anything. No gain across a boundary has been measured, and the decision record for the most recent boundary does not require one — a change of conditions is not a claim about strength, and passing an anchor is not an EloElo Strength difference to the opponent, estimated from the games, with a 95-percent half-width where the oracle reported one. Never an absolute rating. gain.

It does not say results from different epochs are wrong. They hold within their epoch, subject to the conditions there having stayed as recorded. What the present data do not support is subtracting one from another and calling the difference progress — a build measured under both sets of conditions would support it, and no such measurement exists here.

It does not say the boundaries are all the changes that occurred. They are the ones that were recorded as such. A change nobody noticed would not appear here, and this data cannot show whether such a change happened.

And it does not say how large a shift a boundary can cause. That would need a measurement across one, and there is none.