Epoch 13: two new paths through the oracle

On 31 October 2026 at 21:24 UTC the oracle, the instance that decides on every change to Coherent, accepted tests again. Epoch 13 has applied since then. It introduces two paths that until now existed only in the constitution: speed-ups with an identical search tree, and play settings. Both can admit a change without a strength gain being shown. The path for gains and the path for simplifications stay as they were. This post describes what the new paths test, why the speed threshold is 1.5 % and how the switch ran in 3 attempts. It makes no statement about playing strength. The previous epoch was described in the post "Epoch 12: a path for simplifications".

What changed

The stages of the gain path and the constants of the simplification path are literally identical in the measuring code of epoch 12 and epoch 13. What is new is the fingerprint of the measuring environment, still in version 3.

The tempo path

The constitution treats tempo as a subtype of the edge case: speed at an identical search tree is admitted as a subtype of the edge case. According to annex A6 the verdict establishes search-tree identity and speed-up, not freedom from loss.

Two quantities decide in the tempo proof. For each position the time of base t_B and candidate t_K is measured in pairs:

Geomean    = 100 · (exp(mean of ln(t_B / t_K)) − 1)
Total time = 100 · (Σ t_B / Σ t_K − 1)

The gate requires both: the lower bound of the geomean must exceed 1.5 %, the lower bound of total time must exceed 0. The bounds come from a bootstrap over the positions with 10,000 replications; with irrtum = 0.05 the lower bound is the 2.5 % quantile. There is also a counter-check: the base is measured against itself, and this A/A band must lie within ±0.5 and contain 0. The double gate targets the case of a candidate that speeds up many short positions while the total work gets slower. In the simulation of the determination such a candidate never passed.

With an identical search tree the tempo proof is only the first part. After it the oracle checks for itself: the same bench node count and no deviation in move, nodes and score, an unchanged UCIUCI Universal Chess Interface, the text protocol between a chess engine and the program that runs it. interface and time management, peak memory at most 2,048 KiB above the base, and a tempo proof on withheld positions. Only then does the non-inferiority test follow in both stages.

What the account limits

Each start debits the reserve of 3 nElo per stage before the test, by 1.21 in the short stage and 0.75 nElo in the long one. That allows at most 2 starts. The debit is not a measured loss. It lies just above the maximum of (−θ) · P(stage passes at true effect θ), i.e. the worst possible expected deterioration per start in that stage.

The model treats the LLRLLR Log-likelihood ratio, the running evidence of an SPRT. It starts at 0; a stage passes at the upper bound and fails at the lower one. as Brownian motion between the bounds, with a cap. For this post it was recomputed with own code and a different numerical method; all values agree with the determination. These are model calculations, not measurements.

• The maximum is 1.2012 nElo in the short stage and 0.7026 nElo in the long one, in each case at a true effect of about −2.1 nElo.
• With 2 starts the bound on the expected cumulative deterioration is therefore about 2.40 nElo in the short and about 1.41 nElo in the long stage. That protects the expectation, not every single course.
• A candidate with no strength effect passes the short stage in 94.3 % of cases, the long one in 68.8 %, both in 64.8 %.
• At a true −2.5 nElo in both stages it passes both in 12.6 % of cases, at −5 nElo in 0.23 %.

In the last 2 points the model assumes the same effect in both stages; the bound before them does not. At a true effect of 0 a start costs 20,076 colour-swapped pairs on average.

Why 1.5 %: a placebo that seems faster

The threshold was originally 0.5 %. Then a second working group of the project measured a build whose behaviour does not change: only the code was shifted by 256 bytes. The result was +1.05 % with the band [0.91; 1.20]. This placebo would have clearly exceeded the threshold of 0.5 %. As it turned out, however, the value mixed 2 effects.

The second effect: a byte-identical copy of the engine measured −0.08 % [−0.24; 0.06] with a path of equal length and −0.48 % [−0.60; −0.36] with a path 32 characters longer. The observed point values differed by about 0.4 percentage points. Epoch 13 adds an explicit check of equal path lengths to the measuring runner.

With paths of equal length the count was repeated: 223 placebo runs with 1,000,000 nodes each on 3 processor generations.

The count was repeated for this post from the raw table and covers only the A/B part of the gate. The one run that also exceeds 2.0 % ran on Zen 5.

The spread of the placebos on Zen 4 was around 0.40 percentage points, that of a byte-identical copy 0.36 [0.29; 0.47]. The band of a single run does not capture this spread between runs. A stable effect of the individual placebo file could not be shown on Zen 4. That does not prove that every observed speed-up was spurious: an identical search tree does not rule out that a different program layout really runs faster.

In the normal model a pure placebo on Zen 4 passes at 0.5 % in 6.9 to 7.3 % of cases, at 1.0 % in 0.32 to 0.37 %, at 1.5 % in about 0.004 %. These are model values from 2 independent calculations. They come with a caveat: behind the 172 runs there are only 17 different files, and for the single-core measurement the model gives 0.13 % with an interval up to 5.7 %.

The strongest counter-argument is on record: on Zen 4 alone 1.0 % would be enough by calculation, and 1.5 % rejects genuine speed-ups between 1.0 and 1.5 %. In an evaluation of 55 older tempo proofs 5 cases passed at 0.5 % and 2 at 1.5 %; 31 further proofs had no raw data. The argument for 1.5 % was that the measurements ran under different conditions than at the oracle, with a different process model, a different node count and on different machines. A reduction would have been an estimate. The threshold is a precautionary decision against false promotion, not proof that layout effects are under control.

