SAFETY
Reconstructing an incident after the fact
When an autonomous machine does something unexpected, the questions arrive with urgency and the answers depend entirely on decisions made months earlier about what was retained. What a reconstruction actually needs, and why telemetry is not it.
· 7 min read
A machine did something nobody expected, and now three people need to know what happened. An operator has a stopped fleet and has to decide whether to resume it, in minutes rather than weeks. A safety officer needs to know whether the machine did what it was designed to do, which is a different question from whether anyone was hurt. An investigator needs a record that was not curated by the party being investigated.
The questions arrive with urgency and consequence. The answers were determined months earlier, by decisions about what the system retains, at what fidelity, and with what integrity. Nothing done after the event improves the record.
Reconstruction is not an operational feature that can be added when it is wanted. It is a design property, present before the event or unavailable after it.
What a reconstruction needs
Answering the question takes five things, captured together and aligned in time:
- What the machine sensed. The input as the machine received it, not as a dashboard summarized it. A downsampled preview and a derived bounding box answer only the questions someone thought to ask in advance. The retained stream lets an investigator ask a new one.
- What the machine believed. Perception output and the relevant slice of the shared world model at that instant, including how stale that slice was. A machine acting on a picture that was accurate several seconds earlier behaved reasonably given its beliefs and unreasonably given the world, and only the retained belief separates those two findings.
- What was requested and what was allowed. Kept as separate records. The policy asking for something the limits refused and the machine actually doing it are different events with different consequences, and a log holding only the resulting actuator commands cannot tell them apart.
- What was running. The exact image, policy, model, and configuration identity in force at that moment — the point at which attestation records stop being a governance artifact and become the reason an investigation does not spend its first week establishing what was on the machine.
- When, relative to everyone else. A fleet event is a multi-party event, and which thing happened first is unanswerable when every machine keeps its own clock. Ordering across machines and the facility plane is where time synchronization earns its keep.
These have one property in common. Each is inexpensive to retain if the system was built to retain it, and impossible to recover if it was not.
Telemetry is a different data product
Operational telemetry is sampled, aggregated, and lossy by design. Those properties are what make it cheap to keep for a long time and useful for watching a fleet: counters, rolling averages, a health state reported at intervals, summaries that compress a shift into something a person can look at.
The same properties make it nearly useless for reconstruction. The event under investigation is precisely the outlier that aggregation removed. A statistic over a window cannot describe the moment inside the window, and a health state sampled periodically will usually have been sampled just before and just after the thing that mattered.
Reconstruction needs the opposite shape: full fidelity, a short horizon, anchored to a specific event, with nothing selected out of the window. The hard part is not the storage, which is tractable where the data already is. The hard part is what marks a window as worth preserving, and the answer cannot be only the machine's own judgment that something went wrong, because a machine that registered nothing unusual is among the more common things an investigation finds. Preserving a window has to be reachable after the fact, by an operator and by a supervising system that sits outside the machine being recorded.
A record the operator could have edited
Evidence the party under investigation could have altered is weak evidence. Its value in a dispute rests on the goodwill of the parties, which is exactly what is in short supply whenever a dispute exists.
The requirement is tamper-evidence rather than tamper-proofing. Records signed at the point of capture, chained so each entry commits to the ones before it, append-only in structure, with the signing identity rooted in the same hardware chain the node attests with. Nobody can stop an owner from destroying a record they physically hold. What is achievable is that alteration and deletion cannot be hidden, and that a gap in a chained record is itself a finding.
There is a second property that gets less attention. The capture path must not be disableable by the thing being recorded. A workload able to switch off its own recorder produces a record that goes missing exactly when it counts, and the failure mode is not hypothetical — a policy that has entered a bad state is not a reliable narrator of its own bad state. The recorder belongs outside the authority of the software it records, on the same principle that puts stop authority outside the authority of the policy.
Retention deserves a decision rather than a default as well. Investigations start late. A record that ages out on a schedule tuned for storage cost is a record that will be absent for the one event that mattered.
Evidence that cannot leave
A reconstruction record is the most sensitive material a facility holds. It is sensor-level imagery of the process, the people, and the layout, assembled around the one moment everybody wants to look at, which means it stays inside the boundary for the same reasons the rest of the raw record does.
That rules out the usual arrangement, in which the record is trustworthy because it was shipped somewhere the operator could not reach. The arrangement was never load-bearing anyway. Confidence in a record comes from signing and hardware-rooted identity, not from where the bytes are parked, and a record signed at capture is as verifiable inside the fence as outside it.
What the design has to provide instead is a way for an outside party to examine evidence in place: scoped, logged access to a specific window, inside the boundary, with signatures checkable against a chain that party can verify independently and a structure that reveals whether anything is missing. What leaves the site is the governed minimum — signed attestation and audit records stating what was running and what was captured, not the captured material. Someone outside can establish that a record exists, is intact, and covers the moment in question without seeing what is in it. Whether that is enough for a given accreditor or insurer gets settled per environment, and the architecture has to be able to enter that conversation with something more than a promise.
What reconstruction still cannot tell you
Perfect capture establishes what the machine sensed, what it believed, what it asked for, what it was permitted to do, what it was running, and when. It does not establish why the model preferred one action to another.
Replaying the inputs and observing the same output is reproduction, not explanation. It is worth having, because it separates a property of the model from a transient fault, and that is often the first thing anyone needs to know. It still does not recover a reason. A large learned policy does not carry reasons in the form the question assumes, and an explanation offered afterward is a story fitted to the behavior.
So the honest scope is narrower than the word reconstruction suggests, and stating the scope is part of the design. The operator's question can be answered: here is what the machine perceived, here is what it did, here is whether it stayed inside its limits, resume or do not resume. The safety officer's question can be answered: the constraining layer either held or it did not, and the record distinguishes a policy that asked for something it was refused from a machine that exceeded its bounds. What happened is answerable. Why a model preferred one action to another is not, and no volume of retained data changes that.
E31 Network is being designed so the record is a product of the system rather than a byproduct: capture on the edge node, retention and reconstruction inside the facility plane, signed audit rollup to the fleet plane, and no path by which a machine can quietly stop recording itself. The capability has to be in place before the event that needs it. There is no version of this that gets added afterward.