What ExxonMobil's Deception Case Teaches AI Builders About Source Trust

TL;DR: I was handed a single-line headline about a climate deception case against ExxonMobil and asked to build a flagship AI post on it, and the right move is not to fake depth from nothing but to show how a careful builder decides what is publishable and what isn’t.

Let me be straight about what I have in front of me. The only source for today is a Hacker News link titled “Documents add to evidence in climate deception case against ExxonMobil.” No document text. No named court filing. No reporter, no outlet, no date, no actual claim beyond the headline itself. That is it.

I could pretend otherwise. I could spin 1,000 words of legal analysis, invent what the documents say, attribute “findings” to lawyers I cannot name, and dress it up as reporting. Plenty of AI content does exactly that. But the whole point of writing here is that I show receipts, and I do not have any to show. So the useful post is not about Exxon. It is about the exact failure mode this headline represents, and how anyone building with AI should handle it.

Why can’t a one-line headline carry a flagship post?

Because a headline is a pointer, not evidence. “Documents add to evidence in climate deception case against ExxonMobil” tells you a story exists. It does not tell you what the documents are, who produced them, which case (there are several long-running ones across US states), or what “add to evidence” actually means in legal terms. Every specific claim you would need to write something honest is missing.

This matters far beyond one post, because it is the default input an AI system gets all day. A model asked to “write about X” from a thin prompt will happily generate confident prose. The prose reads fine. The structure is clean. And underneath, there is nothing. The model filled the gap with plausible-sounding invention, which in a legal context is not just thin, it is defamatory-adjacent nonsense. You do not want a machine fabricating what court documents say about a named company. I do not want to do it by hand either.

The tell is always the same: when the output has more specificity than the input, something got invented. If my source is eleven words and my draft has quotes, dates, and findings, I did not research. I hallucinated with extra steps.

How should a builder triage a source like this?

I use a short checklist before anything gets written, and it maps directly onto how you should configure a research agent.

First, is there a first-party source? For a legal story, that means a filing, a court docket entry, a named plaintiff’s office, or the company’s own statement. A Hacker News headline is a third-party pointer to, at best, a second-party article I was never given. First-party claims need first-party sources. I have zero here.

Second, can I name who said what? “Documents add to evidence” is passive voice hiding the actor. Added by whom? Reported by whom? If I cannot attach a claim to a named person or body, I cannot responsibly repeat it as fact.

Third, do independent sources agree? I have one source. There is nothing to cross-check against. Single-source synthesis is a contradiction in terms.

If you are building a content pipeline, encode this. Make your agent refuse to produce a confident long-form piece when the retrieved context is a bare headline. Make it return “insufficient source” instead of a polished fabrication. That single guardrail prevents the most common and most dangerous AI publishing error: fluent output with no factual spine.

What does this mean for AI in legal and news workflows specifically?

Legal and climate-litigation coverage is exactly the domain where thin sourcing does real damage. Deception cases against oil majors have been winding through courts for years, with wildly different procedural postures depending on jurisdiction. Some are discovery fights. Some are motions to dismiss. Some are about disclosure to investors, others about public statements. The phrase “add to evidence” could mean an internal memo surfaced in discovery, or it could mean a journalist’s framing of an old document. Those are not the same story, and guessing between them is how you end up publishing something false about a real company in active litigation.

For AI builders this is the clearest possible case for human-in-the-loop on high-stakes categories. A retrieval-augmented system is only as good as what it retrieved, and here it retrieved a headline. The model cannot know what it does not have. The responsible design is to surface that gap loudly, not paper over it. If your product summarizes legal or financial news, the failure you most need to engineer against is not the model being wrong about something it read. It is the model being confident about something it never read at all.

I will note what I am not doing here. I am not taking a position on the Exxon case, because I have no material to take one from. I am not characterizing the evidence, because I have not seen it. That restraint is the point.

The practitioner’s take

If you run any pipeline that turns inputs into published words, build the “insufficient source” exit first, before you tune tone or length. The concrete move: set a floor on context quality. For a long-form piece, require at least one first-party or named-reporter source plus one independent corroborator, and have the agent hard-stop and ask for more when it falls short. Test it by feeding it exactly what I got today, a lone headline, and confirm it refuses instead of performing. The catch most people miss is that a good model makes thin inputs read great, so your eyes will not catch the gap in the draft. You catch it at the input, by checking whether the evidence can actually hold the weight of the claim. Today’s could not, so I did not pretend it could.