Why AI outreach fails on true claims, not just hallucinated ones, and what I learned building a deterministic verification layer for it.
Artificial IntelligenceSalesStartup

The claim was true. I killed it anyway.

Ashutosh SinghalAshutosh SinghalJune 22, 202615 min read

The first email I ever refused to send was completely accurate.

I remember the sentence because I read it about forty times: "I saw you've recently grown your One-Way Truckload fleet to 2,735 trucks." Every word of it was true. Werner Enterprises really did report that fleet, in its own Form 10-K, filed with the SEC. And sitting in front of the demo I was building, I killed the claim anyway.

That decision felt wrong for about a day. Then it felt like the entire point.

Veracity Engine evidence panel showing the real Werner 10-K claim about growing the One-Way Truckload fleet to 2,735 trucks flagged stale because the cited filing is 842 days old, struck through and marked stripped in the draft email.
The claim I killed. The 2,735-truck sentence cites a real Werner 10-K, but the filing is 842 days old against a 365-day recency window, so "recently" fails and the line is stripped before send. Code made that call, not a language model.

I had started this project believing, like almost everyone building in AI sales right now, that the enemy was hallucination. The model makes something up, the false thing goes in the email, the prospect notices, your credibility dies. Catch the fabrications and you win. That framing is clean, it demos well, and I now think it is quietly responsible for a lot of burned sending domains. The Werner sentence had zero fabrication in it. It was still a claim I would never let leave the building.

This is an essay about what changed my mind, told the way it actually happened, which is to say slowly and with one embarrassing week in the middle. If you want to see the thing I ended up building, it lives here: veriprajna.com/demos/ai-sales-intelligence. But the product is the boring part. The interesting part is why a true sentence is not a safe sentence, and why I stopped trusting the model to tell the difference.

The week I tried to make the model grade its own homework

I spent about a week trying to get the language model to catch its own stale citations, and I want to be honest that it did not work.

The setup was reasonable on paper. A researcher agent pulls facts. A writer agent drafts the email, constrained to only those facts. Then a fact-checker agent reads the draft against the sources and flags anything that does not hold up. Three agents, a tidy pipeline, the kind of architecture that gets a nod in a design review. I genuinely expected the fact-checker to be the easy part.

It was the part that broke. Not loudly. That was the problem. The fact-checker would read the Werner draft, see a sentence about 2,735 trucks, find a source that said 2,735 trucks, and confidently approve it. Which is correct, if the only question is "does a source support this number." The model had no durable sense that the source was more than two years old and the sentence said "recently." When I pushed it to reason about dates, it would sometimes catch the staleness and sometimes wave it through, and I could not predict which. A checker you cannot predict is not a checker. It is a second opinion.

The moment it really landed was late one evening when I ran the same draft through the fact-checker three times and got two approvals and one rejection, with no change to the input. I stared at that for a while. I was asking a probabilistic system to be the deterministic gate on another probabilistic system.

I was asking an LLM to be the trustworthy referee for an LLM, and calling the result "verification."

That is not verification. That is two models agreeing, which is a different and much weaker thing. If the whole reason you need a checker is that the model's output cannot be trusted at face value, then a second model's output cannot be the thing you trust to check it. I had built a hall of mirrors and put a compliance sticker on it.

Which is worse, a made-up fact or a true one?

What surprised me most while building this was realizing the fabrications were never the scary failures. The true-but-misused claims were.

Think about what actually happens when an AI SDR hallucinates a company detail. Often it is nonsense, obviously off, the kind of thing a prospect reads and deletes. Embarrassing, sure. But the claim that gets you in real trouble is the one that is checkable and correct and still wrong in context. It sails through every "is this made up" filter precisely because it is not made up. The grammar is perfect. The number is real. And it is a lie about the present tense.

I started calling this contextual misuse, and once I had a name for it I saw it everywhere in the demo I was assembling. It has more than one shape, but every version shares the property that makes it dangerous: each is a true statement.

The shape that taught me the most is the stale source, and Werner is where I first saw it clearly. "Recently grew to 2,735 trucks" cites a real 10-K, but that filing landed on 2024-02-26, and against the demo's working date it is well over two years old. The number has not stopped being true. The word "recently" has stopped being true. Those are not the same fact, and a source-matching check treats them as identical.

I built the same shape a second time with a synthetic lead, a mid-market logistics company called Northwind, so I could show the pattern without pretending a real firm said something it did not. The draft claimed Northwind had "recently expanded into APAC." There is a real-looking source for it. The source is dated March 2019, which in the demo works out to roughly 2,652 days old, more than seven years. The grounding overlap between claim and source is a clean 100%. The entity matches. And it is still the kind of sentence that makes a prospect think you have not looked at them since the last World Cup.

