\section{Results}\label{sec:results}

All numbers in this section are generated from result files by \texttt{scripts/make\_tables.py} and are indexed
in \texttt{results/claim\_registry.csv} with their run identifiers. Unless stated otherwise, ``loss'' is the
teacher-forced cross-entropy on the answer span of the synthetic suite (nats per token), ``$b$'' a forced budget
applied to every position with uniformly random actions, and relative changes are with respect to the frozen
backbone (budget 0) of the same run.

\subsection{Learnability and the bootstrap problem (Phase 4)}\label{sec:results-learnability}
With the readout initialised at zero, as prescribed, the editor did not learn at all in 700 steps on the frozen
2.1M-parameter backbone: validation loss was identical at every budget (0.4144, 0.4143, 0.4143, 0.4146, 0.4164)
and the trainable gradient norm stayed at 0.01--0.02. The cause is a scale mismatch: the backbone residual stream
has root-mean-square 5.6 while the difference of the two attention reads has root-mean-square 0.06, so $U$ must
grow by two orders of magnitude before any edit can move a logit, and until it does the editor receives no
gradient. Three remedies were compared under the identical recipe (Figure~\ref{fig:learnability}): the fixed
scale $s$ alone (zero $U$), $s$ with $U\sim\mathcal N(0,0.2^2)$, and $s$ with $U\sim\mathcal N(0,0.5^2)$. Only
the non-zero initialisations learned within 2,000 steps (dev-iid loss $-1.4\,\%$ at budgets 1--2 for
$\sigma=0.2$); with $\sigma=0.5$ the budget-8 loss was worse than the backbone throughout, and a learning rate
of $3\times10^{-3}$ with $w=128$ collapsed to inert edits (every budget exactly equal to budget 0, gradient
norm 0.00). The deliberate-overfitting test passed: on 64 items at budget 8 the frozen-backbone model reached a
training loss of 0.0024 in 200 steps through the workspace path alone while the held-out loss rose, confirming
that the gradient path and the capacity exist. Failure mode 13.1 of the proposal is therefore confirmed, and
$U\sim\mathcal N(0,0.2^2)$ with $s=\rms(H)$ is used for every adapter below, including the baselines.

\begin{figure}[t]\centering
\includegraphics[width=\textwidth]{../results/figures/learnability_bootstrap.pdf}
\caption{Stage B bootstrap on the frozen tiny backbone (dev-iid answer-span loss under random forced actions,
budgets 0--8). Left: zero-initialised $U$ with the scale $s$; middle and right: $U\sim\mathcal N(0,\sigma^2)$ with
$\sigma=0.2$ and $0.5$. Budget 0 is the frozen backbone (identical in all panels).}
\label{fig:learnability}
\end{figure}

\subsection{Sparse editor versus global recurrence and dense writes (H1, H2)}\label{sec:results-matrix}
Table~\ref{tab:seedmatrix} reports the pre-registered decisive comparison on the second tiny backbone
(5.6M parameters, char-level): \vtwoprismeseeds{} independent adapter seeds for the sparse editor,
\vtwogrseeds{} for the global-recurrence adapter and \vtwodenseseeds{} for the dense sixteen-slot editor, all
trained with the same forced-budget recipe for 3,000 steps. H1 is supported in its weak form: random sparse
edits reduce the held-out answer-span loss by \vtwoprismegainbone{}\,\% (budget 1), \vtwoprismegainbtwo{}\,\%
(budget 2) and \vtwoprismegainbfour{}\,\% (budget 4), with seed standard deviations below 0.002 nats, and
raise dev-iid exact match from \vtwoprismeembzero{}\,\% to \vtwoprismeembtwo{}\,\%. The effect is not
specific to sparse local writes, however: the global-recurrence adapter---one shared block rewriting the whole
latent, parameter-matched, same bootstrap---reduces the loss by \vtwogrgainbone{}\,\%, \vtwogrgainbtwo{}\,\% and
\vtwogrgainbfour{}\,\% at the same budgets and reaches \vtwogrembtwo{}\,\% exact match, i.e.\ it is at least as
good at every budget and better at budget 8, where the sparse editor's gain shrinks to \vtwoprismegainbeight{}\,\%.
Dense writes answer the second half of H2 directly: rewriting all sixteen slots at every action with the same
editor weights (\vtwodenseseeds{} seeds) lowers the loss by \vtwodensegainbone{}, \vtwodensegainbtwo{} and
\vtwodensegainbfour{}\,\% at budgets 1, 2 and 4---slightly \emph{more} than the sparse one-or-two-slot writes at
every budget, at roughly eight times the editor arithmetic---and gives the same exact match within noise
(Table~\ref{tab:stats}). Sparse local writing therefore buys nothing in quality at this scale; its only potential
advantage is cost, and Section~\ref{sec:results-latency} shows that this advantage does not materialise in
measured latency either. None of the adapters improves the held-out template, depth or compose regimes by more
than one point (H6).
Figure~\ref{fig:frontier} places the same runs on the quality-versus-analytic-cost plane: the global adapter is
both cheaper per step (one block at width $w$ over the whole latent costs less than two shared blocks with slot
re-keying for two lanes) and better at every budget, so it dominates the sparse editor along the entire frontier;
H4 is refuted at this scale for the comparison the proposal considered most important.
\input{tables/seed_matrix.tex}
\begin{figure}[t]\centering
\includegraphics[width=0.72\textwidth]{../results/figures/frontier_v2.pdf}
\caption{Quality versus analytic extra operations per token at the tiny scale (five adapter seeds, mean $\pm$ SD),
random forced budgets $b\in\{0,1,2,4,8\}$, context 160. Costs from \texttt{prisme/flops.py}; the sparse editor's
cost is the average of single and pair actions.}
\label{fig:frontier}
\end{figure}

