How I stop AI hallucination without waiting for a better model

Why I stopped waiting for a better model

Early on, my working theory was that hallucination was a temporary problem that better models would eventually solve. I was wrong, or at least wrong about the timeline, and waiting cost me nothing but time I didn't need to lose. Every model I've worked with, across multiple generations of meaningful improvement, will still confidently state something false if you let it operate without constraints. The improvement curve is real, but it's a curve, not a cliff, and legal work can't tolerate confident falsehoods in the meantime.

What changed my approach was realizing that the fix doesn't live in the model at all. It lives in what you let the model do and how you structure what happens around its output. A model that can invent a case citation from nothing can't invent one if it's only ever allowed to select from a verified, retrieved set of citations you control. That's the whole idea behind what I call evidence anchoring: constrain the system so that fabrication isn't an available move, rather than hoping the model chooses not to fabricate.

What evidence anchoring actually means in practice

Evidence anchoring, as I build it, has one governing rule: any system that states a fact must be able to point to exactly where that fact came from, and that pointer has to be checkable by a human in seconds, not minutes. Not a vague reference to 'the file' or 'prior research,' a specific document, a specific page or clause, a specific line.

In a computed module I built for a real estate practice, every clause the system suggested for a lease came with a direct link back to the source precedent document and the specific prior matter it was pulled from. If the system couldn't find a grounded source for a suggestion, it was built to say so explicitly rather than generate something plausible-sounding to fill the gap. That single design choice, forcing an honest 'I don't have a source for this' over a confident guess, eliminates the majority of hallucination risk before you've done anything else.

How I actually build anchoring into a system

1. 1. Constrain the retrieval pool

   Don't let the system pull from the open internet or its general training knowledge for anything fact-specific. Point it only at a defined, vetted set of documents: your own precedent library, the specific case file, the specific statute text you've loaded in. If it's not in the pool, it can't be cited.

2. 2. Require inline sourcing on every factual claim

   Structure the output format so that any statement of fact must carry a citation to a specific document and location in the same breath. If the format makes an unsourced claim awkward or impossible to produce cleanly, most of the hallucination pressure disappears.

3. 3. Build an explicit 'no source found' path

   Design the system so that admitting a gap is the easy, expected output, not a failure mode it tries to avoid. I tell every system I build to say so and stop, rather than reach for a plausible-sounding fabrication, whenever the retrieval pool comes up empty.

4. 4. Add a verification checkpoint before anything leaves the system

   Even with anchoring, put a human review step between generated output and anything that reaches a client or a filing. This isn't redundant with anchoring, it's the backstop for the anchoring logic itself failing or being misapplied.

5. 5. Spot-check the citations, not just the prose

   The review step should specifically click through a sample of the citations, not just read whether the output sounds right. Fabricated-sounding text is often easy to catch; a citation that looks correct but points to the wrong clause is not, unless someone actually checks it.

Where I see practices get this wrong

The most common mistake is treating a good prompt as a substitute for a constrained retrieval pool. A prompt that says 'only cite real cases' or 'don't make anything up' is a request, and models under uncertainty will still sometimes produce something confident and wrong despite that request. The instruction has to be backed by an actual structural constraint on what the system can access, not just a polite ask layered on top of unrestricted access.

The second mistake is skipping the verification checkpoint because the anchoring feels thorough enough on its own. I've seen this fail in subtle ways: a system correctly cites a real document, but the passage it pulled from that document has been taken out of context in a way that changes its meaning. Anchoring reduces fabrication; it doesn't eliminate every way a system can mislead. The human checkpoint is what catches the more subtle failures anchoring alone can't.

The honest goal is catchable errors, not zero errors

I don't tell clients that a well-anchored system will never produce an error. That's not a promise I can make about any tool built on a language model, and I distrust anyone who makes it. What I promise instead is that every error will be structurally catchable: sourced, traceable, and positioned in front of a human checkpoint before it can do damage.

That reframing matters because it changes what you're building toward. You're not chasing a mythical error-free system. You're building a system where the errors that do occur are visible, attributable to a specific traceable claim, and stopped before they leave the building. That's an achievable, verifiable standard, and it's the one I hold every system I build to.