Evidence panel for the Northwind APAC claim: grounding at 100 percent and entity match both pass, temporal validity fails at 2,652 days over the 365-day limit, verdict stale source, the claim struck through and stripped.
The same shape on a synthetic lead, so no real firm is misquoted. Grounding 100%, entity OK, and the temporal check still fails at 2,652 days. A true fact riding a source from 2019.
A true fact on a stale source is still a lie about the present. The date is part of the claim, whether or not the sentence admits it.

The other shape is the same-name collision, and I kept it as a synthetic case too. "Northwind Logistics just raised a $40M Series B" has a real source behind it. The source is about Northwind Inc., an Austin cybersecurity startup, a completely different company that happens to share a name. Every word is accurate about a Northwind. None of it is accurate about this one.

Evidence panel showing the $40M Series B claim failing the entity match check because the cited source is about Northwind Inc. and not Northwind Logistics, verdict entity mismatch, the claim struck through and stripped.
The same-name collision. Every word is true about Northwind Inc., an Austin cybersecurity startup, and none of it is true about Northwind Logistics. The entity check catches what a plain source-match never would.

Notice what all three examples have in common. Not one of them is a hallucination. If you built your entire safety story around catching fabrications, you would ship all three. This is the failure mode behind the AI-SDR flameouts everyone quotes and nobody quite explains. The single-pass tools do hallucinate a measurable slice of prospect-specific claims, somewhere in the range of 12 to 18 percent by one industry accounting (AI SDR Industry Report, 2026), but the fabrications are the failures you can at least imagine catching. The true-but-stale, true-but-wrong-entity claims are the ones that look like success right up until they cost you.

What made me stop trusting the model and start trusting a date subtraction

The thing that finally worked was almost insultingly simple, and I resisted it for longer than I should have.

If the problem with the Werner claim is that "recently" points at a source older than a sensible recency window, then the check is not a reasoning task. It is arithmetic. Take the source date, take the working date, subtract. If the claim uses recency language and the gap is larger than 365 days, the claim is stale and it does not ship. Source age 2652 days is greater than 365 days on a recency claim, therefore fail. There is no prompt, no temperature, no "as an AI language model." There is a number and a threshold.

Once I let myself write that, the rest of the checks wanted to be code too. Is the claim actually entailed by a source snippet, measured as token overlap against the content words, with the company's own name excluded so a sentence cannot score high just by repeating "Werner, Werner, Werner"? Code. Is the source about this entity and not a same-named other? Code. The language model is still the author, and it is a genuinely good author. It just is not the judge.

I ended up phrasing the principle two ways that I now say constantly. One is "agents advise, code decides." The other is "not an LLM judging an LLM." The neural network handles what neural networks are good at, which is writing a fluent, human draft. A deterministic, pure-Python verifier handles what code is good at, which is applying the same rule the same way every single time. Neural authorship, symbolic verification. The industry word for that pairing is neurosymbolic, though I care less about the label than about the property it buys.

Better models write better sentences. They do not make a two-year-old filing recent. That is not a capability gap. It is a category error.

And the property it buys is reproducibility. When I run the verifier on the same input, I get the same verdict, every time. That sounds like a small engineering nicety. It is actually the whole ballgame, because reproducibility is what makes a decision certifiable. I can hand you the trace. Source age 2652 days, greater than 365, recency claim present, verdict stale, claim stripped. You can rerun it and get the identical result. An LLM judge, even a good one, cannot promise you that. I lived through the three-runs-two-verdicts evening. I am not building a compliance story on top of it.

Signed JSON audit receipt with a Download JSON button, listing each claim's verdict, cited fact and source, published date and recency days, and every per-check result including source resolution, grounding, sentence faithfulness, entity match, and temporal validity.
The receipt the verifier writes for every email. Each claim, its verdict, the cited source, the dates, and the exact check results, exported as JSON you can download and rerun. Reproducibility is what makes it certifiable.

Isn't this just a hallucination problem in disguise?

I get asked some version of this in almost every conversation, usually by someone technical, and my answer has gotten shorter over time. No. And the reason it is not is the reason I think this work outlives the current model generation.