\subsection{Oracle opportunity and the structure of intervention gains (Phase 5)}\label{sec:results-oracle}
Figure~\ref{fig:labels} and Table~\ref{tab:controller} summarise the counterfactual labels collected with the
fixed editor on a stream the editor never trained on (\labelstrainnstates{} and \labelscalibnstates{} exhaustive-audit
states in the training and calibration partitions). Three facts shape everything downstream.
First, the exhaustive one-step oracle finds real value: choosing the best of the 24 actions, or stopping when
none helps, gains \labelscaliboracle{} nats per state on calibration against \labelscalibrandom{} for a random
action; rolled out greedily on dev-iid it lowers the loss by \routingoraclebone{}\,\% with
\routingoracleeditsone{} edits per token at budget 1 and by \routingoraclebeight{}\,\% with
\routingoracleeditseight{} edits per token at budget 8 (Table~\ref{tab:routing}). The two-action oracle gains
\oracletwostep{} nats against \oracleonestep{} for one step, and ``greedy first action then best second'' recovers
almost all of it, so myopia of the one-step rule is not the binding constraint at this scale.
Second, most of the variance of the gains is between states, not between actions: \labelscalibwithin{}\,\% of
the variance of the audited gains is within-state (action identity), the rest is the state's mean gain;
\labelscaliballpos{}\,\% of states have all 24 actions positive and \labelscaliballneg{}\,\% have all 24
negative. Decomposing the oracle, a perfect continue/stop decision with a random action captures
\labelscalibstoponly{} of the \labelscaliboracle{} nats; the choice of \emph{which} slot captures the rest.
Third, opportunity is concentrated where the backbone is uncertain and is dangerous there: in states above the
median base loss the oracle gains \labelscaliboraclehigh{} nats while a random action loses
\labelscalibrandomhigh{}; in the top decile of base loss the oracle gains \labelscalibtopdecoracle{} and a
random action loses \labelscalibtopdecrandom{} nats, with only \labelscalibfracposhigh{}\,\% of actions helpful
(\labelscalibfracposlow{}\,\% in the lower half, where all gains are negligible).

\begin{figure}[t]\centering
\includegraphics[width=\textwidth]{../results/figures/labels_analysis.pdf}
\caption{Counterfactual labels (calibration partition, editor-unseen stream). Left: fraction of positive gains by
number of edits already applied. Middle: variance decomposition of the exhaustive 24-action audit. Right: mean
gain per state of a random action, of a perfect continue/stop decision with a random action, and of the
one-step oracle.}
\label{fig:labels}
\end{figure}

\subsection{Learned routing versus reference routers (H2, H3)}\label{sec:results-routing}
Table~\ref{tab:routing} compares, on dev-iid with the same editor, the frozen backbone, random, round-robin and
fixed-pair schedules at budgets 1--8, entropy and norm-change routers over a threshold grid, the learned value
controller at its locked penalty and along a $\lambda$ grid, and the diagnostic oracles. Three results follow.
(i) Spatial selection does not matter for fixed schedules: at budget 1 random, round-robin and fixed-pair give
\routingrandombone{}, \routinguniformbone{} and \routingpairbone{}\,\% respectively, within the paired
bootstrap noise of one another; more edits hurt (\routingrandombeight{}\,\% at budget 8). H2 is not supported.
(ii) The learned controller is worse than not routing: at its calibration-selected penalty
($\lambda=\routingctrllambda$) it edits \routingctrlledits{} times per token and \emph{raises} the dev-iid loss by
\routingctrllocked{}\,\%; every smaller $\lambda$ is worse still, although the same controller had lowered the
calibration loss by 1.1\,\% (Table~\ref{tab:controller}). The reference routers do no better: the best entropy
threshold gives \routingentropybest{}\,\% and the best norm-change threshold \routingnormbest{}\,\%. H3 is
refuted at this scale.
(iii) The mechanism of the failure is visible in the labels. With backbone-residual and entropy features the
controller predicts the \emph{sign} of a gain with \ctrlhentsignacc{}\,\% accuracy (chance 50\,\%) and finds
the states with opportunity, which are the high-loss states; but in exactly those states a wrong action costs
more than the right action gains (\labelscalibtopdecrandom{} versus \labelscalibtopdecoracle{} nats in the top
decile), and the controller's ranking of actions within a state is close to chance (top-1 agreement with the
oracle 7--8\,\% against 4.2\,\% for a uniform guess; captured fraction of the oracle opportunity $\le 5\,\%$).
The pre-registered null ``an oracle can find beneficial edits, but the learned controller cannot predict
them'' is the outcome at this scale.
(iv) The result replicates across adapter seeds on the second backbone (Table~\ref{tab:routingseeds}):
over \vtwoctrlseeds{} seeds the locked controller changes the dev-iid loss by \vtwoctrlrel{}\,\% (SD
\vtwoctrlrelsd{}) while editing a small fraction of tokens, the best fixed schedule lowers it by
\vtwobestfixedrel{}\,\% and the greedy oracle by \vtwooraclerel{}\,\%; the controller beats the frozen backbone
on \vtwoctrlbetter{} of \vtwoctrlseeds{} seeds and never approaches the fixed schedules at any cost.
(v) Adding within-state ranking losses (pairwise on the logged candidates, listwise on the exhaustive audits;
Appendix~\ref{app:failures}) did not change the picture: the locked policy edits 0.07 tokens and matches
budget 0 (0.4333 vs 0.4334), and every smaller penalty is worse.
\input{tables/routing.tex}
\input{tables/controller.tex}
\input{tables/routing_seeds.tex}

