SanSi: Looped Typed Decisions

Why People Wanted It

A typed decision model takes a state, a question, and a declared set of options, then returns probabilities over those options without generating an explanation. That contract is useful for classification, verification, and judging—but a single pass can fall short when the answer depends on following evidence through a chain. The real question is not only how to make the model think longer. It is how to add computation while preserving the typed decision interface, and how to make an answer available at intermediate computation budgets.

The Core Move

SanSi repeatedly applies one shared, loop-pretrained language-model stack to its evolving internal state, with a trained option-probability readout after every loop. The supplied pages do not give the state-update or readout equations, so the mechanism can be stated without adding formulas: each loop updates the state; each loop’s readout turns that state into probabilities over the declared options.

Why Looping Adds Computation Without Adding a New Stack

Here is the part that gets technical: the loop is a repeated application of the same transformer stack, not a sequence of separately parameterized stacks. Ouro-1.4B uses one stack of 24 transformer layers repeatedly; its normalized state after a loop becomes the input to the next, and the original input tokens are not injected again. Consequently, running more loops costs additional passes through that stack but does not add parameters. This preserves the typed contract: the model still returns option probabilities rather than generated reasoning text.

The backbone is frozen during SanSi training. LoRA adapters are trained on the attention and feed-forward projections, alongside the readouts. The paper reports 60.6M adapter parameters shared across loops and 0.27M readout parameters. These are implementation details of the reported setup, not requirements of looping in general.

Why Every Loop Needs Its Own Trained Readout

Now the deeper issue is what makes intermediate computation useful to a caller: SanSi reads option probabilities after every loop, with a separate small readout at each depth. A single run therefore exposes decisions at successive budgets rather than only a final answer. The option logits use the frozen language-model head’s rows for the option letters, with a trained low-rank correction and scale for each loop.

The paper’s Figure 2 illustrates why this matters: on its example, the first loop prefers the wrong option, while later loops prefer the correct one. Training only the last loop would leave early readouts without the same direct learning signal. In the reported comparison, training every loop gives 58.4% accuracy at loop one, while training only the last loop gives 35.6% there. The early result is not merely an accidental view of an unfinished hidden state; it has been trained as a decision.

Why Proper Scoring Rules Train More Than the Final Answer

Here is the training machinery: every loop is trained toward the target option distribution using the sum of cross-entropy and Brier score. Cross-entropy penalizes probability assigned away from the correct option, with a particularly heavy penalty for a confident error; the Brier score evaluates probabilities across all options and is bounded. Both are proper scoring rules: their minimum occurs when the predicted probabilities match the target distribution.

Targets are not always one-hot. They are one-hot for an item with a correct option, uniform when the evidence is insufficient, and the annotators’ label distribution for crowd-labelled items. Losses from the loops are backpropagated through the preceding loops. This couples the readouts to a shared evolving computation while directly supervising each available decision depth.

Minimal Causal Code

This sketch makes the repeated state update and per-loop readout visible. It leaves out the paper’s prompt construction, frozen head, LoRA details, and exact loss implementation.

state = embed(prompt)
probabilities_by_loop = []

for loop in range(num_loops):
    state = shared_stack(state)       # same stack, applied again
    option_logits = readouts[loop](state)
    probabilities = option_logits.softmax(dim=-1)
    probabilities_by_loop.append(probabilities)

What You Gain, and What You Lose

You gain a typed decision at selectable depths: callers can use an early readout or spend more computation on later loops. Reusing one stack adds computation without adding a new stack of parameters, and training every readout makes intermediate budgets meaningful. In the reported setup, loop three already captures 88% of the accuracy gain from loop one to loop eight.

You pay for repeated passes: the reported eight-loop model costs 7.7 times the computation of a single pass. More loops do not guarantee that confidence remains well calibrated; confidence can keep rising after answers settle. Nor does looping create a new stopping rule by itself: SanSi tests existing choices, including Ouro’s frozen exit gate. The tradeoff is extra iterative computation and multiple usable readouts, not a free replacement for a single-pass model.

Quiz

What is the defining architectural move in SanSi?

Choose an option without producing probabilities.

Apply the same stack repeatedly and provide a trained option-probability readout after each loop.

Generate a longer explanation before producing one final decision.

Add a separately parameterized transformer stack for every computation step.

$ check

Quiz

Why train a readout after every loop with proper scoring rules?

So the backbone must be updated independently at each loop.

So early-loop predictions are hidden from callers.

So every loop can provide a trained decision at its computation budget.

So the model can skip the typed options and generate free-form reasoning.

$ check