The hallucination framing quietly assumes the fix is a better model. Bigger context, cleaner training, lower fabrication rate, and eventually the problem shrinks to nothing. Maybe that is true for pure fabrication. It does nothing for the failures I actually care about. A perfect model, one that never invents a single fact, will still cheerfully write "recently" over a 2024 filing, because from inside the draft that sentence is true and fluent and exactly what you asked for. The model has no obligation to the calendar. The gap between "grew to 2,735 trucks" and "recently grew to 2,735 trucks" is not a gap that scale closes.

This is where the market keeps teaching the lesson the hard way. The AI-SDR category optimized hard for volume and for signal-based personalization, and it mostly skipped the step where you re-verify the resulting claim against a current, entity-correct source. The economics have not been kind. Enterprise AI-SDR churn runs somewhere around 50 to 70 percent a year (UserGems, 2026). The most-cited cautionary tale, 11x.ai, raised 74 million dollars and then came apart in 2025 with churn reported in the 70 to 80 percent range (TechCrunch). You do not post those numbers because your model hallucinated occasionally. You post them because the output looked personalized and was not trustworthy, and buyers eventually feel the difference even when they cannot name it.

So the thesis I keep coming back to is blunt. Personalization is not verification. Your AI SDR does not primarily have a hallucination problem. It has a verification problem, and a better base model will not fix it, because verification and provenance are not model capabilities. They are properties of the system you wrap around the model.

Personalization is not verification. Verification and provenance are not model capabilities. They are properties of the system you build around the model.

What "100%" is actually allowed to mean

I want to be careful here, because this is exactly the place where a founder is tempted to overclaim, and the company I am building is named for the opposite instinct.

There are two numbers in the demo and they are not the same number. The first is the Veracity Score, which is just supported claims divided by the total factual claims in the draft. It answers "how much of what the AI wrote turned out to be true," and on a real draft it is often well short of 100, which is the honest and useful thing about it. The Werner email loses its headline claim. The Northwind email loses two. That is the system working, not failing.

The second number is sent integrity, and it is 100% by construction whenever anything survives at all, because the policy gate strips every non-supported claim before the email is allowed to send. The guarantee is not "the AI was always right." The guarantee is "the email that goes out contains only source-backed claims." Those are very different promises, and I have watched people conflate them into a much bigger, much falser one.

There is also a benchmark, and here is the sentence I refuse to shorten: on a fixed, hand-labeled golden set of 25 cases, the deterministic verifier gets 25 out of 25 verdicts right. That is 100% on that labeled benchmark. It is not a claim about the open world, it is not a promise about your inbox, and it is emphatically not "zero hallucination," which is a phrase I think nobody honest should say. The model still drafts. Drafts still contain unproven claims. The point is that the unproven ones are caught and stripped, and the catch is deterministic enough to certify. Anyone selling you a zero-hallucination guarantee is selling you the thing I spent a week failing to build.

I will also say plainly, because the brief I hold myself to demands it, that the demo's connectors are simulated. The EDGAR pull, the news retrieval, the CRM write-back, the actual send, all stubbed. What is real is the mechanism: the checks, the gate, the audit trail, and the Werner 10-K excerpts, which are genuine public record. I am showing you how the engine decides, not a production pipeline with your data in it. If you want to watch it decide, it is here once more: veriprajna.com/demos/ai-sales-intelligence.

The question I am left with

I found that the last thing this build changed in me was smaller than the thesis, and it has stuck the longest.

There is a third lead in the demo, a synthetic FINRA-regulated broker-dealer, and its draft comes out completely clean. Every claim supported, nothing stripped, a perfect Veracity Score. And the policy gate still routes it to a human, because it is regulated and C-suite and a large deal, and the rule says a human looks at those regardless of how clean the draft is. The first time I watched a flawless email get held for review, my instinct was that the system had made a mistake. It had not. I had just assumed, without noticing, that correctness and safety were the same property.

They are not. A claim can be true and unsafe. A draft can be clean and still need a person. The whole job turned out to be separating those ideas and building for both, instead of collapsing them into one number that makes a good headline.

So the question I would leave you with is the one I now ask before any AI-written thing leaves my hands. Not "is this true," which I can usually answer and which usually is not enough. The harder one: can I prove, right now, which current source backs this exact claim, and would that proof survive someone who wanted it to fail?

If the answer is no, it does not matter how good the model gets. The sentence is not ready to send.

Related Research

Build Your AI with Confidence.

Partner with a team that has deep experience in building the next generation of enterprise AI. Let us help you design, build, and deploy an AI strategy you can trust.

Veriprajna Deep Tech Consultancy specializes in building safety-critical AI systems for healthcare, finance, and regulatory domains. Our architectures are validated against established protocols with comprehensive compliance documentation.