Extracting a Structured Timeline From an Accident Report

The obvious plan is to pull every time from an accident report and sort them. It fails immediately, because most of the events that matter are described with no time at all — only in relation to something else — and because the times that are printed belong to four different processes.

There are four clocks on the form

A crash report’s header block typically carries the time of the crash, the time the agency was notified, the time a unit was dispatched, the time the first unit arrived on scene, and the time the scene was cleared. Only the first is an event in the collision. The rest describe the response, and one of them — time of crash — is very often an estimate derived from the notification time rather than an observation. On top of those, the report has an authoring date and an approval or supervisor review date that can be days later, and any attached emergency medical or fire form carries its own set of times recorded by a different agency against a different clock.

So the first schema decision is that a time is never a bare field. It is a value plus what it is a time of, plus who recorded it. Flattening “time” into one column is how a downstream system ends up asserting that a collision happened eleven minutes after the ambulance arrived.

{
  "event_id": "e4",
  "kind": "impact",
  "recorded_by": "reporting_officer",
  "absolute_time": "2026-03-14T23:52:00-05:00",
  "time_precision": "minute",
  "time_basis": "estimated_from_notification",
  "source_span": {"page": 1, "field": "TIME OF CRASH"}
}

The narrative is not in chronological order

Officers write the narrative in the order they learned things. A typical opening is the arrival — “On the above date and time I was dispatched to…” — followed by what was observed on scene, then each driver’s account of what happened before the impact, then the disposition. Read literally, the document begins after the crash, goes backwards twice, and ends at the tow truck.

The events that matter for reconstruction are almost all in the middle section, and they arrive with phrases rather than timestamps: prior to impact, approximately two seconds before, moments later, after coming to rest, while waiting at the signal. These carry ordering information and, sometimes, duration information, and they carry it relative to a landmark rather than to a clock.

Anchoring relative time to the impact

The workable model is to designate the impact as the origin and express everything near it as an offset. Extract each event with four optional fields: an absolute time if one is stated, an anchor event if the phrasing names one, a signed offset in seconds if a duration is stated, and an ordering relation if only sequence is implied. An event may have none of these except a relation, and that is a legitimate extraction result rather than a failure.

• “Approximately two seconds before impact” gives anchor impact, offset -2, precision approximate. Keep the hedge word. Dropping approximately converts an estimate into a measurement, and the reader of your database cannot tell which they have.
• “Moments later” gives an ordering edge and no duration. Do not assign it a number. A model asked for a numeric offset will supply one, and inventing five seconds is the same class of error as inventing a name.
• “While waiting at the signal” describes an interval that contains another event rather than a point. Model it as an interval with a start relation and an end relation, or you will be forced to pick a point and every choice will be wrong.

Ordering a partial order

What you have after extraction is a set of nodes and a set of before/after edges — a directed graph, not a sequence. The correct operation is a topological sort, which produces a valid ordering when one exists and, importantly, tells you when several orderings are equally consistent with the document.

1. Emit one node per event, with its anchor, offset, relations and the verbatim span it came from.
2. Add edges from explicit relations, then from absolute times where two events both have them, then from anchor-plus-offset arithmetic where both events share an anchor.
3. Topologically sort. If the sort finds a cycle, the document contradicts itself — usually because two drivers’ accounts disagree — and the right output is the cycle, flagged, not a resolution.
4. Where the sort admits more than one order, mark the tied events as unordered rather than picking the one the model happened to emit first.

Contradictions are the useful output here, not noise. Two accounts that cannot both be true is exactly what a claims reviewer wants surfaced, and it is the same provenance question the police report fault extraction page is built around: an event described only in one party’s statement is an assertion by that party, and the timeline should say so on the node.

Arithmetic traps in the times themselves

• Midnight rollover. A crash at 23:52 with a unit arriving at 00:07 is fifteen minutes, not minus twenty-three hours and forty-five minutes. Times on these forms frequently carry no date, and the date is inherited from a header field that refers to the crash. Any negative elapsed interval under twelve hours between two events known to be ordered should be resolved by adding a day to the later one, and any that is larger should be flagged instead. This belongs in a date field validation rule rather than in the extraction prompt.
• Four-digit military time against a twelve-hour clock. 0730 and 7:30 PM can appear on the same page in different blocks. Capture the printed form and the interpretation separately, and reject a four-digit value whose first two digits exceed 23.
• Minute precision hides ordering. Several events inside one minute are unordered by their timestamps, and the narrative relations are the only ordering evidence you have. A sort that uses timestamps alone will silently reorder them on every run.
• Daylight saving. A local time in the repeated hour of an autumn transition is genuinely ambiguous. Store the local time as written with its zone name, not a converted instant.
• Amended and supplemental reports. A supplement can change a time recorded in the original. The timeline is a function of a report version, so key it by report number and supplement index, and never merge the two into one set of events.