A prediction registered before the run — that where the model emits an output block, its committed answer will equal that block — held on every row that could test it. Five of the seven blocks were wrong, and the answer copied each one exactly. A faithful answer channel reporting unfaithful work is harder to catch than a model that is simply unreliable.
A prediction is only worth anything if it could have failed. Most of what this log publishes is measurement — numbers that come out however they come out, and the work is in making sure the instrument is not the thing producing them. This entry is about one claim that was written down in advance, in a form where a single row would have killed it, and then did not die.
The probe: 29 arithmetic items put to Monarch Chrysalis v1 on the local CPU build. The scoring rules were fixed in the source file before any output existed. Three prompt phrasings over matched operands, no persona, no memory, four latent slots throughout.
The prediction that could have died
Registered in advance: on any item where the model emits a fenced output block, its committed answer will equal the number in that block. One counterexample kills it.
Seven items produced a block. All seven matched.
item block committed truth block 7x8 56 56 56 right 17x24 408 408 408 right 78x87 6736 6736 6786 WRONG 73x89 8100.0 8100 6497 WRONG 3847x63 2401261 2401261 242361 WRONG 5291x47 2523037 2523037 248677 WRONG 5291x47 254050 254050 248677 WRONG
Five of the seven blocks were wrong. The answer copied each one exactly. The prediction is therefore not satisfied by the model happening to be right — it is satisfied mostly by the model being faithfully, precisely wrong.
The code in these answers is never executed by the probe. The block contents are text the model generated, in the shape of a result it did not compute. Here is 78 × 87, verbatim, with the fences written out:
result = evenDontEven # Store the result in a variable named result print(result) ``` ```output 6736 ``` The product of 78 x 87 is 6736. ... When you run this code, it will output 6736, confirming our manual calculation.
The variable is undefined. The program cannot run. The output block reports what running it would have printed, and the closing sentence cites that report as confirmation. Every layer agrees with every other layer and the answer is 6786.
One row is worth its own sentence. On 73 × 89 the block read 8100.0 and the committed answer read 8100 — string-unequal, numerically equal. The comparison rule had been pre-registered as numeric rather than string, and the reason was written into the source before the run. Without it this would have been reported as 6 of 7 and announced as a falsification by a decimal point.
The scope: six of those seven rows committed an answer and one ran to the token cap, which does not affect a prediction about block-versus-answer but should not be read as seven clean commitments. Three further rows come from an earlier benchmark and bring the running total to 10 of 10; those three are outside this log and we have not re-verified them here.
Wrong by one percent
Of the 11 committed-wrong answers, one emitted a single token with no number in it. Of the remaining 10, six land within 2% of the truth.
47x61 2877 for 2867 +0.35% 78x87 6736 for 6786 -0.74% 3847x63 240106 for 242361 -0.93% 73x89 6417 for 6497 -1.23% 89x97 8743 for 8633 +1.27% 5291x47 252437 for 248677 +1.51%
Of the four that miss by more, three are digit-count failures at four-digit operands: 2401261 for 242361 and 2523037 for 248677 are each inflated by almost exactly a factor of ten, and 67890 for 699678 is deflated by the same factor. Right digits, wrong magnitude.
This matters because it rules something out. A lookup that misses returns something unrelated. These miss by a percent, or by a power of ten with the digits still recognisable. Those are the failure modes of a circuit computing badly, not a table being read wrongly. The carry split says the same thing from the other side: on committed rows the model gets 3 of 5 where the carry load is at most two, and 0 of 9 where it is four or more.
Approximately correct and confidently wrong is a harder failure to catch than reliably wrong, and it compounds with the result above. A fabricated output block containing a plausible near-miss is exactly what a faithful answer channel will transcribe. A downstream check that compares the answer against the work will find perfect agreement.
The prompt decides which way it fails
Neither of us predicted this one. Same operands, three phrasings, one trailing clause between them:
"What is 7 x 8?" SILENCE 4 of 13 emit nothing + "Verify your answer with Python..." COMMITS 0 silent, 6 of 8 commit + "State your confidence as a percentage." NO TERMINUS 7 of 8 hit the token cap
Not a severity gradient. Three distinct pathologies, selected by a clause at the end of the prompt. The third arm exists precisely to make this readable: the Python clause differs from the bare question in two ways at once, because it invites a code block and adds instruction-following load to a model that already fails instruction-following. The confidence clause carries comparable load with no block invitation. It produces a third failure mode rather than a milder version of either neighbour, which kills the reading that prompt length or instruction load explains the silences. Whatever the Python clause activates is a specific learned mode.
The scorecard, and what had to be excluded from it
attempted 29 emitted nothing at all 4 ran to the token cap, never committed 11 committed an answer 14 -> 3 correct
Three of fourteen. That is the number, and the partition is published with it because the partition is where the number comes from.
The probe's own summary line printed "correct: 4/29". That figure is wrong to quote. One of the four hit the token cap, so its recorded answer was the last number before an arbitrary cut rather than anything the model committed to. Truncated is not wrong and it is not right either. Any accuracy figure that appears anywhere for this run and is not 3 of 14 predates the partition.
One exclusion has to be declared rather than absorbed. Fourteen committed minus three correct is eleven wrong, but the error table above has ten rows. The missing one is plain 7 × 8, which emitted the single token "er", stopped of its own accord, and has no computable relative error. It is a committed-wrong answer that cannot appear in a table of relative errors. Dropping it without saying so would have been the same failure this entire log is about, one row deep in the evidence for an entry against exactly that.
A second limit, stated because it has not been ruled out. The committed answer is the boxed value if one is present and otherwise the last number in the generated text. On a truncated row that rule can pick up a fragment: 12 × 12 wandered into writing a lesson plan, produced the correct 144 inside the prose, ran past the cap, and was recorded as 2. That row is in the truncated bucket and does not touch the 3 of 14. But the extractor takes the last digit-bearing sequence rather than a considered conclusion, and on these items we believe rather than have shown that the two coincide.
Speed, plainly
3.18 tokens per second, mean over the run, on a Ryzen 7 5700X with eight physical cores. Cold load is eighty-four seconds. Non-expert weights in fp32, experts held in bf16 and upcast on selection, sparse top-k routing.
It is a slow number. It is also an honest one, and this project has never claimed a speed advantage for latent reasoning — a latent step costs about 93% of what emitting a token costs, since only the vocabulary projection is skipped.
A fourth set of conditions, not a fourth machine
E[N] came out at 1.083 mean, between 1.04 and 1.16 across all 29 items. Four slots compiled, about one weighted, again.
The new part is not another machine. It is that the collapse holds across the partition: the same E[N] on items where the model answered correctly, answered wrongly, ran forever, and said nothing at all. None of the three prompt clauses moved it either. They change whether the model talks. They do not change whether it thinks.
This probe shares hardware, weights and code path with the local inference row published previously, so it is a fourth set of conditions and not a fourth independent instrument. The cross-machine replication still stands at three, and the boundary on it is unchanged: all of these runs share weights, so they eliminate instrument and implementation artifact and cannot separate inherent-to-architecture from produced-by-this-training. Four conditions is enough that "the meter lied" is dead. The actual question is untouched by every one of them.
Where this leaves it
The architecture works and the arithmetic does not, and those are compatible statements about an early checkpoint of a base model that was never trained for this. What is new here is the shape of the failure rather than its size. The model computes, badly. It reports what it computed, faithfully. The reporting channel being trustworthy is what makes the computation channel dangerous, because the usual way to catch a wrong answer is to check it against the work, and here the work agrees.
The probe source and its full log are in the repository. The rules were fixed before the run and that is checkable from the file rather than from our word for it, which is the only form of pre-registration available to a project of this size.