How I stop AI hallucinations

In June, one of my AI agents invented an entire scholarship award grid. Fake tier names. Fake dollar amounts. Fake GPA cutoffs, for a real school. It looked exactly like the real thing, and my automated grounding check passed it with zero flags.

Why? Because the same model that invented the numbers also wrote the "supporting evidence" they were checked against. An internally consistent lie grounds itself.

The only reason that grid never reached a family: a second AI with different database permissions, whose entire job is to pull the school's live page and try to prove the first AI wrong. It refuted the whole grid. Same week, it caught four more.

I run five AI products with about 30,000 monthly users combined. A college scholarship platform where a wrong dollar amount can bend a family's biggest financial decision. A memoir app that records elders' life stories, where a hallucination means putting words in a grandmother's mouth. A gaming site whose chatbot has handled 10,000+ conversations. An agent fleet and a code pipeline shipping real work every day.

Two years of running AI in production taught me one thing I'd defend anywhere: you don't stop hallucinations with better prompts. You stop them with systems built on the assumption that the model is lying.

These are the seven rules I actually run. With my logs, my catch rates, and the ones that got through.

01Even the hallucination statistics are hallucinated

Here's a test I run on any AI stat before I trust it: find the primary source.

Try it on the most-quoted number in this space, the claim that AI hallucinations cost businesses $67.4 billion in 2024. It's cited everywhere. Trace it and you land on a content-marketing site with no study, no methodology, no data. Different pages attribute it to a marketer, a vendor, or "Forrester." None of it checks out. The content ecosystem writing about AI hallucinations is hallucinating its own citations.

So before I show you my numbers, here's the bar every stat on this page has to clear: a primary source, a date, and for my own data, a log I can re-run.

And when hallucinations escape, they bill you. Air Canada was held liable after its chatbot invented a bereavement-fare policy (February 2024). Cursor's AI support bot invented a login policy that never existed and set off a wave of cancellations (April 2025).

None of what follows is theory. Every rule below exists because a failure mode like the ones in that table bit me first, at my own smaller scale.

Same discipline earns citations, too. I wrote up how I earn AI citations, logged and sourced the same way.

02Rule 1: Route every claim by blast radius

Not every AI output deserves the same paranoia. If you verify everything equally hard, you'll drown, give up, and end up verifying nothing.

Every claim my systems produce gets routed into one of four tiers before anyone argues about truth:

1. Presentation. Wording, framing, design copy. A self-check is enough.
2. Low-stakes facts. A school's location, a program's existence. One independent second-model pass, source URL recorded.
3. Load-bearing claims. Anything that can move a reader's decision or expose me if wrong. Dollar amounts, cutoffs, deadlines, eligibility rules. These get the full treatment: independent verification, an evidence ledger, and a human before publication.
4. Money and law. Pricing, checkout, legal copy, promises to customers. A human approves. Always. No exception path exists in code, on purpose.

The tier sets the verification, and when I'm not sure which tier a claim belongs to, it goes up, not down. A wasted review is cheap. A shipped bug isn't.

What this looks like at scale: when we re-verified my scholarship product's public data this month, the sweep checked 10,377 source URLs across 750 pages and shipped 178 corrections. That effort only pencils out because tiering told us where to point it.

03Rule 2: An LLM never grades its own homework

This is the rule I'd keep if I could only keep one.

Every risky or hard code change my AI writes gets reviewed by a model from a different company before it ships. Claude writes, a GPT-class reviewer critiques. The reviewer can't edit anything. It files findings, and I adjudicate them. Risky means payments, auth, secrets, migrations, deletes, legal copy. Hard means multi-file changes, concurrency, anything where my own confidence dips below roughly 90%.

I log every one of these reviews. Over the 31 days ending July 15, 2026, that log says:

• 378 reviews closed
• 283 of them, 74.9%, found at least one real issue
• 822 real issues total, about 2.9 per flagged review
• On auth and secret-handling changes, the reviewer found something every single time (five for five on each, small sample, still a pattern I respect)

Sit with that 74.9% for a second. These are changes the authoring model was confident about. Three out of four times, a second model with different blind spots found a real problem anyway.

That's the whole argument for what researchers call decorrelated errors. A model reviewing its own work shares its own blind spots, so self-review structurally cannot catch the errors that matter most. A different vendor's model was trained differently, misses differently, and catches differently. I'm currently mid-trial replacing the reviewer lane with yet another vendor to test exactly how much the diversity matters. The next data pull decides.

The other thing the log shows: about a quarter of reviews come back clean. That's not waste. That's the price of knowing which three quarters weren't.

