Prediction has no reverse

Jul 20
9 min read

An LLM neither reasons nor verifies. These are not two separate limitations — they are the same architectural property, viewed from two angles.

I published two articles on Medium that seemed to address different problems.

The first, Le cadavre exquis — pourquoi un LLM ne raisonne pas (January 2026), argued that language models don't reason. They continue. The game of exquisite corpse — where each player adds a word to a sentence no one controls — is the clearest model of what a transformer actually does.

The second, Un modèle de langage ne distingue pas le vrai du probable (June 2026), argued that models can't distinguish what they know from what they invent. Their errors carry no internal signal. A correct answer and a fabricated one arrive in the same form, with the same assurance.

When I wrote them, I treated these as two separate arguments. One was about the process — the model has no plan, no objective, no criterion for stopping. The other was about the output — the model has no access to truth, no way to verify what it produced.

They are two faces of the same mechanism, and recognizing that changes what needs to be built.

Face A — the process: an LLM doesn't reason

In the exquisite corpse article, I made the case that the game of exquisite corpse is not a metaphor for how a language model works — it is a precise description.

In the game, each player adds a word to a sentence. No player has the full sentence. No player has a plan. No player knows when the sentence is finished, or whether it succeeded. Each player only has the partial sentence so far, and from that state, picks a word that seems compatible.

A language model does exactly this. At each step, it receives a context — the prompt, the conversation history, the tokens it has already generated — computes a probability distribution, and selects the next token. It doesn't know where it's going. It doesn't know what it's doing. It continues.

The key argument was that reasoning, properly defined, requires at minimum three things:

An explicit, detectable objective — something the process is trying to achieve.
Invariants capable of constraining the trajectory — stable references that survive across steps.
The ability to suspend, invalidate, or backtrack — a way to recognize failure and recover.

A language model has none of these. It has no objective. It has no invariants — every token is produced by recomputing attention over the full context, and nothing persists as a constraint on what comes next. It cannot backtrack. A brilliant justification produced at token N does not become a rule at token N+1. It becomes text — reabsorbed into the context, treated like any other fragment.

Chain-of-thought prompting makes the continuation look more reasoned, but it doesn't create reasoning. It regularizes the linguistic trajectory. The model produces justifications that are more readable, more structured, more convincing — but a justification is not a guarantee. The chain-of-thought is itself text, subject to the same dynamics as everything else in the context. It influences the next tokens exactly like any other context, without any special status.

The conclusion of that article was precise: the limit is architectural, not a training defect. The transformer computes attention at every step, produces a token, and moves on. There is no persistent logical state. No recognized conclusion. No objective carried through time. The model can produce trajectories that resemble reasoning, but it operates in a different regime — one of probabilistic continuation, not of held intent.

Face B — the output: an LLM can't tell true from probable

In the second article, I approached the same model from a different angle: not what it does while generating, but what it can say about what it has generated.

The argument was straightforward. A language model is not trained to tell the truth. Its base objective is to predict the next token — to make probable what was actually written in the training corpus. Its target is plausibility: what resembles what a human would have written. This is not an engineering oversight. There is no mathematical function that encodes truth inside the model. We can write a function that measures the gap to a corpus, or the agreement of a human evaluator. We cannot write one that measures truth. Where truth is verifiable — in mathematics, in programming — it is supplied by an external control that catches errors. The model then learns to satisfy that control, not to know the truth. Elsewhere, truth is neither available at scale nor even definable.

At the moment of producing an answer, nothing corrects this. The model proceeds word by word: for each candidate, it evaluates the probability that it comes next, then picks one. This chain contains no verification step. The model does not confront its output against any fact base. It extends the most probable continuation. When it doesn't know a fact, it fills the gap with a plausible continuation.

Human feedback alignment (RLHF) doesn't fix this. It optimizes for what an evaluator finds satisfying in a few seconds. But satisfying and true overlap only partially. A clear, confident, well-formulated answer is rewarded because it looks right. An exact but hesitant answer may be judged inferior to a wrong but confident one. An error that looks right passes through alignment, because alignment rewards the appearance of correctness.

The result is structural indistinguishability. A correct answer, an approximate answer, and a fabricated one arrive in the same form, with the same fluency, the same confidence — nothing in the shape of the response separates what the model knows from what it invents.

This is why the common advice — "AI helps when you already master the subject" — is not a stopgap but a permanent condition. To catch an error, you need to already know the correct answer. The model produces; the user sorts, within the limits of their own knowledge. Beyond those limits, errors pass unnoticed.

And here was the counterintuitive conclusion: a better model doesn't reduce this requirement. It increases it. A more accurate model produces errors that are rarer but subtler, in places you wouldn't expect. The verification becomes less frequent but more demanding. And worse: the model's accuracy itself erodes vigilance. When a model is right 99% of the time, you stop looking for the 1%. But the 1% hasn't become visible — it has just become rarer. The rarity of errors reduces suspicion without making errors detectable. A more accurate model is, paradoxically, harder to monitor than a less accurate one.

The bridge

These two arguments look like they address different problems. One is about how the model generates. The other is about what it can say about what it generated.

They are the same limitation.

