The Raw Is the Trust Boundary

“In God we trust; all others must bring data.” — W. Edwards Deming

Ask a model to summarise a document and you can hold the result against the document — the raw is right there. Ask it to write a feature and there’s nothing to hold it against but your own judgment, and it drifts to the mean — hand-rolled where the platform had a primitive, an effect where a plain value would do. Same model, same session. It’s tempting to call that “reads better than it writes,” but that’s not the mechanism, and the mechanism is the useful part.

There’s no reading organ and no writing organ. A model does one thing: take a sequence of tokens, produce the next, repeat. The summary is “written” the same way the feature is. So the difference isn’t the activity. It’s whether there’s a raw — a ground truth the output can be checked against.

Bottom line up front

• It’s all input → output. There’s no read/write faculty; there’s one operation. The real axis is whether there’s a raw to hold the output to.
• Reading tasks come with a raw. Summarise, review, extract — the input is the ground truth; the output is pinned to it, so its errors are checkable (not automatically absent — checkable).
• Generation comes without one. The output is drawn from the weights; nothing was handed in to check it against. The only ground truth is your experience — so you’re the raw.
• Trust tracks the pin. Fully pinned (summarise) → crisply pinned (find this in this code) → loosely pinned (“is this good?”) → unpinned (write from a blank prompt). How far you can trust the output follows the pin down.
• The whole discipline is manufacturing a raw. Rules, tests, examples turn your in-your-head standard into an external ground truth; a review pass is then the check run against it — so the check can leave your head and be delegated or mechanised.
• Two honest bounds: the model is a reliable checker against a crisp raw; it goes soft on open-ended judgment, and it can’t be its own raw — self-review doesn’t hold.

It’s all input and output — the difference is the raw

Strip the mysticism and the model emits high-probability continuations. When you hand it a document, it first encodes that input across every layer — the prefill — so the raw is literally sitting in the context. A summary is generated pinned to that encoded input: a selection and compression of something present, a small and grounded search you can check against the source. A blank-prompt “write me X” has almost nothing in the context to pin it, so the continuation is driven by the priors — pulled toward the most typical thing the training distribution has seen (what I’ve been loosely calling the mean). Same operation; wildly different amounts of ground truth in the room.

Reading-shaped tasks — summarise, classify, extract, review this for X — arrive with their ground truth: the input. Generation-shaped tasks don’t. The output came from the weights; there was no raw handed in, and the only thing to match it against is your own sense of what good looks like. You are the raw, and the judgment is matching what it produced to what you expected.

One qualifier: generation isn’t raw-less in principle. A test is a raw (does it pass?), a spec is a raw, the compiler and the runtime are raws. What’s missing by default is a raw for “is this what I meant, is this good” — and you are the default raw for that, until you manufacture an external one.

Trust tracks the pin

So reliability isn’t about reading vs writing; it’s about how tightly the input constrains the answer. A crisp criterion — “does this function drop any items?” — is a strong pin: a bounded check against something concrete. “Is this code good?” is a weak pin. “Write a feature” is no pin at all. This is the intuition behind what the field now calls the generator–verifier gap, or Jason Wei’s Verifier’s Law: for many tasks, checking a specific claim is a smaller, more grounded job than generating a good answer from scratch. It’s an asymmetry, not a theorem that holds everywhere — some things are as hard to check as to do.

I ran a small version of this. I took one paginated fetch, planted a specific data-loss bug in it, and asked blind reviewers — on two model tiers, a frontier model and a small one — to check it for correctness. Twenty for twenty caught it. Be precise about what that is and isn’t: it’s one planted bug, strongly pinned, that both tiers caught every time — evidence that a crisp criterion is a strong pin on this fixture, not proof that “the model is a reliable checker” in general (one bug × twenty runs can’t carry that). It also does not show “reads better than writes”: the writing task it’s set against was open-ended and hard, so that contrast only isolates task difficulty. The narrow, clean reading is the one I’ll lean on: crisp criterion, strong pin.

Manufacturing a raw

Once you see that trust tracks the raw, most of the discipline around AI stops looking like separate tricks and starts looking like one move: manufacture a raw for output that didn’t come with one.

• Tests are a raw for behaviour.
• Rules are your expectations encoded into a raw a reviewer can be checked against — that’s what makes them the asset (Rules Are the Alpha).
• A clean codebase is a partial raw: the model conditions on the surrounding code and matches it, so good code in pins good code out (Your Codebase Is the Prompt).
• A review pass isn’t itself a raw — it’s the check; but it runs the model against the raws you’ve made (rules, tests, criteria), catching after the fact what the generation had no ground truth to avoid (Keep the Factory, Ship the Result).

