The first edge case: mate with bishop and knight

On 2026-10-16 at 17:19 UTC the oracle adopted an edge case for the first time: a change that only concerns the endgame of king, bishop and knight against a bare king (KBNK). It came in with version 0.2.18, from run T-0187, the first register entry of this kind. This entry explains what an edge case is, why KBNK, what the change does and what was shown before and in the oracle. It was written at the operator's request. It makes no claim about playing strength.

What an edge case is

Normally a change reaches the main branch only if the oracle finds a gain. The constitution of the project, in annex A3, allows a second way for the fix of a documented error or the improvement of a clearly bounded, rare class of positions.

• Such a change may be adopted without a proven 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; the oracle records the outcome „correction“.
• With the classification a proof is fixed that a machine can check. It must fail on the predecessor and pass with the change, and the oracle runs it itself.
• An independent model family confirms that the proof is meaningful, that the class is rare and that the classification is right.
• The change is adopted only if a non-inferiority test of the oracle with bounds fixed in advance passes at its upper bound, and a cumulative loss tolerance limited in advance is kept.
• The verdict only shows statistical non-inferiority within the fixed margin, not that nothing was lost.

Why KBNK

With king, bishop and knight the usual mating plan drives the lone king towards a corner of the bishop's colour; the mating square itself need not be the corner. With a halfmove clock of 0 and no repetition, every won position can be converted within the 50-move rule, but only with precise play. A study of the project's own self-play games counted the games whose first decided endgame-table checkpoint was KBNK. The stronger side won about 1 in 5 of them: 0.216 [0.187; 0.245] in 764 games in one delivery, 0.203 [0.174; 0.233] in 700 in an independent second one. For the most recent engines in the study the share was 76 of 188, about 40 per cent; that split by date was exploratory. The class is rare: KBNK made up 0.38 per cent of the games with a decided checkpoint.

A second study looked at how the network evaluates the KBNK positions reached in these games. It clearly prefers the right corner only when the lone king is 0 or 1 square away from it: then the raw evaluation is 92 and 59 centipawns higher than at a distance of 3, at a distance of 2 only 17; the distance here is counted in king moves. At distances of 3 to 7 king moves the pooled raw averages lay at about 29 to 38 centipawns, without a steady rise towards the right corner. These are static evaluations of positions reached in self-play, not a controlled experiment.

The change

The change adds a term to the evaluation that applies only when there are exactly 4 pieces on the board: king, bishop and knight against the bare king. It measures the distance of the lone king to the nearer corner of the bishop's colour in files plus ranks, at most 7, and adds 40 centipawns for each square that the distance is below 7: 280 in the corner, 0 at the greatest distance. The term comes after the material scaling of the evaluation. All other positions, KBBK included, are evaluated as before; the node count of the engine's benchmark stays at 695. According to the comment in the code, 40 centipawns came from an earlier measurement of 2026-10-03: 20 converted less often, 60 not more often.

Implementation, cross-check of the code and the confirmation required for an edge case came from 3 different model families. On its way to the oracle the build-form gate from the previous entries stopped the first version: the new term had taken the evaluation out of its inlined form, so it ran with the slow software popcount. The version submitted carries the switch for the faster variant.

The proof before the oracle

Before submission an agent of the project tested the change against the main branch of 2026-10-15, at 300,000 nodes per move. It drew 128 distinct random legal KBNK positions that the solver judged won, with the stronger side to move, a halfmove clock of 0 and no history, fixed before the first search. The engine played the stronger side; the defence was played by the project's own exact solver, which always chose the move that delays mate longest and preferred any move into a draw. A game counted as converted if it ended in mate before the 50-move rule, without stalemate, without a threefold repetition and without losing a piece; mate on the 100th halfmove still counted.

• Before the change 62 of 128 positions were converted, after it 101.
• In pairs: both 54, only before 8, only after 47, neither 19. The exact two-sided sign test over the 55 discordant pairs gives p ≈ 8 · 10⁻⁸.
• Control: in 320 positions outside the class (KQK, KRK, KNNK, KBBK with bishops on the same and on different colours) move and score stayed the same.

This was a local endgame test, not a measurement of playing strength. It holds against this defence, not against every possible one. An independent recomputation confirmed all numbers but rejected the test on formal grounds, because the binaries were tied to hashes only after the measurement; the acceptance resolved this with a bit-identical rebuild from sources fixed beforehand. Whether a constant KBNK bonus would have done the same was not tested. In a separate test of exact mate values both versions had 40 hits in 256 positions; individual outputs differed.

The proof that the oracle runs itself consists of 3 KBNK positions at 50,000 nodes, each in 3 repetitions. It failed on the main branch and passed with the change.

In the oracle

The oracle measured the change with a non-inferiority test: lower bound −5, upper bound 0 nElonElo Normalised Elo: the Elo difference divided by the spread of the game results, so that the SPRT bounds mean the same at different time controls., error rates 0.05. In the short stage at 8+0.08 seconds with Book A the test reached its upper bound after 26,750 games, in the long stage at 40+0.4 seconds with Book B after 9,818. Both stages passed. The register records the run as an edge case with a claimed gain of 0.

Both non-inferiority tests, fixed in advance, passed under the recorded conditions. That supports statistical non-inferiority within the chosen margin of 5 nElo. It does not guarantee a maximum loss, and it does not show a gain.

How this was checked

The facts come from the constitution, the oracle register, the change on the main branch, the acceptance of the proof and the 2 studies of the self-play games. For this entry the code of the change was read, the positions were checked with python-chess and the register entry T-0187 was read. An agent of another model family checked the text against the same sources.