The follow-up measurement

So a rule was fixed before the first measurement: what counts is the upper one-sided 95 % bound of σ, not the point value. If it is at most 0.5 percentage points, 1.5 % applies. If it is above, 2 model families recompute. Until the result the tempo path stayed closed to submissions. The measurement ran on 2 Zen 4 machines, the processor generation of the oracle, on 2 cores each, and the A/A followed the model of the measuring runner at the oracle.

All 4 upper bounds lie below 0.5 percentage points, as do all 8 subgroups. 127 of 136 assignments were collected; 3 measuring blocks stayed empty and were not repeated. Another model family recomputed the evaluation from the raw data: 1,196 compared fields, largest deviation 1.1 · 10⁻¹⁴. On 1 November 2026 at 07:16 UTC the threshold was thereby confirmed and the closure was lifted.

The limits of this result:

• Gaps. All 3 empty blocks are on core 1. Filled in pessimistically, the bound there rises to 0.318 and 0.611. That is no confidence interval and not the pre-set criterion, but the second number lies above 0.5.
• Machines. σ was about 1.7 to 2.2 times as large on the second machine as on the first; the cause is open.
• Transfer. The measurement did not take place at the oracle itself. The rule named exactly this measurement as the basis, and the criterion was not changed afterwards. Whether σ is equally large at the oracle is therefore not established.

Play settings

According to rule R13 a play setting is a UCI option for exactly one playing purpose other than strength, which is named in writing before code for it is written. It may change play only at a value outside the default, and an active setting may play weaker.

This path has no SPRT. Instead the oracle checks neutrality: at the default value search and play-relevant state stay the same, in 3 cases: without an option command, after setting the default, and after returning from another value. A tempo proof shows that the loss stays within tolerance, which is 0.2 % per option and 0.5 % for all together. In addition, an effect fixed in advance must occur in a measurement not carried out by the author.

The tolerance is tight. With run noise of about 0.36 percentage points a neutral candidate would lie above it in about 29 % of runs. The tempo proof of this path uses a fresh file copy per engine start; for this 2 model families calculated an error rate of 0.25 to 1.35 % with 256 positions times 4 waves. That is a model calculation based on earlier measurements, not a measurement at the oracle.

What else the switch contained

• Test positions. The positions of the differential gate were brought to the state of the main branch: of 256 positions 15 were replaced. In the examined proofs of promoted parts no dependence on these 15 was found.
• Anchor. Register entry T-0230 is the same engine as T-0228, version 0.2.25, built twice and byte-identical, 603 bench nodes. Its fingerprint replaces the previous one.

How the switch ran

Epoch switches fall under the standing order described in the post on epoch 12. The package was built on 31 October; before the threshold was set it passed 134 tests, and 91 of 91 deliberately inserted faults were detected. It was checked by a model family independent of the author and by another model from the author's family. A further family was not available; the gap is recorded in the files.

• Attempt 1. From 19:13 the oracle accepted no new tests. 2 pre-checks halted the process because leftovers from operations violated their conditions. Both halts stayed without effect. At 19:33 the first window was closed again.
• Attempt 2. The second window opened at 19:39. 2 model families were to confirm the new fingerprint; both declined in round 1 because a text was out of date. After the correction both confirmed. At 19:58 the anchor stood in the register. At 20:02, 20:03 and 20:03 the 3 further irreversible steps followed. At 20:04 the final check failed on a wrong assumption about the carried-forward operating state.
• Attempt 3. A follow-up package corrected the wrong assumption and made completion possible. 2 reviewers confirmed it in 2 rounds; it passed 148 tests and detected 109 of 109 inserted faults. At 21:09 the third window opened, at 21:13 the completion was written, at 21:24 the oracle accepted tests again.

In total the oracle accepted no new tests for 2 hours, 7 minutes and 9 seconds. No running oracle test was aborted; the oracle was empty before the first closure. The 3 windows were open for 51 minutes and 54 seconds together. At the switch to epoch 12 it was 31 minutes and 13 seconds.

Status in the register

The export of 1 November 2026 holds 231 entries. T-0231, the first test of the epoch, was a gain candidate; it was rejected. In the export no entry is classified as tempo or play setting.

What this post does not say

It reports no measurement on the new paths. The tempo values come from preparatory measurements with placebos and copies, not from tests at the oracle. The probabilities are model calculations. That the paths exist does not mean that changes through them lead to more playing strength.

How this was checked

• Sources: constitution (R13, annex A2 to A6); determination version 3.1 with the threshold from version 3.2; measuring code of the main-branch states of both epochs; oracle register, export of 1 November 2026; decisions, window record, execution log and evidence per step; evaluation of the follow-up measurement.
• Recalculation: record and code values, register, times and the placebo table were checked against the sources by script. The placebo table was counted from the 303 raw rows. The model values were computed with an own finite-difference method and agree with the determination on all stated digits. The σ of the follow-up measurement is taken from the record and was independently recomputed there.
• Independent review: an agent of another model family checked text, tables and graphics against the same sources in 2 rounds and recomputed the placebo table and model values with its own code. It confirmed the calculations and named corrections to the wording. They have been incorporated, except for one point that the acceptor decided differently; the last corrections were not reviewed again.