A reader writes in to say the article should have said "2.4 million euros in subsidy", not "24 million". The editor checks the report, sees the reader is right, and fixes the article. Within a quarter of an hour there's a correction note underneath. Done, everyone thinks.
Except the same figure is in Tuesday's newsletter, in three social posts, in the summary the app shows at the top, in the English version and in the podcast script. Nobody remembers those. Not because anyone was careless, but because the article was never tracked as the source of all the others.
(The example is made up. The mechanism isn't.)
The real cause
A correction arrives where the error was spotted, and gets fixed there. But an error that sits in the source, or in the first article, spreads with every derived text. Each new version is a copy with a life of its own: a different tool, a different channel, often a different person.
AI makes this worse, and faster. When a model turns one article into five versions in a minute, you also get five places where the same claim lives, in slightly different words. That's the whole point of the tool, and it's also the problem when a correction comes in.
Two habitual workarounds follow, and neither works.
Searching for the figure. You'll find "24 million". You won't find "just over twenty million" or "€24m". The summary may only say "a hefty subsidy". The Dutch version has "vierentwintig miljoen", and the podcast script spells the number out. Search for the shape of the error and you'll find half of it at best.
Emailing round. "Heads up, the amount was wrong, check whether it's in yours too." That works while the team is small and everyone remembers what they made. With a newsletter a freelancer puts together and a social account an intern runs, it doesn't.
Which phase this is
SEAL describes the four phases knowledge work goes through: Source, Edit, Approve, Launch. In every phase the traceability of a source can be lost, and the weakest phase determines what the work is worth.
This touches two phases at once. Edit, where the question is whether the source still covers the text after editing. The moment the source changes, it no longer covers the derived texts, even though nothing in those texts was touched. And Launch, because a release only holds as long as text and source stay unchanged. A correction in the source invalidates every earlier release of what rests on it, automatically. Only nobody knows, because nowhere does it say what rests on what.
That's the core. What nobody can reconstruct, nobody can correct. A newsroom that hasn't recorded in advance where a claim ends up can't say afterwards where it is now.
The tool: a correction list, built at publication
No database, no new system. One table with a row for every claim that matters: figures, names, dates, quotes, conclusions. Not every sentence, only what would be worth a correction.
- Claim: Subsidy: €2.4 million
- Source: Evaluation report, p. 14
- Where used: Article (site), newsletter 12 Oct, 3 social posts, app summary, Dutch version, podcast script
- Who: Desk
- Fixed: …
- Re-approved: …
It only works on one condition: the "Where used" column is filled in the moment a piece goes out, not the moment a correction is needed. Then it costs one line per piece. Afterwards it costs an afternoon of digging, and you still end up with gaps.
When a correction comes in, you walk the row from left to right:
- Check the source. Does the original say what the reader claims? Only then do you change anything.
- Take every place in "Where used". Change the figure in each piece, including the one "nobody reads any more".
- Have the derived texts approved again. That doesn't mean rereading the whole piece. It means that one passage, next to the source. An approval belongs to the passage it refers to, and the passage has changed.
- Note the date and who did it. That way you can show the next reader, or the next complainant, what happened.
- Announce the correction where the error appeared. A correction under the article alone doesn't catch up with the newsletter.
What AI helps with here, and what it doesn't
A model is useful for finding candidates: "show where in these twelve texts the subsidy amount, or a description of it, appears." It finds "a hefty subsidy" where a search stops. But a model that says "I found everything" proves nothing, because search alone can never show absence. What the model finds is a list to check. What it doesn't find stays unknown.
For building the list itself, the strongest set-up is a system in which the derived text knows its source. In TRACES, the six layers on which you assess an AI system, that layer is called Trail: the system records which claim rests on which source, as a by-product of the work. The record then appears without anyone maintaining a table, and a correction in the source points straight at the pieces that rest on it. If you don't have such a system, the table above does the job, by hand.
What stays hard
Two things remain difficult, and it's more honest to say so.
First, content outside your control. A story someone else picked up, or a screenshot that's doing the rounds, can't be pulled back. For those, the only thing left is a public correction in the places where you do have a say.
And the habit. A list that only comes out for corrections doesn't get maintained. It works when it's part of publishing: no filled-in row, no release for a piece with a figure in it.
What you can do this week
- Take the last correction you made. Try to find, in fifteen minutes, every piece where the same claim appeared. Count how many there are, and how many the correction reached.
- Set up the table above, on paper or in a spreadsheet, with the six columns.
- Fill it in for the claims in the piece currently in progress. Only the claims that matter.
- Agree that a piece containing a figure, name or quote doesn't go out without a row in the list.
The difference between what the correction reached and what it should have reached is your leak between Edit and Launch.