← Blog
Posts

An AI writing tool should know where its facts came from

Before paying, ask where each claim came from

Ghaith Ayadi · 06 Nov 2026 · 5 min read

In February 2024, a Canadian tribunal ordered Air Canada to compensate a passenger who had relied on its website chatbot's answer about a bereavement refund the airline didn't offer. Air Canada argued that the chatbot was responsible for its own words. The tribunal ruled against it. Any company publishing machine-written text should keep that ruling near the desk. Whatever the software prints under your name, you said it.

A blog post from an AI writing tool goes out under the company's name too. So the cheapest way to vet one takes an afternoon. Take a sentence in its draft that makes a claim about your company and ask the tool where it got it. A tool with an answer points to a call, a page or a fact somebody at the company approved. A tool without one wrote about companies like yours and guessed the rest. We don't think every line needs a receipt, and a paragraph on why onboarding matters can stand on its own. The claims about the product are another matter. Somebody should know where those came from.

Drafts get the category right and the company wrong

Models do their guessing in a predictable place. A first draft about a B2B tool usually handles the general material well, since the model has read thousands of posts about churn, onboarding and pipeline. Models stumble on the sentences only the company could write. The one that should worry a founder sounds something like "Built for enterprise teams, it plugs into Salesforce and HubSpot out of the box." It's fluent. It matches what similar companies say about themselves. For a twelve-person startup with no Salesforce integration, it is wrong twice.

There are four kinds of miss, which are who the product is for, what it connects to, what exists today and what is still planned. Of the four, the last bites hardest, because plans leak into sales calls, pricing pages and Slack threads, and a model reading those sources has no way to tell an ambition from a feature. We have the same exposure. Since social posting is on our plan for next year, a tool that skimmed our pricing page could write, with perfect confidence, that Propaganda posts to LinkedIn today.

Brand kits go stale soon after the upload

The usual fix is a brand kit, or a wiki uploaded as the source of truth, and we think that fix ages badly. A brand book is right on the day someone writes it and is rarely opened again, while the company keeps moving. Then someone at the company changes the prices. A feature gets renamed after the third customer misunderstood it, and over a couple of quarters the ideal customer drifts from agencies to in-house marketers, but the document goes on describing the agencies with the serene confidence of a map drawn before the town moved.

A tool that writes from those files repeats every stale line. It repeats them in the same assured tone it uses for the fresh ones. Nothing in the draft marks a sentence as two pricing changes old. Stale prices usually come to light on sales calls, long after the post went out.

A good draft traces back to facts someone approved

When we designed Propaganda, we started from a smaller unit than the document. Our knowledge base holds hundreds of short claims about a company, each with its source and the quote it came from, covering both facts and voice. A claim like "integrates with HubSpot" either sits there with a transcript or a page behind it, or it doesn't sit there at all. One part of the system, the Guardian, is the only part allowed to change what the company believes. When two claims contradict each other, the Guardian sends the question to the person at the company who owns the topic. A draft written from that base can name where its claims about the company came from, because a person approved each claim before the draft existed.

We ran our own blog through that loop. When Propaganda made a plan for us on 14 October 2026, it came with questions, and we answered them over three rounds before approving the fourth version. Along the way we also overruled it. The plan read "ai cms" as a search that brings in people shopping for a free blog, and we kept it as a target anyway. That decision is ours, written down with a reason, which means the next draft that touches it can point to who made the call.

A second reader checks the draft before you do

Writers believe their own drafts, and models are no exception. So we built a second reader, the Checker, which is in beta. It reads each draft against its sources and the knowledge base before the customer sees it, and it leaves a comment in the editor on any sentence that makes a claim without a source. The comments land next to the sentence, where a human editor would put them.

The point of a second pass is boring, and boring is the goal. A writer and a checker that share the same blind spot catch nothing, which is why the Checker works from the approved facts and the drafts never get to grade themselves. When a fact changes later, another part of the product flags every published piece that used it and proposes the fix. That part matters more than it sounds. The stale line from the brand kit is the one nobody goes back to find.

Run the test on three calls and a homepage

You can run the test inside a free trial. Give the tool three recorded sales calls and your homepage, which is what we ask for to get started, and ask for one post about your product. Then go through the draft with a pen. Mark every sentence that names a customer type, an integration, a price, a feature or a promise. Ask the tool where each marked sentence came from, and count the ones it can trace to a call or the page.

The count matters less than which sentences fail. A tool that can't source a line about tone is mildly annoying. But when a tool can't source who the product is for, or lists a planned feature as shipped, those sentences reach buyers under the company's name. We'd hold any tool to this, ours included. By that standard our free plan, Propaganda Light, which has no agents and no knowledge base, wouldn't pass, though it was never built to take the test.

Posts that name the product need it most

General explainers need less of this. A post on how to run a discovery call can borrow from the whole internet and be fine, and a wrong detail there costs a little credibility with a reader who wasn't buying anyway. The posts that name the product, its customers or its plans carry far more weight. Buyers read them in the days before a first call, and they arrive with the claims already in their heads. We think a wrong integration in a post like that costs the founder the opening minutes of the first call, spent taking back a sentence the company never meant to publish.