Each one takes a standard that lived only in your head and makes it external, so the check can be delegated to a model or a machine instead of costing you a read. The spine of all of it: externalize your raw where you can; the rest stays you. A raw doesn’t make the output right — it makes it checkable; the trust is earned when the check runs, not when the raw exists.

Which raises a question you have to answer for every raw you make: who is it a raw for? It’s easy to assume the answer is “both of us,” and that assumption is doing more work than it looks. BabelTele compresses text into forms a person can’t read and a matched model still can — 99.5% semantic fidelity at 27.9% of the original length. The authors are careful about the scope: the three properties (human-readability, natural-language fluency, machine-recoverability) come apart only partially, and the results hinge on the specific compressor–reader pairing and the task. Read narrowly, it still bites — under a matched pair, readability and recoverability separate. So a raw can pin the model beautifully and be useless to you at the moment you want to check the model, which is the moment this post says the trust is actually earned. That’s a trade, not a free compression win. Compress the raw and you’re deciding, on purpose or by accident, that this particular check is one you’ll never run by hand.

The two bounds

The model-as-checker is powerful and bounded, and the bounds matter:

• A crisp raw or nothing. “Find the data-loss bug” is a tight pin the model nails. “Is this well-designed?” barely pins anything, and there the reliability I’d claim falls away — the model can’t check against a raw you haven’t made concrete.
• It can’t be its own raw. Ask a model to review what it just wrote and it tends to bless its own mistakes; in the reasoning tasks they studied, Huang et al. found intrinsic self-correction without external feedback didn’t reliably help. The raw has to be independent of the writer — a separate check, a different model, a deterministic test.

What you keep

The model is trustworthy exactly to the degree there’s a raw to hold its output to. Reviewing against a crisp criterion has one, so you can hand that to the machine. Generating to a standard has none but you — until you encode one as a rule, a test, or an example. So the move is: give the model crisp, raw-backed checks; and everywhere there’s no raw yet, either be the raw or make one. The trust boundary and the raw boundary are the same line.

---

How sure I am: the PR (an agent’s feature, corrected commit by commit) and the small experiment are real, genericised. The experiment is bounded — one planted bug, one clean/mean pair, twenty blind reviews across two tiers of a single model family — and it supports only the narrow claim it’s used for: a crisp criterion is a strong pin the model checks reliably. It is not evidence that reading beats writing in general (that comparison is unpaired — an open task vs a closed one). “It’s all input and output / trust tracks the raw” is my framing of the mechanism, backed by the cited results, not a measurement. The self-review bound leans on Huang et al.; the generator-verifier framing on Wei and the surrounding literature — real, cited narrowly. BabelTele’s numbers are measured and theirs, and I’ve kept their qualifiers (partial decoupling, conditional on the compressor–reader pair) because dropping them would make the point bigger and wrong; the who is the raw for question I hang off it is mine.

Sources

• W. Edwards Deming — “In God we trust; all others must bring data” (widely attributed; the epigraph, not a load-bearing cite).
• Jason Wei, Asymmetry of Verification and Verifier’s Law (blog, jasonwei.net, Jul 2025) — some tasks are far easier to verify than to solve (an asymmetry, not a universal law); the generator–verifier framing the post leans on.
• Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet (arXiv 2310.01798, ICLR 2024) — intrinsic self-correction without external feedback doesn’t reliably help. The “can’t be its own raw” bound.
• Zhu, Peng, Wang, Ke, Zhang & Zhang, Large Language Models Do Not Always Need Readable Language (BabelTele) (2026, arXiv:2606.19857) — text compressed out of human readability that a matched model still recovers, at 99.5% semantic fidelity and 27.9% of original length. Cited for the narrow claim the paper makes: the three properties are only partially decoupled, and outcomes hinge on the specific compressor–reader pairing and task. Turning that into “so ask who your raw is for” is my extension, not their finding.
• Cobbe, Kosaraju, Bavarian, Chen et al., Training Verifiers to Solve Math Word Problems (2021), arXiv:2110.14168 — a trained verifier ranks generated solutions (GSM8K); cited as the generator–verifier gap in practice, by analogy, not proof about code review.

---

Related: Your Codebase Is the Prompt (a clean codebase is a partial raw the model matches); Rules Are the Alpha (rules = your expectations encoded into a raw); Keep the Factory, Ship the Result (the review pass is the check run against your raws, after the fact); Give Away the Writing (give away the generating; stay the raw); You Can’t Grade Your Own Misses (why it can’t be its own raw, human-side); You Can’t Save a Layout You Don’t Own (one concrete raw — the layout tree you keep, with the screen as its render).