Inspectable incident reconstruction

1 · The problem

After an incident, evidence arrives from systems that were never meant to agree: an access controller, two cameras, an inventory database, a witness. Their clocks drift, their records get copied between systems, and their gaps get filled by whoever writes the summary. A narrative that reads well can hide all three problems.

Our aim is narrower than “find out what happened”. It is to show, for every statement in a timeline, which record supports it, which contradicts it, and what nobody can tell.

2 · Two times, one event

An event carries the time its source recorded and a normalized time on a shared reference clock. The source time is never edited. The transformation is stored as a rule, for example clock_offset:-120s, so a reviewer can reverse it. An unknown timezone is never assumed to be UTC; the normalized time is left empty instead.

3 · Inferring a clock offset

A camera rarely tells you its clock is wrong. But it often records moments that a trusted source also recorded: a door opening that the access log timestamps, an alarm that the alarm panel timestamps. We call each such pair an anchor.

Each anchor gives one estimate of the offset: the camera’s time minus the reference time. We take the median, which one bad pairing cannot drag far, and keep the spread between estimates as uncertainty. Only anchors against a source on the reference clock count. With no usable anchor the clock stays unknown and nothing is moved.

Both anchors agree, so the camera runs 120 s fast with no spread. The result is reported as a conflict under RULE-TIME-002 with both pairs listed, because an inferred offset is a claim a reviewer should be able to check.

4 · Named rules

Every contradiction comes from a rule with a stable ID. Each rule records what it compared, how, and what it cannot tell. Rules flag records for review; none concludes that anyone acted wrongly.

• RULE-DUP-001 A row repeated in another source with the same key fields but a different time. Cannot tell: import job, manual edit or a genuine second event.
• RULE-TIME-001 A declared clock offset. Cannot tell: whether it held for the whole recording.
• RULE-TIME-002 An offset inferred from anchors. Cannot tell: whether it held outside the anchored moments.
• RULE-CLAIM-001 An identity claim no source supports. Cannot tell:who the person is.

5 · Four claim states

We do not attach probabilities to claims. A number like “82% likely” suggests a precision the evidence rarely has. Instead each claim is in one of four states, and each state has a test a reviewer can apply.

Supported

A cited source records it and none conflicts.

Contradicted

A source conflicts, under a named rule.

Inferred

Follows only from several sources together.

Unresolved

The evidence cannot settle it. It stays in the report.

6 · Evaluation

CASE-001 is a fictional warehouse incident with known answers written before the code. A second, blind case with different times, a slow clock and different IDs checks that nothing is hard-coded. Every change runs the full test suite. Ten repeated analyses of the same input produced byte-identical output, and a clean checkout reached passing checks and a working demo in about a minute.

These results say the method is consistent and does what it claims on synthetic data. They say nothing about accuracy on real investigations.

7 · Limits

• Video, audio and PDF extraction is simulated from metadata; the anchor events are too.
• A constant offset is assumed between anchors; drift is reported only as spread.
• The demo has no authentication and keeps state in memory.
• The tool is an investigative aid. People make every decision.

See the method on CASE-001 →