The exquisite corpse doesn't know where it's going. The plausibility machine doesn't know whether what it wrote is true. These are not two independent deficits. They are two consequences of a single architectural fact:

Prediction is a forward-only process. It has no access to its own trajectory, and no access to the truth of its own output.

Consider what "having a reverse" would mean for each face.

For Face A — reasoning — the model would need prospective access: the ability to hold an objective ahead of the next token, to carry an invariant across steps, to recognize when a trajectory has failed and backtrack. This is what reasoning requires. The transformer has none of it. It computes attention, picks a token, and the state is gone. Nothing looks forward. Nothing persists.

For Face B — truth — the model would need retrospective access: the ability to look back at what it just produced, evaluate it against something outside itself, and mark it as correct or incorrect. This is what verification requires. The transformer has none of it. It produces a token and moves on. Nothing looks back. Nothing checks.

Now observe the symmetry:

	What's missing	Direction of access	Consequence
Face A (reasoning)	Objective, invariant, stop criterion	Forward (prospective)	The model can't guide its own trajectory
Face B (truth)	Verification, fact-checking, error marking	Backward (retrospective)	The model can't validate its own output

The exquisite corpse's indistinguishability — a meaningful word and an absurd one written with the same confidence — is the same phenomenon as the plausibility machine's indistinguishability — a correct answer and a fabricated one delivered with the same fluency. Not because the signal is weak, but because the architecture that would produce it doesn't exist.

A prediction has no reverse. It can't look back at what it did and ask "was that right?" And it can't look forward at where it's going and ask "is this what I meant to do?" The absence of both is the same absence. The transformer runs in one direction, and in that direction, there is no self-reference.

The paradox of improvement

Once you see the two faces as one, the standard optimistic argument — "models will get better" — lands differently.

Better models predict more accurately. More accurate prediction means:

Fewer errors, but errors shifted to rarer, subtler cases (Face B)
More coherent trajectories, but trajectories still carried by no invariant (Face A)
Higher fluency, which makes the indistinguishability worse, not better

The improvement acts on the quality of continuation. It does not act on the nature of the mechanism.

The two traps mirror each other precisely. Chain-of-thought makes the model look like it's reasoning — but the chain is text, not a held idea. Accuracy makes the model look like it's reliable — but it reduces suspicion without making errors visible. In both cases, the model produces output that resembles what reasoning or verification would produce, but the mechanism that would make it genuine — the reverse, the self-reference — is absent. Improvement makes the resemblance better. It doesn't install the mechanism.

This is the crucial point: the improvement of the model and the improvement of the architecture are not the same thing. A better predictor is still a predictor. It predicts more, it predicts better, it predicts with fewer visible errors. But it still has no reverse.

What this implies architecturally

If the two limitations are the same architectural property, then the fix is not "better data" or "more parameters" or "better prompting." Those act on the quality of the forward pass. The missing piece is structural:

The architecture has no self-referential loop.

A transformer runs: predict → output → predict → output. At no point does it evaluate its own output against something external. At no point does it hold an objective that constrains the next prediction. The loop is:

predict → produce → discard state → predict again

There is no

predict → evaluate → correct

hold objective → predict → check against objective → adjust

What's missing is not a bigger forward pass. What's missing is the other half of the loop:

An objective that persists across tokens. Not a prompt — a prompt is text, absorbed into the context like everything else. An architectural invariant: something that sits outside the generation stream, is not overwritten by the next token, and constrains the trajectory.
A verification path. The ability to take what was just produced, compare it against a ground truth that lives outside the model's own distribution, and mark it. Not confidence — confidence is just a property of the distribution. A check: "this output corresponds to a fact" or "this output does not."
A self-monitoring signal distinct from fluency. The model's own uncertainty is currently indistinguishable from its fluency. A well-written wrong answer and a well-written right answer feel the same — to the model and to the reader. The architecture needs a channel that separates "I produced this fluently" from "I can verify this is correct."

None of these are exotic requirements. Thermostats have objectives. Databases have verification paths. Compilers have self-monitoring signals. The fact that we don't think of these as "AI" is itself a symptom of the problem — the field has equated intelligence with the forward pass of a predictor, and forgotten that intelligence in every other system includes the reverse.

The assumption that "scale + data → reasoning" is not just optimistic. It's architecturally incoherent. Scaling a forward-only process makes it a better forward-only process — it does not give it a reverse.

This is not an argument against language models. They are useful, powerful, and will get better at what they do. It is an argument against confusing what they do with what they appear to do. A predictor that predicts well is a good predictor — it is not a reasoner, not a verifier, because reasoning and verification require what prediction structurally lacks: a reverse.

Changing the frame

The two articles I wrote months apart each identified a wall. One said: the model doesn't reason, it continues. The other said: the model doesn't verify, it generates plausibly. What I see now is that both walls are the same wall, and it has a name.

Prediction has no reverse.

That sentence changes the question. The question stops being "how do we make the model reason better?" — because the model doesn't reason, and improving its predictions won't make it reason. The question becomes: what do we build around the predictor to give it what the predictor cannot give itself?

Not a better prompt. Not a larger model. An architecture that carries objectives, verifies output, and separates confidence from truth.

That is a different kind of work. It is not the work of training. It is the work of design.

Mickaël Mahabot