What the result file does not label

Everything below was read out of the interface's own result files: six tournament files on the workstation, not the test register. Nothing here has a test number, and nothing here could have one — which is also why none of it is a statement about playing strength.

The first run in a tournament interface, three reading errors of the same shape, and five faults the harness reports never raised.

Coherent had been played by a test harness for some time before anyone watched it play. On 2026-08-30 it ran inside a chess tournament interface on a desktop workstation — a board on screen, a clock running down.

This entry is not about how it did; that question belongs to a measurement, and this was not one. It is about what the interface stores, what it leaves out, and three reading errors that followed — the third made while writing this.

The colour is not labelled

Each finished game is stored with its result, the reason it ended, its length, the moves, and the two engine names. No field labels either engine as White or Black. black and color do not occur in the files at all; white and side do — in an Armageddon rule and in swap pair sides, both tournament-level — but neither ever labels a game. The names sit in a list of two, and that list looks like it gives the colours.

The file is not silent on the subject, which is what makes the trap work. Every game file carries "swap pair sides": true in its header. The format records that the sides get swapped, and then never labels which side anyone had in any particular game.

An automated reading took the first name to be White. Checked against the move data, the first name is Black in every game examined — so that reading assigned both engines the wrong colour in every single game, and with the colours reversed, a decisive game’s outcome reads as its own opposite. A draw stays a draw; everything else inverts. There is no partial credit and no averaging out: a wrong constant is wrong everywhere.

What the file does hold, without labelling it

The colours are recoverable, because the interface stores an evaluation, a depth and a node count beside every move the engines searched — the fixed opening moves carry no comment — and the two sides in these games searched to very different depths.

One side searched shallow throughout and never went deep; the other spent most of its moves far below. The two distributions overlap only in a narrow band at the shallow side’s ceiling — a handful of moves out of thousands — and their masses do not come near each other. Combine that with a second marker — the opening is fixed and twenty half-moves long, so the first commented move in every game belongs to White — and the list position resolves: the engine named second had White. Checked across all six game files and both list orderings, with no counterexample.

This is a consistent reconstruction, not a proof. Two things it rests on are worth stating plainly. The two markers are not independent: both come out of the same file, and they are complementary rather than mutually confirming. And separating the two depth clusters does not by itself say which cluster belongs to which name — that step uses information from outside the file to associate an engine name with a depth cluster. A game file that contains neither engine shows a shallow cluster too, so “shallow means Coherent” is not something the data establishes on its own.

An independent review by a different model, given the files and none of this reasoning, reached the same reconstruction and then declined to commit to it. Its objection stands: chess tools conventionally list White first, so data and convention point opposite ways, and the file alone does not break the tie.

The second reading error, and the third

The same reading reported a game count that a recount does not reproduce, and the difference is a whole tournament: a neighbouring file in the same folder holds games between two other engines, with no Coherent in them. They had been counted in — and they are also why a tally of games “not ending in mate” came out far too high, since none of those games ended in mate.

The third error is in this entry’s own drafting. Two commits from that day were named as having fixed two of the faults below. They exist and they are from that day, but 6257300 reserves the pseudo-legal move list up front and d8f006b changes seven range loops to bind by reference — the throughput item and the build item, not the two they had been attached to. The attribution was assumed and it was wrong.

The three share a pattern: order, proximity or timing was treated as metadata, and the mapping was never checked. A separate check exposed each one. That is what three cases show — a pattern that occurred three times, not a law about how often it occurs or why.

What running in an interface surfaced

The harness plays each candidate against Coherent’s own predecessor and reports a rating difference. A fault that affects both sides alike does not move that number, so nothing in the normal report draws attention to it. Five things showed up in a GUI that the harness reports had not:

None of these was invisible in principle — a timeout does appear in a result, and throughput can be computed from nodes and time. They were unremarked, which is a different thing and the reason a second kind of run was worth doing at all.

The first item is not cosmetic. VERFASSUNG.md names this channel: adjudication thresholds hang on reported evaluations, so a shifted scale can change an adjudication decision wherever a threshold is actually crossed — without a single better move being played.

What this does not say

It does not say how strong the engine is, and no rating should be derived from anything here. The opponent’s strength setting was changed between tournaments and is not stored in these files at all; it lives only in the interface’s configuration. Games from different tournaments are different experiments and do not add up. The measurements are on the current state page, made under conditions nobody here controls.

It does not say the five items above cost rating. Most concern output and robustness. Any that could change what happens in a game go through the harness like anything else, and until they do, nothing about their value is established.

It does not say the harness could not find them. It says its reports did not raise them, and gives the reason in each case.

And it does not say the reading is right now. Three errors were found because a separate check was made — the move data for the colours, a recount for the games, the repository for the commits. Where no separate check was made, less has been ruled out.