The failure modes diverge

I expected one of two outcomes from Task 9. Either both architectures crash to chance, confirming that the apparent Task 8 performance was retrieval and the function-learning hypothesis was uninteresting. Or the transformer retains meaningful accuracy while Reverie crashes, confirming that gradient descent extracts genuine multiplication structure from sparse examples and the architectural gap is real for hard operations. The point of the experiment was to pick between those two readings.

The result is neither.

  Task 9 — strict held-out multiplication, 5 seeds
  Frozen Reverie:      15.0% ± 13.7
  Symmetric Reverie:   50.0% ± 17.7
  Transformer:          0.0% ± 0.0

Symmetric Reverie scores 50% on test facts neither of whose orderings appeared in training. The transformer scores 0% across all five seeds with zero variance — not random failure, systematic failure. Reverie’s diffuse generalization beats the transformer’s confident wrongness by a large margin on the strictest version of the test we’ve built.

This needs explaining before it gets celebrated.

What’s actually happening

Symmetric Reverie’s 50% is not “the substrate learning multiplication.” It is the substrate doing diffuse weighted averaging over a training distribution whose answer space is skewed.

The multiplication facts with a·b ≤ 9 have a non-uniform answer distribution: 6 and 8 each appear as the answer to four training facts; 4 and 9 to three; most others to two. When a slot cell matches a held-out window like [2, +, 3, =], the sorted-multiset key (2, 3) was never trained — but the cell’s non-binding preferences (its normal per-cell preference row, updated on every observation it participated in) accumulate a soft bias toward whichever answer tokens are most common across the slot cell’s lifetime. Context cells with partial-match templates also contribute small weighted signals. The result is a prediction that’s biased toward common answers — 6, 8, 4, 9 — and some of those happen to be the correct answer for the held-out facts, because the most common training answers are also the most common possible answers.

This is not the same as learning multiplication. If we held out pairs whose answer was 1 or 7, Reverie would predict 6 or 8 and get them wrong. The 50% reflects the alignment between the held-out facts’ answers and the architecture’s prior — a frequency bias dressed up as generalization.

But the transformer’s 0% is also informative. Across five seeds, four held-out facts each, the transformer never gets one right. This is the opposite phenomenon: it has learned a function of the input that confidently predicts something wrong for these specific pairs, and the same wrong-something every time. A reasonable guess at the function: “predict whatever answer was most common among training facts that share an operand with this query.” For a held-out pair (2, 3) with answer 6, that function would point at the most common answer associated with 2 in training or 3 in training — likely 8 (from 2*4) or 9 (from 3*3), not 6. Systematically wrong.

So neither architecture has learned multiplication. They have learned distributions that partially solve the test in different ways: Reverie’s distribution happens to overlap with the held-out answers because the held-out pairs map to common output tokens; the transformer’s distribution doesn’t, because it’s conditioned on operand identity in a way that misses on unseen operand combinations.

Why this matters

This is the first benchmark result in the project where the two architectures don’t just have different scores — they have qualitatively different failure modes. That’s more informative than another ambiguous tie.

The transformer’s failure on this task is the failure of a system that confidently extrapolates. With enough training data, gradient descent on the same architecture would presumably eventually learn the multiplication function correctly. The error mode in the meantime is “wrong with conviction” — predict a specific token, get it wrong consistently.

Reverie’s failure is the failure of a system that does diffuse weighted averaging. The substrate has no notion of “the function the data implies”; it has cells that accumulate preferences over training. When the test falls outside any specific trained pattern, the prediction is a soft blend of whatever priors the architecture has built up. Sometimes that blend lands near the right answer by accident — when the right answer is also the prior’s mode.

Neither failure mode is, by itself, intelligent behavior. But they are different shapes of failure, and the difference clarifies what each architecture is doing. The transformer is a function approximator with insufficient data. Reverie is a prior-weighted retrieval system with no function approximator at all. Both are doing exactly what their mechanisms let them do.

I want to be especially careful here not to overclaim. The 50% does not mean Reverie is preferable, more correct, or doing something the transformer cannot. It means Reverie’s wrong-when-wrong is closer to “no opinion” than the transformer’s wrong-when-wrong, and on this specific test distribution that lower-confidence stance happens to score better than the transformer’s higher-confidence stance.

A test where the held-out pairs mapped to rare answers — 1 or 7, say — would reverse the order entirely. Reverie’s frequency-biased prior would underperform a transformer’s still-wrong-but-not-frequency-biased prediction. The 50%/0% split is specific to the multiplication-tables answer distribution, not a general architectural property.

What changes about the project’s reading

Across Tasks 6, 8, and 9 together, a cleaner picture emerges than entries 006–008 had each on their own:

The strict variants (6 and 9) are where things get interesting. On strict addition, both architectures collapse — neither can retrieve the unseen pair’s answer and neither has function structure for it. On strict multiplication, the two architectures diverge: Reverie at 50% via frequency-bias-meets-skewed-output-distribution, transformer at 0% via wrong-function-confidently-applied. The architectural gap that was invisible across the easy held-out tasks is visible here, just not in the direction “transformer is better at function learning.”

The reading I’d commit to: at this scale of data and model, the per-cell substrate’s failure mode is more aligned with the test’s answer distribution than the transformer’s failure mode. That doesn’t make Reverie a better architecture. It makes the comparison sensitive to whether the test distribution matches the architecture’s implicit priors, in ways that need to be controlled for in any honest benchmark.

The substrate’s strength here is its weakness elsewhere: it has no function approximator, so it can’t be systematically wrong. The transformer’s strength elsewhere is its weakness here: it has a function approximator, so when the function it learned doesn’t match the test pair, it’s confidently wrong.

This is the closest the project has come to a finding that says something architecturally interesting about both systems rather than declaring a winner.

Where the project goes from here

The list has not changed since entry 008 in terms of what’s available, but the framing has changed in terms of what’s worth doing.

The single experiment that would most sharpen this picture: redo the strict-held-out tasks but deliberately hold out pairs whose answers are rare. If symmetric Reverie’s 50% drops to ~10% on strict mult under that variant, the frequency-bias explanation is confirmed exactly. If it stays anywhere near 50%, something else is going on architecturally. About a day.

The serious next direction remains direction B — vector-symbolic binding — which is the only ADR on the queue that would give the substrate genuine function approximation (and therefore the ability to be systematically wrong like the transformer, which entry 009 has now suggested is actually a property worth having, not a bug). Weeks.

The retrospective option is still available, and entry 009 is a clean place to take it — the project now has a real architectural win (ADR 0017), a bounded characterization of what it does and doesn’t fix (entries 007 and 008), and one finding that distinguishes the two architectures’ failure modes architecturally (entry 009). That’s more than a research log usually accumulates before pausing.

Nine entries, seventeen accepted ADRs, one mechanism that lifts the headline number, one mechanism (described in this entry but not yet built) that would test the strongest remaining hypothesis. The project ends with measured uncertainty about what it has shown, which is the right shape of ending for a research log.

I am genuinely going to step away from this for a while and let the rest of the queue sit until I have a better idea. The benchmark is real. The findings are honest. The next move can wait.

— Kaan, with Claude as collaborator on the build, the experiments, and these notes. All nine tasks live at model/scripts/benchmark.py; the full sweep reproducible with --variant frozen or --variant symmetric and --seeds 5.