AI incident reporting and the evidence problem
Reporting regimes give you days. The facts you need to report were produced weeks earlier, by systems that have changed since. What you can prove at hour 70 was determined long before the incident.
Incident reporting obligations for AI systems are arriving across jurisdictions, with varying triggers and deadlines. The EU AI Act requires providers of high-risk systems to report serious incidents to authorities within defined periods. Illinois SB 315 introduced a 72-hour reporting requirement. More regimes are in progress.
The common structure: a short clock, and a demand for facts about what a system did before anyone knew there was an incident.
What a report has to establish
- What the system did, specifically, and when.
- How many decisions or individuals were affected.
- When the behaviour started, which usually predates detection.
- What changed immediately before, in the model, the configuration, or the data.
- What was done in response, and when.
The retrospective evidence problem
Every item on that list is a claim about the past, assembled under time pressure from logs that the organisation controls. Two failure modes follow. First, the reconstruction may simply be wrong, because the systems have moved on. Second, even a correct reconstruction is a self-produced account of a self-caused incident, which is the least persuasive category of evidence.
Neither is a discipline problem. Both are a design problem: the evidence was not created independently at the time.
What contemporaneous attestation changes
If consequential decisions, model version changes, and configuration edits are attested as they occur, the incident report assembles from records that already existed, timestamped externally, before anyone had a motive about the outcome.
The change in posture is significant. A report that says "here is our reconstruction" invites scrutiny of the reconstruction. A report that says "here are the records, anchored at the time, verify them yourself" does not.
Check it yourself
Every Rubric attestation resolves publicly, with no account and no API key, and every anchor resolves to a public ledger message you can read without our cooperation.
HCS topic 0.0.10416909 · ML-DSA-65 signatures
Change records are the sleeper
Most AI incidents trace back to a change: a new model version, a threshold adjustment, a data pipeline edit. Attesting change events is cheap, low-volume, and disproportionately useful, because it establishes when the behaviour could first have occurred without relying on anyone's memory.
Related: Illinois SB 315 · AI audit trail requirements · How to prove an AI decision happened