AI can write sentences that look checked but aren’t, so proving where content came from now happens one fact at a time. This Q&A Kitchen uses a health inspection to show what that proof looks like, where it gets lost between teams and tools, and why the rules that protect it belong in the content itself.
This issue of Q&A Kitchen is sponsored by Precision Content, which helps enterprise teams structure their content for people and AI.
Last month, the kitchen had a drift problem. Two cooks, two recipe cards, and a regular who wondered why things tasted different.
This month, the health inspector shows up.
And she doesn’t taste anything.
She opens the walk-in cooler and points to a container on the second shelf. No label.
“What is this, and when was it made?”
Now, the sauce looks fine. It smells fine. Honestly, it’s probably fine.
But you can’t show an inspector “probably.” No label means nobody can say what it is, who made it, or when.
So it goes in the trash.
Documentation needs inspected the same way ... especially if you are using AI.
Here’s an example that stuck with me. A technical writer posted on Reddit about documentation that an AI tool had drafted for them. One sentence explained what happens when too many people use the system at once. It said the extra requests get turned away.
It sounded right. It had an exact number, the right technical terms ... all of it.
It was wrong. The real system doesn’t turn anyone away. It puts them in line. And the number was wrong too.
It looked good ... but was wrong.
For years, a polished page was a decent sign that somebody had checked it. If it read well, someone had probably spent time with the product.
AI broke that. Anybody can produce a sentence that looks checked now but never was.
For tech writers, that’s a real shift. Polish used to be part of how we showed our work ... and it doesn’t count as evidence anymore.
So when a customer, a support agent, or an AI assistant asks where a fact came from, “well, it reads nicely” isn’t going to pass inspection.
I’m Lance Cummings, and welcome back to Q&A Kitchen. Each month I take one question content folks are asking and pull everything I’ve been learning about it into one answer.
Every section answers one question, so feel free to skip around. And if you’re listening instead of reading, welcome. Same kitchen, different door.
This month’s question is the one I promised last time. How do you prove where content came from?
What does proof look like?
Go back to that walk-in cooler.
In a kitchen that passes inspection, every container has a strip of tape on it. Most kitchens use the same few fields:
what’s inside,
who made it,
when it was made, and
when it has to be used by.
That label is what makes the sauce checkable. The inspector can read it, and so can the next cook who reaches for it at 9 p.m. on a Friday.
Notice where the label goes, too. On the container ... not on the menu.
The menu can say “house-made marinara” all it wants. The inspector cares about this tub on this shelf.
Documentation works the same way. Most of the time, when we track where content came from, we track the page: who wrote it, when it was published, maybe a “last reviewed” date in the footer.
But nobody acts on a page. People act on the facts inside it ... a limit, a price, a default, a step.
So proof has to live at the level of the fact. Each fact people act on needs its own label:
where it lives,
what it was checked against,
who owns it, and
when it was last confirmed.
For the Reddit example, the label on that one fact might look something like this:
fact: what happens over the limit
value: extra requests wait in line
checked against: load test on the real system
owner: platform team
last confirmed: October 1
Now an inspector, or an AI assistant, has something to check.
There’s one more wrinkle. That sentence on Reddit was doing two jobs. One part was a number you look up. The other described how the system behaves when it gets busy.
Those need different kinds of proof. You confirm a number by checking the setting. You confirm a behavior by watching the system under real load.
Precision Content calls these information types, and each type fails in its own way. A single “reviewed” checkbox on the page can’t catch that. (I broke down all five types, and what counts as proof for each, in this month’s piece on proof.)
So the first rule of the inspection is simple. If it’s a claim someone will act on, label it where it lives.
Where does proof get lost?
Back in the kitchen, the label usually survives the walk-in. Where it gets lost is on the line.
During a rush, a cook grabs the labeled tub of sauce and fills three squeeze bottles for the station. The bottles don’t get labels. Who has time?
By Saturday, there’s a new batch in the walk-in with a little less garlic. Some bottles on the line hold the old sauce and some hold the new. And they all look the same.
When the inspector picks one up, nobody can say which batch it came from.
That’s the handoff. Every time a fact moves, it can lose its label along the way.
I saw a documentation version of this in a Center for Information Development and Management (CIDM) webinar last month. Rob Hanna, Precision Content and Amit Siddhartha of Metapercept walked through two real user guides for air conditioning units. Both were clean and professional, the kind of guides that pass a standards review.
Then they read the words.
Take one simple fact: how often to clean the air filter. The same guide said it three different ways.
The maintenance section said “at least once a month.”
The troubleshooting table said “every 30 days.”
The warranty said “clean filters monthly.”
Close enough that a reviewer would nod right past them. But the warranty one matters. If an AI assistant gets asked “How often do I need to clean this to keep my warranty?” ... it has three squeeze bottles to choose from.
Nobody made a mistake, exactly. The fact got copied into three sections, by people writing for three different jobs, and none of the copies kept the label.
So how do you keep it?
A well-run kitchen has a simple rule for this. The squeeze bottles always come from the current batch, and every bottle gets a piece of tape with that batch’s date on it.
When a new batch is made, the old bottles get dumped and refilled. Nobody tops off an old bottle with new sauce, and nobody makes a “quick batch” right at the station.
There’s one batch. Everything on the line points back to it.
Structured content works the same way. You write the fact once, in one place ... that’s your batch. Every section that needs it points to that one source instead of retyping it. So when the filter interval changes, you change it in one spot, and all three sections update.
The label stays with the batch, and every section that uses it inherits that history.
Rob made a practical distinction here that I really like. Copy and paste is fine for wording you want to sound consistent, like “Turn off the unit before removing the front panel.” Reuse from one source is for the facts that have to change together, like numbers, intervals and error codes.
Not everything needs a label. The things people act on do.
(If you want the technical version, with DITA keys and Precision’s take on microcontent, it’s all in my piece on keeping provenance across teams and tools.)
Who keeps the proof?
Labels are great. But somebody has to decide that every container gets one, what goes on it, and what happens when a cook skips it.
That’s governance. And the real question is where those rules live.
Picture four kitchens.
In the first kitchen, there are no rules. Everybody cooks from memory. When the inspector asks how the sauce is made, she gets four different answers, and nobody can say which one is right.
In the second kitchen, the rules live in the equipment. The fancy new prep system prints the labels and won’t let you log a batch without filling in every field. It works well, until the restaurant switches systems, and the rules leave with the old one.
In the third kitchen, the rules live in a binder in the manager’s office. It’s all written down, and nobody on the line has opened it since spring.
In the fourth kitchen, the rules live on the food itself. Every recipe card follows the same format, and every container carries the same label. A new cook can figure out the system just by opening the walk-in.
Content teams pick one of these, whether they mean to or not. Usually it’s whoever bought the last tool who picked.
The first kitchen is the dangerous one, and there’s a real case that shows why.
In 2022, Jake Moffatt asked Air Canada’s website chatbot about bereavement fares after his grandmother died. The chatbot told him he could book now and apply for the discount later. It even linked to the airline’s policy page ... which said the opposite.
Air Canada refused the refund and argued that the chatbot was responsible for its own words. In 2024, a British Columbia tribunal disagreed and ordered the airline to pay.
That’s what an inspection costs when it comes from outside.
The tribunal also pointed out that Air Canada never explained why the policy page should be trusted over the chatbot. Both were Air Canada content. Nobody could show which one was the real recipe.
Air Canada was the first kitchen, and the tribunal was the inspector who finally asked.
Now imagine the bereavement rule written once, as a single approved statement with an owner and a date. The website pulls from it, and so does the chatbot. When the policy changes, the owner updates one statement, and every channel changes with it.
That’s the fourth kitchen. It also holds up when you switch tools, because the rules travel with the content. And adding a chatbot is a tool change too.
(I compared all four approaches in more depth, including where judgment lives in each one, in my piece on content supply chain governance.)
Would you pass the inspection?
A health inspector doesn’t check every grain of rice. She walks in with a clipboard, picks a few things, and asks the same questions every time.
Rob Hanna gave content teams their own version of that clipboard at LavaCon this year. It’s a quick test for whether a piece of content is canon, the version your organization actually stands behind.
Ask three questions about any answer your content gives, including an AI answer:
Can you trace where this claim came from?
Can you tell which version of the source it reflects?
If the source changed tomorrow, could you update every place the claim appears?
Air Canada’s chatbot failed all three. The Reddit sentence would have too. And the air conditioner guide would have struggled with the third, since nobody knew there were three filter intervals to update.
Think back to the label on the container. Where it lives, what it was checked against, who owns it, when it was last confirmed.
That label is what makes those three questions answerable.
What can you check this week?
Run your own inspection.
Pick one question your customers ask a lot, one that a help page, a support agent, or an AI tool answers for them. A return window, a price, a setup step, a warranty rule.
Then find every place that answer shows up, and ask the clipboard questions.
Where did it come from?
Which version does it reflect?
If it changed tomorrow, would every copy change with it?
If the answers point to different sources, you’ve found an unlabeled container. Pick an owner, give the fact one home, and put a label on it.
If you lead a team, the owner question is the one only you can answer.
You don’t need a new system to start ... just a piece of tape and a marker.
Next month, Q&A Kitchen closes out this series with the biggest question yet. How do you track content provenance across an entire content supply chain? We’ll follow a single fact from the first draft all the way to the AI answer and see where the labels hold up along the way.
I’m Lance Cummings. Until next time ... label your containers.
About Precision Content
Precision Content helps enterprise organizations turn scattered documentation into structured, reusable content that people can trust and AI systems can retrieve accurately. Their methodology, standards training, and content transformation services give teams a single source for every fact.
