We Built an AI Incident Register. Now You Can Audit Its History.

On 30 September, our record of the DIVD intrusion left the exact intrusion date unknown. The version saved the following morning contained a date, more technical detail, and a higher severity assessment.

You can now read both versions on Agent Did What?. The earlier account is still there, with its own sources, assessment, and limitations.

That's the latest addition to the searchable incident register we've been building with Codex. What happens when the evidence changes after someone has read, shared, or relied on your account?

How the register took shape

The original brief was to collect AI-agent incidents in one place, make them searchable, and link the evidence. We wanted readers to be able to examine what went wrong and hold the organizations involved accountable.

The live register on 1 October 2026. Reports and research demonstrations have separate collections; readers can filter by evidence status, severity, and updates.

That required more structure than a list of alarming headlines. An affected organization acknowledging a breach, a researcher demonstrating an attack, and a disputed claim need different treatment. A case also needs to separate the model provider from the organization operating the system, and the agent's role from the damage attributed to it.

The saved project history begins on 28 September 2026. Over the following days, we added an explicit severity rubric, a private archive of source material, and maps of the systems involved. Cases gained fuller article views.

But the current page still answered only what the register said now. A reader who remembered a different assessment had no convenient way to revisit it.

The next request to Codex was to review cases added in the previous two weeks, look for new information or retractions, and let readers click back to an earlier account. That required storing versions and review results separately, then making the saved records readable through the same case interface.

We added public record histories on 1 October. At the time of writing, the live register contains 71 cases and 203 saved versions. Those versions include records recovered from actual project saves as well as subsequent reviewed updates. They are not 203 separate incidents. The public history index contains the timestamps and version references.

Open the earlier account

Each case now has a Record updates section. Choose an entry and the site opens that saved account. A prominent historical-version banner gives its timestamp and tells you that later information may correct or supersede it. There is a direct link back to the latest version.

A crop from the live historical DIVD case. The selected 30 September version sits beside the 1 October update. The notes below distinguish save times from incident dates and disclose the limits of the latest source check. Times are UTC.

The DIVD example shows why we preserve the whole record. The 30 September version says the exact intrusion date is unknown. The next saved version adds 21 September, identifies Zammad, and incorporates technical case files and an advisory into its sources.

Its severity assessment also changes from Medium to High as the account gains detail about unauthorized system control. Yet its evidence status remains Reported. More detail about the intrusion does not independently establish that an AI agent performed the initial exploit, or identify a model or operator.

Two live screenshot excerpts, stacked for comparison, with date labels added above each crop. The supported impact changes; the evidence label remains Reported. The full assessments retain additional limitations on loss, data compromise, and AI attribution.

The timeline lists the fields that changed. Opening a version lets readers inspect the text and its supporting source references themselves. It is not a word-by-word comparison screen.

A saved version also retains the assessment and system map that belonged to it. If an older record predates those features, the site says so. Showing today's assessment inside yesterday's account would make the history misleading.

There are two timelines

An incident chronology dates events in the world: initial access, detection, disclosure, response.

A record timeline dates changes to our account of those events.

For DIVD, the intrusion date recorded in the newer account is 21 September. The older register version was saved on 30 September at 18:12 UTC. The update was saved on 1 October at 06:18 UTC. Those dates answer different questions.

The distinction also limits what we can claim about our own history. A recovered save tells us what was in that saved record. It does not prove the exact time those words appeared on the public website, or when an external publisher changed its reporting. We recovered the versions we actually had, beginning on 28 September. We did not reconstruct earlier accounts from today's knowledge.

A recovery belongs in the case too

Following incidents means recording information that changes the outcome, including information that makes an earlier account less alarming.

One reviewed update concerns PocketOS. The register now includes Railway's account of full database recovery and changes to deletion safeguards. That matters to anyone evaluating the consequences of the incident.

The update does not erase the original destructive action or lower its High severity assessment. It does make clear that permanent data loss is not established. Readers can distinguish what happened during the incident from what was subsequently recovered.

The history system supports corrections and retractions as well as new information. Those need to change the current account and remain visible in the record. A version archive would do little good if the latest page continued repeating a claim that had been withdrawn.

Checking is different from changing

A routine review can find no material change. It can also fail to establish one because a source is blocked or only partly readable.

We record that coverage separately. Rechecking a case does not create a new historical version by itself, and it does not make an old case look newly updated. When access is incomplete, the review note says so.

Material updates, corrections, and retractions receive a visible flag for 14 days. Readers can filter for recently updated cases or sort by the latest information. Editorial changes and newly added assessments stay in the history without being presented as fresh incident evidence.

What we actually save

Underneath the interface, each version is a separate data file containing the case, its referenced source metadata, and the assessment rules needed to read it in context. New versions are added; published snapshots are kept unchanged.

Each file has a cryptographic fingerprint. The build checks those fingerprints and refuses to accept a changed current record without a corresponding saved version. Historical links and downloads preserve the selected version, so someone following a citation can open the account the author meant to reference.

These checks help detect inconsistent or accidentally altered files. They cannot prove that the underlying allegation is true, and this remains a register we operate. Evidence still requires judgment.

There is a second, private layer behind the public record. We retain retrieved source material and tie research notes to the exact captures used. If a source changes later, an earlier usable capture is still available to our research process. A blocked refresh does not erase it.

The public histories contain source references and metadata, not a republication of those captured articles. Clicking a publisher's link may take you to a page that has since changed. The register's history and the publisher's history are separate things.

Being able to check us

We built Agent Did What? to make AI-agent incidents easier to examine. Our own revisions belong in that examination.

A reader can now open the version they remember, compare its fields and sources with the latest account, and share that specific version when discussing it. If you disagree with an assessment or spot a missing update, you can point us to the account you mean and the evidence that challenges it.

Explore the register or open the historical DIVD case and follow it forward. Figures and implementation details checked on 1 October 2026.