Onyx Digital Intelligence.

The correction runs on a different clock

#AI #Wikipedia #misinformation #POPIA #OnyxAudit

At 09:47 UTC on 12 August 2026, someone rewrote the English Wikipedia biography of Sam Altman to say he had been assassinated in Seattle that morning. The opening paragraph was shifted into the past tense. A death date went into the infobox.

Screenshot_20260816_211743_Brave

A volunteer reverted it at 10:29. The false claim had been live for forty-one minutes.

In that window, Google's Knowledge Panel picked it up. Anyone searching his name in ordinary Search, not an AI summary, was shown a man who had died that day.

Disclosure. A second incident of the same kind occurred the following day, involving an executive at a company whose AI tools I use in my own research. I have not named him. Putting a person's name next to a false death claim on a page that indexes is the specific harm this piece is about, and I am not going to commit it in the course of describing it. That case appears below only as an unnamed second data point, and it is the weaker of the two evidentially.

What Wikipedia did

The system worked. That is worth saying before anything else, because the easy version of this story is that Wikipedia is unreliable, and the easy version is wrong.

Wikipedia's automated tooling flagged the edit as a possible unreferenced addition to a biography of a living person. Volunteers descended: the article recorded 22 edits on 12 August against five in the whole month before it. A second attempt to reinsert the death date at 12:39 was removed within minutes. The page was placed under semi-protection, restricting editing to accounts at least four days old with at least ten edits to their name.

A Wikimedia Foundation spokesperson told Business Insider the edits had been reverted in anywhere from one to forty-three minutes, that most vandalism is addressed within ten, and that the episode demonstrated the volunteer model working in real time.

All of that is accurate. Wikipedia has ClueBot NG watching every edit on the site, often reverting detected vandalism within seconds. It has semi-protection and pending changes. It has a biographies policy stricter than anything else on the platform, requiring that unsourced contentious material about a living person be removed immediately, without waiting for discussion.

Screenshot_20260816_210031_Brave ![Uploading Screenshot_20260816_211759_Brave.jpg...]

The problem is not that Wikipedia lacks a correction mechanism. It is that Wikipedia's correction mechanism does not extend past Wikipedia.

What Google did

Google's own account, posted publicly on the day: the change was not manual on their side, and when people vandalise public information sources, this can affect what appears in Search.

That is true, and it is also the whole finding.

The Knowledge Panel is generated automatically from sources across the web, Wikipedia prominent among them, and it updates as those sources change. No editor approved the death. No reviewer compared "died 12 August 2026" against the "CEO of OpenAI" sitting in the same record and asked whether both could be true. The panel simply reflected its upstream and moved on.

And here is the asymmetry. We know precisely when Wikipedia was wrong and precisely when it was fixed, because every edit is timestamped, attributed and public. We do not know when Google's panel corrected, because Google publishes no equivalent record. Reporting at the time noted the panel took longer to catch up and that public timestamps do not show when the death date disappeared.

HPhcPwJWMAA54yp

Forty-one minutes of error on one system, an unknown duration on the other, with no way for anyone outside the company to measure the gap.

The gap is where the damage lives

This is not new, and the historical cases are instructive precisely because they predate any of the current machinery.

In 2005 a fabricated Wikipedia biography linked the journalist John Seigenthaler to the Kennedy assassinations. It stood from May to September. After Wikipedia corrected it, Seigenthaler recorded that the falsehood remained live on Answers.com and Reference.com for three further weeks. The correction did not propagate at the speed of the error, on mirrors that were, by the standards of 2026, primitive.

In 2007 a false report of the comedian Sinbad's death was reverted in about seventy-two minutes and still became international news.

Randall Munroe named the self-reinforcing version of this in 2011: citogenesis. An unsourced claim enters Wikipedia. A rushed writer repeats it. An editor cites that article back on Wikipedia as a source. The error is now load-bearing. Wikipedia maintains a list of confirmed instances, and it is longer than you would like.

What has changed since is not the mechanism. It is the number of systems downstream and the speed at which they ingest.

Wikipedia feeds Wikidata, which is editable by anyone and, in the words of the research literature on the subject, frequently gets vandalised, exposing every information system that consumes it. Wikipedia is also the single dominant knowledge base for retrieval-augmented AI systems and the benchmarks used to evaluate them. Anything scraped during a live window enters a training snapshot or a retrieval cache and stays there until something else displaces it. Corrections do not chase the copies.

The clearest demonstration this year did not involve Wikipedia at all. In June, DuckDuckGo's AI answer tool told users Donald Trump and JD Vance had died of rabies, having stitched together a deliberate Reddit hoax, a fabricated local news site, and an unrelated real report of a rabies death in Ohio. Brave's AI repeated part of it. A Brave spokesperson observed that search engines, with or without AI, are not oracles of truth.

