A day without a verdict

The oracle, the measurement that decides whether a change to Coherent is adopted, gave its last verdict on 2026-10-11 at 08:30 UTC. By 2026-10-12 at 06:40 UTC, no further test had started: about 22 hours without a result. This entry describes why. The short answer: monitoring recorded no outage of the oracle; the candidates did not get to it.

What monitoring recorded

Up to 06:40 UTC on 2026-10-12 the monitoring history recorded no outage of the oracle and no lock on its supply; its messages about the oracle said that no candidate was ready. A tool that sorts the oracle's idle time into causes, minute by minute, counted 1 minute as occupied and 1,329 minutes as waiting for candidates from the pre-tests, none as a lock.

The way to the oracle

A candidate does not go to the oracle directly. It is built and must then pass two pre-tests against the current version of the engine on separate machines: the first filters out clear losses and, since the evening of 2026-10-11, also changes that show no effect under its test conditions; the second has to show that the change is better. Most candidates are measured there with a fixed number of nodes, which is fast. Changes that affect how an engine uses its time have to be measured with a real clock, on a few dedicated clock machines. Changes that only make the engine faster must play exactly as before and prove a measured speed gain instead; they skip the second pre-test. Only a candidate that gets through goes on to the oracle.

The fast path found no winner

From 08:30 UTC on 2026-10-11 to 06:40 UTC on 2026-10-12, 35 new candidates of the fixed-node kind were added. The second pre-test reached 29 decisions in this time: 21 rejected, 8 stopped at their limit without a decision. None went on to the oracle. The pre-tests found no change that was clearly better.

Of 4 new speed candidates, two measurements failed because the measuring machine was not quiet enough; one of these candidates was measured again and was valid with a gain of 1.57 per cent. It was rejected, because since the morning of 2026-10-11 a speed gain counts only if even the lower end of its 95 per cent band exceeds 3 per cent. In the night before, a speed-up of about 1 per cent had been rejected in the oracle after more than 3 hours. Another candidate was 4 per cent slower.

No clock candidate got through

The last decision of the second clock pre-test, the one that can send a candidate to the oracle, came on 2026-10-09 at 20:11 UTC. After that there was none. There were two reasons.

A pass sends clock candidates back. When a candidate passes the oracle, it becomes the new predecessor, and candidates still in the pre-tests generally have to be measured again against the new version. Fixed-node candidates barely notice. Clock candidates need far more machine time per decision. Between 2026-10-08 and 2026-10-11 the base changed 7 times. The last change, at 08:35 UTC on 2026-10-11, came from the last verdict itself; by 10:53 UTC it had sent 6 clock candidates back to the start. That morning a check commissioned by the supervising agent took the 3 base changes of the previous 24 hours and, assuming that changes come at random, estimated the chance that a clock round of about 9 hours finishes without a base change at about 32 per cent.

Few clock machines. Clock measurement needs machines that are used for nothing else, are alike and have been confirmed by two model families. From 2026-10-09 only one of them measured, because the second one was needed as a build machine. From 15:55 UTC on 2026-10-11 two measured again.

Other causes

Between 11:29 and 17:35 UTC on 2026-10-11, no new fixed-node candidates were added, because the generating process stopped several times; once because a change to the project's constitution had not yet been committed. None of the later candidates of this kind had passed the pre-tests by the end of the period; how much the pause lengthened the gap was not quantified.

Two errors of the agents from the days before weakened the clock path. A change on 2026-10-09 prevented new batches of the second clock pre-test from being queued until it was corrected the next day. And on 2026-10-11 the clock measurement spent about 10.7 machine-hours on candidates that were found retired in a review that afternoon. About 4.6 hours of that concern a batch that, as far as can be reconstructed, only started after it had been retired, because a check was missing; an earlier start cannot be ruled out.

The records also show two brief interruptions: a pre-test machine stopped twice over a connection error and was free again within minutes. All 47 builds in the period succeeded.

What was decided

On the morning of 2026-10-11 the project's owner noticed that the oracle had no work, and gave the agents the task of assigning the machines by need. The supervising agent then brought the second clock machine back. In the evening a proposal to move the oracle to a smaller machine was discussed and rejected after three independent reviews: make the flow to the oracle larger, not the oracle smaller.

The gap had no single faulty part. The fast path found no change that was clearly better, the last pass sent the slow path back, the slow path had few machines, and errors of the agents had weakened it in the days before. How much each of these contributed was not quantified.