\subsection{Token loss versus task success}\label{sec:results-reasoning}
Exact match of free greedy generation moves with the loss on dev-iid but by less than the pre-registered
minimum effect of three points (Table~\ref{tab:stats}): the sparse editor gains $+1.9$ points at budget 2
(95\,\% $t$-interval over five seeds $[+1.6,+2.2]$; every per-seed paired item bootstrap excludes zero), global
recurrence gains $+1.9$ at budget 2 and $+2.3$ at budget 8, and the paired difference between the two systems
at budget 2 is $+0.1$ points $[-0.5,+0.7]$---a null---while at budget 1 global recurrence is ahead by $0.6$
points $[0.3,0.9]$. Transitions are two-sided: at budget 2 the sparse editor turns \vtwoprismetransplus{}
items per thousand from wrong to right and \vtwoprismetransminus{} from right to wrong
(Table~\ref{tab:emfamilies}); gains concentrate in \textsf{fsm} and \textsf{bind}, \textsf{excl} does not move.
No adapter changes the held-out regimes by more than a point, and the compose family stays at 2--3\,\%.
\input{tables/stats.tex}

\subsection{Pre-registered primary outcome on the locked test regimes}\label{sec:results-test}
The test streams (seed 9) were unsealed on 2026-10-30 after the pre-registration was frozen
(Appendix~\ref{app:prereg}); every system was evaluated once, at budget 0 and at forced random budget 2, on 1,000
stratified items per regime (Table~\ref{tab:test}). The pre-registered primary outcome---pooled exact match over
the iid, template and depth regimes at budget 2 versus the frozen backbone---is $\testprismebtwovsbzero$ points
for the sparse editor (95\,\% $t$-interval over \testprismebtwovsbzeron{} seeds
$[\testprismebtwovsbzerolo,\testprismebtwovsbzerohi]$), far below the pre-registered minimum effect of three
points; against the global-recurrence adapter the paired difference is $\testprismevsgr$ points
$[\testprismevsgrlo,\testprismevsgrhi]$ and against the dense editor $\testprismevsdense$ points
$[\testprismevsdenselo,\testprismevsdensehi]$. The compose regime stays at 4--5\,\% for every system. By the
decision rule fixed in advance, the architecture does not advance: it neither exceeds the strongest matched
baseline by three points at comparable cost nor reduces cost at non-inferior quality.
\input{tables/test.tex}

\subsection{Latency and memory}\label{sec:results-latency}
Table~\ref{tab:latency} gives measured batch-1 and batch-8 decode latencies for the tiny model on the
development laptop (Apple M5 Max, fp32, PyTorch 2.15, MPS). Budget 0 costs \latencybzero{} ms per token; each
executed single-slot edit adds about 2.3 ms, so eight edits cost seven times the backbone although their
analytic operation count is only 4.2 times; the dense sixteen-slot write at budget 8 is \emph{not} slower than
eight sparse writes (17.3 vs 19.3 ms), and one controller evaluation adds 2.9 ms even when it stops immediately.
At this scale the per-action host dispatch and kernel-launch overhead dominates the arithmetic, exactly as the
proposal's failure mode 13.6 anticipated; Section~\ref{sec:results-pilot} repeats the measurement at 103M, where
the arithmetic is 60 times larger per token.
\input{tables/latency.tex}

\subsection{The 103M pilot on web text (Phase 8)}\label{sec:results-pilot}
\input{sections/results_pilot}

\subsection{Larger configurations}
The 459M and 1.18B configurations were instantiated on the meta device for exact parameter accounting
(Table~\ref{tab:configs}) and the 459M operation table was reproduced (Table~\ref{tab:ops}); neither was
trained. No scaling claim is made (H7 untested).