They are not. But they are read as though they are, which is the entire problem, and none of them carry Wikipedia's edit history.

The second case, and why it isn't one

Reporting at the time indicated that a second AI executive's Wikipedia biography had been vandalised the following day, 13 August, and that Google's panel had again displayed a death date for a living person.

I went and checked, and the Wikipedia half of that is not true.

I have read every edit to that article over the preceding six months. There is no death insertion, no death date, no death place, no revert of any such edit. The vandalism reported did not occur. What the talk page actually contains, over that period, is a dispute about whether a family member warrants inclusion, which Wikipedia's editors resolved against on notability grounds. Nothing else.

Tracing the claim back, it appears to originate with a single outlet, the Indian edition of Business Insider, whose headline grouped both executives together. I have found no other major outlet reporting a vandalised edit on the second article, and Google's own acknowledgement referred to public information sources being vandalised, which the Wikimedia Foundation confirmed in relation to the first article only.

So the second incident, as reported, did not happen the way it was reported. Whatever produced any error in a search panel about that person, it was not an edit to their Wikipedia page, because there wasn't one.

I had this in an earlier draft as a Tier B second data point on the strength of contemporaneous screenshots and a forum thread. It does not survive the edit history, and I am recording the correction rather than quietly removing the paragraph.

Which is, awkwardly, the same mechanism the rest of this piece is about. One outlet grouped two names in a headline. The grouping travelled. It reached me, and I nearly published it. The difference between me and the pipeline is only that Wikipedia keeps a record I could go and check, and I checked.

The part where geography decides

Sam Altman found out within the hour. He is one of the most searched names in technology, the story was worldwide by lunchtime, Google responded publicly the same day, and the correction was itself news.

le-pdg-dopenai-sam-altman-lors-dun-forum-transformer-les-entreprises-grâce-à-lia-à-tokyo-le-3 (1)

Now run it for someone in Pinetown.

A South African whose Google panel says they died finds out when a relative rings, or when a bank declines something, or never. There is no press pack. There is no volunteer community watching their article, because there is no article. If the false claim sits in a search result rather than on Wikipedia, there is no edit history to point at and no revert to request.

The legal position compounds it. POPIA section 24 gives a data subject the right to ask a responsible party to correct personal information that is inaccurate or misleading, and on its face a false death is exactly that. But I have not located any tested application of section 24 to a search engine knowledge panel, and whether Google is a responsible party for automatically generated panel content about a South African is not a question our law has answered. The EU has a rectification right under GDPR Article 16 with a decade of case law behind it, and a regulator with the appetite to use it.

Same error and the same company with the same pipeline, whether there is anywhere to take it depends on where you are standing.

What would actually help

Two things, neither of which requires new law.

Any system that displays a death date for a person should cross-reference at least one independent source before showing it, and should refuse to display a death alongside a present-tense current role in the same record. That contradiction was sitting in Google's own panel and nothing caught it.

And any system that ingests from a corrigible source should publish its correction latency. Wikipedia can tell you it took forty-one minutes because Wikipedia keeps the receipt. Google cannot, or will not. Until downstream systems keep an equivalent record, the honest statement about any error they propagate is that nobody knows how long it was live, including them.

Method and limits

The Altman timeline, the edit counts, the Google statement, the Wikimedia statement and the semi-protection are Tier A, from contemporaneous reporting quoting primary sources including Google's own public post of 12 August 2026.

An earlier version of this piece treated a reported second incident as a Tier B data point. On examination of six months of that article's revision history, no such vandalism exists. The claim traces to a single outlet grouping two names in one headline. The paragraph has been corrected in place rather than removed, and the correction is above.

Screenshot_20260816_215030_Brave Screenshot_20260816_215016_Brave

The ClueBot NG catch-rate figures are self-reported by the bot's own statistics page. Vandalism survival statistics from the 2003 IBM history-flow study and later community estimates are dated and establish a pattern rather than a current rate.

The POPIA section 24 reading is my own and is untested. I have located no South African decision applying it to search engine output. If one exists I would like to see it.

Screenshot_20260814_163525_Brave

I have not established that any large language model reproduced either false death after its reversion. The propagation documented here ran through Google's structured Knowledge Graph, not a generative model. The training-corpus persistence risk is plausible and, as far as I can find, undocumented.

Sources

Clayton Bax

Published under ONYX Digital Intelligence
Following the #OnyxAudit methodology.

"Adjacent to true is not true."

Truth has no flag nor favour, only a standard. And it's heavy

#AI #POPIA #Wikipedia #misinformation #search