Reconstructing an Incident Timeline From Primary Sources

The single most common error in AI-incident reporting is a wrong timeline. Not a fabricated event — a real event, dated incorrectly, because the reporter took the first date they saw and treated it as the date. A vendor advisory’s publication date is not when the incident happened. A CVE’s reserved date is not when the bug was found. A news article’s timestamp is not when the harm occurred. Each primary source records a different moment, and conflating them produces a timeline that is confidently, citably wrong. This post is the method we use to reconstruct a defensible timeline from those sources — and the discipline of marking what can’t be pinned down rather than guessing.

The four dates, restated

We date every catalog entry with up to four distinct timestamps. They almost never coincide:

• incident_date — when the harmful behavior actually occurred.
• disclosure_date — when the affected party or vendor first acknowledged it (internally or publicly).
• report_date — when public reporting first appeared.
• verification_date — when we cleared our own bar.

A vendor disclosure on April 30 about an exploitation window in January is two events, not one, and a timeline that records only “April 30” has erased the more important number. The reconstruction job is to recover each of these from sources that were never designed to hand them over cleanly.

What each source actually dates

Every primary source carries dates, but you have to know which moment each one is recording.

Vendor advisory. The advisory’s own header is the publication date — it maps to report_date (or to a public disclosure_date if the advisory is the first acknowledgment). The advisory’s timeline section, when it has one, is where the real incident_date and internal disclosure_date live: detection date, containment date, notification date. The gap between detection and notification is the most operationally meaningful number in the document, and it’s the one a single header timestamp destroys. Read the advisory’s body, not just its metadata.

CVE / NVD record. A CVE carries several dates that are routinely confused. The reserved date is when the identifier was allocated — often long before any detail is public, and meaningless as an incident date. The published date is when NVD first displayed the entry. Neither tells you when the vulnerability was discovered or whether it was ever exploited; NVD records vulnerabilities, not incidents. For an exploited-vulnerability incident, the CVE dates the weakness, and you need a separate source to date the exploitation. Cross-check the referenced patch commit and upstream advisory, which usually predate the NVD publication.

Regulator filing or court document. These date the legal event — the complaint filing, the consent order, the finding. That date is rarely the incident date; a complaint filed in 2026 may concern conduct from 2024. The value of these documents is that they often contain a factual recitation with dated conduct that no other public source provides. Mine the body for the conduct dates; use the filing date only as what it is.

Researcher disclosure / paper. A research blog or preprint dates the disclosure of a technique. If the researcher reproduced an attack against a live system, the post may also date an incident_date — but a demonstrated technique with no observed deployment is a vulnerability disclosure, not an incident, and dating it as one inflates the record. Academic disclosures frequently omit precise dates entirely; when they do, mark the date approximate and say why.

News reporting. An article’s timestamp is report_date and nothing else. A reputable outlet’s body text may establish earlier dates through reporting, but the timestamp itself only tells you when the story published. Aggregators republishing each other reset the timestamp without resetting the event, which is how a 2024 incident shows up “dated” 2026 across a dozen low-rigor sites.

The reconstruction procedure

The method is mechanical, which is the point — it removes the temptation to smooth over gaps.

1. Collect every primary source that touches the event. Advisory, CVE/NVD entry, any regulator or court document, any researcher disclosure, the strongest secondary reporting. Note which tier each is (see our source tiers).
2. Extract every date from each source, labeled by which moment it records — not “April 30” but “advisory publication date: April 30” or “complaint alleges conduct beginning January 12.” Keep the label attached to the date through the whole process.
3. Build a single merged timeline of dated facts, each annotated with its source. Now the four canonical dates usually fall out: the earliest conduct date is your incident_date candidate, the earliest acknowledgment is disclosure_date, the earliest public report is report_date.
4. Resolve conflicts explicitly. When two Tier-1 sources disagree on a date — an advisory says detection on the 3rd, a court filing says the 1st — record both and say which you weight and why. Do not silently pick one. A reader who finds the discrepancy later should see that you saw it too.
5. Mark the unknowns. If no source establishes when exploitation began, the incident_date is “unknown; vulnerability disclosed [date]” — not a guess interpolated from the disclosure date. Being incomplete and reliable beats being complete and wrong.

A worked example of conflict resolution

Suppose a model-serving framework has an exploited deserialization flaw. You have: an NVD entry (published March 12, reserved February 2), an upstream GitHub Security Advisory (published March 5, with a patch commit dated March 3), a vendor blog describing an incident where the flaw was exploited against their service, and a news article (March 20).

The naive timeline says “March 12” — the most prominent date, the NVD publication. The reconstructed timeline says:

• incident_date: the exploitation window in the vendor blog (the actual harm), if dated; otherwise unknown.
• disclosure_date: March 3–5, the patch and GHSA (the vulnerability’s first acknowledgment).
• report_date: March 5 for the vulnerability; the vendor blog date for the incident.
• The NVD published date (March 12) and reserved date (February 2) are recorded as NVD metadata, not as the incident date.
• The news article (March 20) is report_date for the secondary coverage and nothing more.

Same facts, same sources — but the second timeline is one a security team can act on and a later analyst can cite without re-deriving it.

Cross-referencing the reconstruction

A reconstructed timeline should be checkable against the standing public records, which themselves apply dating discipline:

• The AI Incident Database ↗ for a logged entry, if one exists.
• The OECD AI Incidents Monitor ↗ for international coverage.
• MITRE ATLAS case studies ↗ when the event maps to a documented technique.
• The NVD ↗ for the underlying vulnerability’s canonical dates, read with the reserved-vs-published distinction in mind.

If your reconstruction disagrees with one of these, that’s a finding to run down, not an embarrassment to bury — sometimes the standing record is the one that’s wrong, and the discrepancy is itself worth noting.

Why the discipline pays off

A timeline is the load-bearing structure of an incident record. Get it right and every downstream use — patch prioritization, regulatory submission, trend analysis, a journalist’s citation — inherits the rigor. Get it wrong and the error propagates, because the next writer cites your date instead of re-deriving it. The method here is not clever; it is just refusing to let one prominent timestamp stand in for an event that several sources date differently, and being honest in writing about the moments no source pins down. That refusal is most of what separates a record from a rumor.

For how we handle the artifacts these dates come from, see decoding NVD CVE entries and reading a vendor advisory.

Sources

• AI Incident Database (Partnership on AI) ↗ — standing public catalog used as a cross-reference for logged incidents.
• OECD AI Incidents Monitor ↗ — international incident tracker, useful for events with cross-border coverage.
• NVD Vulnerability Database ↗ — the canonical source for a vulnerability’s reserved and published dates; read with the distinction that NVD dates weaknesses, not incidents.
• MITRE ATLAS ↗ — documented AI-system attack tactics, techniques, and case studies for mapping and cross-reference.