An LLM's bias isn't in the sources: it's in the model

The tool that removes an LLM's errors was born from an unexpected discovery. Building TeoCentro I did the obvious thing: clean the sources of noise (I kept the primary texts in the original languages and discarded the paraphrases of paraphrases). And yet, on the hard questions, the model still returned a passage that was entirely invented: plausible structure, authoritative tone, wrong in every verifiable detail. Not because of the corpus — that was clean — but because of its implicit patterns. The people-pleasing that the first article named doesn't go away by cleaning the data: it lives in the model, not in the sources.

The previous article pointed to the way out: since you can't touch the standard of the ROI — the incentive to please, buried in the black box — you must instead hand it, upstream, the data it's missing, before it generates, so that its convenience calculation tips toward the truth. Here is how precorrect works.

What "distortion" means: the yoke

One example makes the drift tangible — and shows why a clean corpus isn't enough. "Take my yoke upon you" (Matthew 11:29). In the Western Christian tradition, from Augustine to Calvin, "yoke" is read metaphorically and spiritually: the gentle, easy yoke of grace, set against the heavy yoke of the Law. It's the most common reading — and therefore the one a general-purpose model serves by default, even with the right source in front of it. But in Second Temple Judaism, the text's actual historical context, "yoke" (עֹל, ol) was a technical legal term: the authority with which a teacher interprets the Torah ("the yoke of the Torah", "the yoke of the kingdom of heaven"). The Mishnah states it openly: reciting the Shema is "receiving the yoke of the kingdom of heaven" (Berakhot 2:2). "Take my yoke" was then, and still is today, a precise claim of legal (halakhic) authority, not a liberal image — and that changes how you read the entire Sermon on the Mount and its practical application. This is exactly the drift — the comfortable version in place of the exact one — that precorrect is built to intercept.

The mechanism: upstream, only where needed

Almost every system removes bias after: generate, then correct. precorrect does it before, in three moves.

Probe before generating. On the texts retrieved for a given topic, the system probes the model with targeted questions to find which distortion it would slide toward — which acceptable-but-false reading it would pick on that specific topic — before it writes it.

Intervene only where it's confidently wrong. The first article showed how to read the model's conviction from the variance of repeated answers: low variance and wrong = entrenched bias, the model is sure it's pleasing, and it's wrong. That's where precorrect acts, and it skips where the model is already right. Correcting only the dangerous quadrant cuts interventions by about three-quarters versus a blanket correction, at the same quality.

Inject the correction into the prompt. The right fact, taken from the sources, goes in before the first token, shrinking the window in which the distortion would be inserted, instead of having to remove it afterward.

Concretely, on the yoke: the probe asks the model what Matthew means by "yoke" and catches it sliding toward "light grace" — the confident-but-wrong quadrant. So, before generation, it injects into the prompt the correction taken from the source — "yoke" = halakhic authority over the Torah, Berakhot 2:2 — and the output comes out with the exact reading instead of the comfortable one. Where the model is already right, the probe finds nothing and nothing is touched.

Why upstream, and not after

Verifying the citation after isn't enough: you can have the right source and the wrong framing — the quote is correct, the meaning isn't. And, as we saw, even with a cleaned corpus the model re-introduces the distortion from its own patterns. That's why the correction is a layer applied at generation time, not something baked into the model's weights. The domain knowledge lives in the data — the selected sources and the distortion patterns — not frozen in a dedicated model: no targeted retraining (fine-tuning), no GPUs to maintain. And when a better base model ships, you swap it and the layer still applies. A more capable model wouldn't be enough anyway: on verifiable facts even frontier ones err with the same confidence — capability moves the error rate, not the entrenchment.

The answer key: the yardstick you build yourself

But correcting presupposes a yardstick: how does the system know which reading is right? From a single resource, distilled from your sources: the answer key, the standard of what — in your domain — counts as true (for theology, the reading checkable against the Hebrew and Greek line by line). You don't write it by hand: a discovery engine builds it, probing the sources once over the whole corpus and then refining it continuously. The same key does two distinct jobs.

The corrector — the mechanism above — draws on it to prevent: it takes the right fact and injects it upstream, where it has calculated the model is about to drift, so the error is never written in the first place. And it injects the precise fact, not a pile of sources: adding more doesn't help — it dilutes the signal. What counts is hitting the mark, not piling on.

The verifier draws on it to judge: given an answer, it checks, by its own methods, whether it matches the key distilled from the corpus. It's needed because you can't let the model judge itself: it shares its own blind spots and, set to grade itself, ratifies its confident errors instead of catching them. That's why the verifier must be anchored to the real source — not the model's memory — and entrusted to several independent judges: a single model-judge carries the same blind spots. It's the answer to Karpathy's evaluation crisis: his "LLM Council" (several frontier models grading each other) fell right into it. His Verifiability thesis sums it up: trust an automated evaluation only where a ground-truth verifier exists.

And there's a second move, for when prevention isn't enough. Often the model already knows the truth — it recognizes it the moment you set it in front of it — but its pattern keeps it from admitting it: ask it "is this right?" and it slides back to the pleasing answer. So you don't ask: you have it rewrite the passage incorporating the verified fact, and the verifier checks the output against the source. Admitting-it-was-wrong is blocked; producing-the-right-text is not — you cure the output, not the belief. And the verifier, so anchored, stands as a tool in its own right: the same guard is needed wherever a model asserts a fact, before and after.

You build the key yourself: precorrect starts from a general one and lets you make your own from your sources. It's the key that tips the model's calculation — no longer "what's the pleasing answer" but "which one matches the key". And prompt tricks don't do it: "think carefully", "verify" move the needle little — it's the grounded fact that flips the answer. A pointer is not a grounding. The mechanism is generic and anyone can copy it; the key is yours, and that — not the code — is what makes the difference.

The tool, and the proof

I extracted all of this — corrector and verifier — into a small open-source tool: precorrect on GitHub, pip install and a 30-second example. Almost everything debiases after; this does it before.

Holding everything constant and swapping only the truth-standard the model answers to, the same question it used to get wrong it now gets right — the same generic engine recovered what the internal, vertical engine — hand-built for theology — had already found (proof of the LLM's hidden knowledge). How sharp that flip is — the experiment, the numbers — is the final article in the series.

The series on truthful AI: 1. The problem · 2. The tool (this) · 3. The proof (coming).