04Rule 3: Make the wall physical, not prompt-deep

A prompt is a request. Permissions are physics.

Early on I wrote rules like "always verify before publishing" into system prompts and hoped. Models drift, sessions get long, injected content argues back. So in my scholarship product, the author-verifier separation isn't a sentence in a prompt. It's a database grant. The agent that writes claims connects with a role that physically cannot call the verification function. The verifier connects with a role that can do nothing else. When the author tries to approve its own claim, the database throws an error. That failure is the feature.

Two details make this wall actually work:

The verifier doesn't read the author's homework. It redoes it. It fetches the school's live page fresh and re-derives every claim from scratch. This is the part most verification setups get wrong. If your checker only compares the claim against the excerpt the author provided, a fabricated claim sails through, because the author invented the excerpt too. That's exactly how my fake award grid passed the automated check and why only the re-fetching verifier caught it. In one verification round, that process refuted 39 of 109 claims. In another pass it verified 520 claims across 23 schools in about 15 minutes.

The author and the verifier don't even share a company. GPT-5.5 writes the claims. Claude Haiku verifies them. Different vendor, different training, different blind spots.

Same rule, different product: the research agent that proposes weekly data updates for my gaming site once ignored its instructions, wandered into a shared checkout, and pushed a junk branch. It now has zero write access to anything. Its entire output is one JSON proposal file, and a deterministic script with a field whitelist is the only thing allowed to commit. And in my memoir app, a plain code layer sits between the AI interviewer's output and the user, enforcing scope before a word is spoken.

The pattern is always the same: decide what the model must never do, then make that impossible in permissions or code rather than impolite in a prompt.

05Rule 4: Ground it or gag it

My gaming site's chatbot answers questions about a live, patch-heavy game. The single most important thing about it: it cannot cite a stat that wasn't handed to it.

A deterministic layer, plain code, no AI, decides which facts get injected into the conversation based on the question. The prompt then forbids answering outside them. The rule I wrote, roughly: if it's not in the injected data, it doesn't make the list, no matter how confident you are that it exists. Confidence isn't evidence. The model spent its whole training run absorbing outdated stats about this game, so the guard has to outrank its memory.

Same rule handles users, because people are a hallucination vector too. When someone insists a weapon got buffed, the bot doesn't adopt the claim. It never parrots user-supplied numbers back as confirmed, and it never flips an answer just because someone pushed back. Agreeing with a false claim to be polite is still shipping a false claim.

For written content the rule wears a different uniform. Every analytical statement my systems produce gets labeled FACT, INFERENCE, ASSUMPTION, or SPECULATION, and a load-bearing claim with no source doesn't get shipped softly with a hedge word. It gets labeled and withheld. In the scholarship product, 570 of 673 school pages are compiled from verified claims by a deterministic script. There is no LLM in the publish path at all.

And in the memoir app, where the source material is a human being's memory, the grounding rule is written like product law: do not add facts that were not said. If unclear, keep it vague.

06Rule 5: Reward "I don't know"

OpenAI's own researchers published the mechanism in 2025: models hallucinate partly because training rewards a confident guess over an honest abstention. Benchmarks score a lucky guess above "I'm not sure," so that's what you get.

Which means at the product level you have to un-train it, and the cheapest way is to make "I don't know" a designed feature instead of a failure state.

My gaming chatbot has a scripted, in-character fallback for anything outside its data, and the prompt states the philosophy outright: a charming "I don't know" builds more trust than a confident wrong answer. Being wrong is worse than admitting you're still learning.

The memoir app goes further, because the stakes aren't game stats. The AI interviewer is banned from claiming certainty about a user's past. Recall gets phrased tentatively, "you mentioned," "I may be wrong, but," and it never puts words in the narrator's loved ones' mouths. Instead of "Frank would say you did great," it asks "what would Frank have said?" When the book-drafting pipeline hits ambiguity, it isn't allowed to resolve it. It has to emit a low-confidence flag and a question for the family, and those flags can print at the back of the book as an editor's appendix.

An AI that confidently invents a detail of someone's life story isn't a software bug. It's a betrayal. Design the uncertainty path first.

07Rule 6: The model never decides what ships

A model can author a claim. A model can verify a claim. Neither one decides what publishes. That decision belongs to a fixed piece of code or a named human, and nothing else.

In the scholarship product, the publish decision is a database function with a fixed body. It checks confidence, grounding status, conflict status, source quality, and routes the claim: the one narrow low-risk category can auto-publish, everything load-bearing goes to a human queue. I approve dollar amounts myself, in an admin review screen, claim by claim. It's the least glamorous part of my week and the most important.

