Epoch 8: a stricter oracle

On 2026-10-09 at 18:30 UTC the oracle, the instance that decides every change to Coherent, entered its 8th epoch. The epoch changed no line of the engine. It changed how the oracle reaches a verdict: in several places, a verdict that could have passed despite a weak or disturbed measurement is now refused. This entry describes what changed, what was planned and left out, and how the change went, including the first attempt, which failed.

What an epoch is

The oracle compares every candidate with its predecessor under fixed measurement conditions. When those conditions change, results from before and after are no longer measured the same way. The oracle then opens a new epoch: it builds the current engine again, records a new fingerprint of the measurement conditions, and writes an anchor entry into its register. Comparisons in the new epoch start from that anchor. Epoch 8 is the register entry T-0172.

What changed

The decision uses the exact value. A sequential test decides when its statistic, the log-likelihood ratio, crosses a bound. The oracle used to read that statistic from the printed output, rounded to 2 decimals. A run that stops at its game limit with a true value of 2.9355 is printed as 2.94 and would have counted as a pass, although the bound is 2.9444. The oracle now computes the statistic itself, at full precision, from the game results; the printed number is only displayed.

A pass needs stages that carry it. A regular two-stage comparison passes only if both stages pass at full precision and the counts of wins, draws and losses agree with the game pairs.

The measuring cores are bound and watched. A separate progress measurement, run by hand under the conditions of the short stage, now binds its engines to the same measuring cores as the oracle's tests. If binding the engines to their cores fails, the run ends in a halt instead of a verdict. The fingerprint of the measurement conditions now records the frequency settings core by core. And a watcher is set to read these conditions every 2 seconds during every stage; a change it detects leads to a halt instead of a verdict once the test has finished. The running test is not cut short.

Installation and transfer. For this epoch change, the oracle modules were installed together from one checked package, fixed by checksum. A package that arrives incomplete starts no job; a fixed procedure moves the fragment into quarantine.

A route for external measurements. The anchorings against engines from other projects are to be entered into the register. The route for this is installed, but sending and ordering are locked. It holds no entry; epoch 8 produced no registered external measurement.

Did any earlier verdict change?

No. Before the change, the new rules were applied to the register as it stood that morning. Every stage kept its verdict under the exact statistic, and every pass holds at full precision. For all entries the register reader could process, the old and the new reading gave the same result.

What the register cannot show is whether an earlier run ever had a disturbance in its measuring cores that went unnoticed; that is what the watcher now looks for.

What was planned and left out

The plan from 2026-10-05 was larger. It included an automatic route for changes that are correct but too small to show a gain, a route for simplifications, a route for playing settings, and the endgame tables. None of them was activated in epoch 8.

On the morning of 2026-10-09 the scope was cut to what was ready. Later that morning the project's owner asked whether an earlier change would bring more playing strength, and added: if something is blocked by the change, change as soon as possible. Two independent reviews, from two model families, agreed on the answer. The planned dates, 2026-10-10 for the content and 2026-10-12 for the window, were buffers from an outdated plan, not external reasons. Neither review could show that an earlier change brings measurable playing strength; the benefit is a safer measurement. On the owner's instruction, no new tests were then admitted, the running test was allowed to finish, and the change followed without stopping a measurement.

How the change went

First attempt. At 13:33 UTC the window opened. Less than a minute later, at 13:34, the 2nd step failed: a file it expected did not exist on the oracle machine, because no run of the type that writes it had ever taken place there. The way back worked. The register was unchanged, the stopped services were restored, no new route was switched on, and at 13:41 the oracle was running in epoch 7 again. It then measured a waiting candidate to its verdict. The handling of missing files was corrected, the prerequisites of later steps were checked in advance, and the package was checked again.

A fixed gate. At about 15:14 the owner installed a fixed gate on the oracle machine. The second attempt went through it without any step by a person.

Second attempt. At 17:54 the gate opened. Before the anchor, two model families had to confirm the new fingerprint independently. The first round failed because evidence on the machine load was missing, an omission the supervising agent recorded as its own error. The second round failed because, once switched on, the new route would have delivered 24 waiting packages; the sender was locked. In the third round both confirmed it. The anchor followed at 18:30, with the engine built twice to the same bytes. After a waiting period and a load check, the oracle was released at 18:41.

The first results

The first run in epoch 8 was rejected in the short stage after about 12,900 games. The second, a version of the engine from the line of a second research group, with its own search, passed both stages. These values are estimates from very short tests.

Epoch 8 lasted about four hours. The anchor of epoch 9 followed at 22:29 UTC. That is a story of its own.

Epoch 8 made the oracle stricter, not the engine stronger. What it was worth shows only over time: in verdicts that no longer pass by rounding or by a disturbed measurement.