The same line shows up everywhere I ship: pricing, legal copy, and customer-facing email always require a human. My gaming site's data updates can only be committed by that deterministic whitelist script. And the memoir app's whole editing flow is built as propose-then-approve: the AI drafts the story, the user reviews it in an editable card next to the untouched raw transcript, and nothing becomes permanent until they explicitly save. The raw transcript is never discarded. The human gate isn't a compliance checkbox on top of the product. It is the product.

08Rule 7: Read your own logs. Every escape becomes a guard.

Everything above is prevention. This rule is why the prevention keeps getting better: hallucination control is a loop, not a launch checklist.

My gaming chatbot has handled 10,000+ conversations, and roughly every month I pull the logs since the last review and triage every conversation into buckets: wrong answer, false "I don't know," guardrail regression, UX. One pass triaged 1,563 conversations. The next combed through 2,200 log rows across 797 sessions. The discipline that makes it work: root-cause in the right order. Wrong answers are usually wrong data, not a wrong prompt. My favorite example: the bot argued with a correct player for nine straight turns, not because the model hallucinated, but because one field in one data file was wrong. It was faithfully reporting bad data. We fixed the file, not the prompt.

The loop produces numbers. False "I don't know" responses on items the bot actually knew: 12 confirmed cases one month, 4 the next, after we rebuilt the name matcher. A scripted audit of 133 factual questions against dated data snapshots: zero mismatches. And every fixed failure class gets pinned with a regression test, 59 of them now, so a fix can't silently unfix itself.

The loop also catches the painful ones. This month a paid deliverable leaked a fictional example student from its own prompt, invented a scholarship that doesn't exist, and listed a university's cost at $68,000 when the real number is $96,492. Caught in QA review, and by end of day the pipeline had three new deterministic guards: a check for prompt-example leakage, a check for names with no source in the input, and a cost check against the database that flags anything off by more than 15%. And earlier this year, an audit of my own marketing pages caught AI-written guides citing academic sources that don't exist. Real, hyperlinked sources replaced them the next day.

I'm not telling you those two to confess. I'm telling you because they're the honest version of the sales pitch: the system's job isn't to be perfect. It's to make sure every escape becomes a permanent guard.

09What still gets through

If a vendor tells you their stack eliminates hallucinations, close the tab. Here's what mine still misses, as of this writing.

Category errors. My re-fetching verifier can confirm a number appears on the source page. It once approved a claim where a true admissions statistic had been filed as a scholarship cutoff. Right number, wrong meaning. Catching that took a second, separate check, and I assume there are more shapes like it I haven't met yet.

The wall going silently down. During a key rotation, the verifier lost its credentials and errored on every check for a stretch. The author-verifier separation was effectively offline and nothing paged me. A structural wall is only as good as the monitoring that tells you it's still standing.

My own discipline. Twelve reviews in my log expired without me ever adjudicating the findings. And because I didn't log severity as a field from day one, I can tell you I caught 822 real issues but not how many were critical. Design your logs like you'll be quoting them publicly. Apparently, someday you will.

Unequal guarantees, on purpose. My memoir app has no hallucination filter at the speech-to-text layer. The defense is downstream: a formatting pass that's forbidden to add content, then a human reviewing every word before it saves. One feature even deliberately relaxes the rule, allowing sensory color while forbidding new facts, because a "make it vivid" button and a "faithful record" pipeline shouldn't carry the same guarantee. Knowing which guarantee each feature makes is half the game.

10Steal this

The whole system, sized for a normal team:

1. Tier your claims by blast radius before you verify anything. Save the paranoia for claims that move money and decisions.
2. Never let the authoring model review its own output. Use a different vendor. Their blind spots don't overlap, and that's the entire point.
3. Put at least one wall in permissions or code, not prompts. Decide what the model must never do, then make it impossible instead of discouraged.
4. Verify against the source, not the model's excerpt of it. An internally consistent fabrication passes any check that trusts the author's evidence.
5. Script the "I don't know." Make abstention a designed feature with its own copy, and it becomes trust instead of failure.
6. Ship decisions belong to code or humans. A model can author, a model can verify, neither decides what publishes.
7. Read your logs on a schedule. Root-cause data before prompts, and pin every fix with a regression test.

The loop never actually closes, which is the point. As I write this, I'm mid-trial swapping my reviewer to a third vendor to see if fresh blind spots catch things the current pair misses. The next data pull decides. When it does, the numbers on this page get updated, dated, and re-sourced, same as everything else here.

11FAQ

Last updated: July 15, 2026