A Replay File Is Not an Incident Timeline by Itself

When a team opens a replay file after a robotic system behaves unexpectedly, a familiar assumption takes hold: the recording shows what the robot actually did, and therefore the incident is understood. This assumption deserves scrutiny. A replay file is not an incident timeline by itself. It is a stored collection of recorded topic messages, and the gap between that collection and a trustworthy narrative about what happened on a physical system is exactly the kind of gap that provenance description is designed to bridge. The following sections explain what recorded topic messages supply, why a narrative timeline needs explicit provenance, and what a handover reviewer should ask before accepting a replay as evidence of a real outcome.

What a replay file actually contains

A replay file, such as one produced by ROS 2 Jazzy rosbag2, records topic data and can replay recorded messages. According to the ROS 2 documentation, ros2 bag is a command line tool for recording data published on topics and services in a ROS 2 system, which accumulates the data passed on any number of topics and services and saves it in a database. The file contains serialized messages published on named topics, along with metadata such as timestamps and topic identifiers. The documentation also notes that replaying data can reproduce the results of tests and experiments, but a stored recording and a live physical system remain distinct. Replaying a message recording alone does not establish that a real machine reproduced an earlier outcome.

This distinction matters because a stored recording and a live physical system are different. When a reviewer watches a replay and sees a joint angle reach a certain value, the reviewer is observing data that was captured at some earlier time, under conditions that may or may not be fully documented. The replay shows what was recorded, not necessarily what the physical robot experienced. Treating the replay as equivalent to a live observation conflates a data artifact with a physical event.

Why a narrative timeline is more than a replay

An incident timeline is a narrative construction. It arranges events in order, assigns causes, identifies responsible actors, and often recommends corrective actions. A replay file can contribute to such a timeline, but it cannot stand in for the timeline itself because the timeline requires judgments that the recording alone does not encode. For example, a timeline must decide which recorded messages are relevant, which gaps in the recording are significant, and whether the conditions under which the recording was made match the conditions under which the incident is said to have occurred.

These judgments are editorial in nature. They involve selecting, weighting, and interpreting evidence. A replay file does not make these decisions; the people who construct the timeline do. Without explicit documentation of those decisions, a timeline appears to emerge directly from the data, when in fact it has been shaped by human choices that remain invisible. This is why provenance matters: a timeline that does not disclose its own construction is a claim without an audit trail.

Provenance as a framework for trustworthy timelines

The W3C PROV Primer introduces entities, activities, and agents as the core elements of provenance description. According to the primer, PROV defines a core data model for building representations of entities, people, and processes involved in producing a piece of data or thing in the world. Entities are things, activities are processes involving things, and agents are responsible actors. Applied to incident analysis, an entity might be the replay file itself, an activity might be the process of constructing a timeline from that file, and an agent might be the engineer who performed the construction. Provenance descriptions record relationships among these elements; they show which agent used which entity in which activity to produce which output.

The PROV concepts provide a way to document how a timeline was constructed. As an editorial inference, merely writing those relationships does not independently verify them. A reviewer can ask who built the narrative, which recordings were used, what interpretation was applied and which gaps remain. If the answers are missing, the record is incomplete for those questions; if answers are present, their supporting evidence still needs evaluation. This is a method of making interpretation visible, not a promise that any structured record is true.

What recorded topic messages supply to a handover review

For a handover reviewer, recorded topic messages supply a partial evidentiary base. They provide concrete data points that can be checked, compared, and replayed. They establish that certain messages were published on certain topics at certain times. They do not, by themselves, establish what those messages meant in the context of the physical system, whether the recording is complete, or whether the system was operating within its intended parameters when the recording was made.

A reviewer receiving a handover package that includes a replay file should treat the file as one input among several. The file is not a substitute for a written account of the incident, a description of the system configuration at the time of recording, or a statement of the conditions under which the recording was started and stopped. The reviewer should also consider whether the recording was made prospectively, as part of routine monitoring, or retrospectively, after the incident was already suspected. The purpose and timing of the recording affect its evidentiary value, and those details belong in the provenance record.

Questions a handover reviewer should ask

Rather than accepting a replay file as a complete account, a handover reviewer should ask specific questions that probe the provenance and limits of the recording. These questions are not accusations; they are standard checks that any careful reviewer would apply to any evidentiary artifact.

First, what topics were recorded, and what topics were not? A recording that omits safety-related topics, diagnostic topics, or operator input topics presents a selective view of the system's behavior. The reviewer should ask whether the selection was intentional and documented.

Second, what is the relationship between the recording period and the period of interest? A recording that starts after the event of interest has already begun, or that ends before the consequences have fully unfolded, is a fragment. The reviewer should ask whether the fragment has been presented as if it were complete.

Third, who initiated the recording, and under what circumstances? If the recording was started by an operator who was already concerned about the system's behavior, that context matters. If it was started automatically as part of a routine logging process, a different context applies. The reviewer should ask for this information explicitly, because it affects how the recording should be weighted in the timeline.

Fourth, has the recording been processed or filtered before being presented as evidence? Any transformation applied to the original messages, such as downsampling, topic remapping, or timestamp adjustment, changes the evidentiary character of the file. The reviewer should ask what transformations were applied and who authorized them.

Fifth, does the narrative timeline cite the replay file as its sole source, or does it incorporate other evidence such as witness statements, system logs, or physical inspection results? A timeline built entirely from a replay file is a timeline built from a single, limited source. The reviewer should ask whether corroborating evidence exists and whether it has been considered.

Building a timeline that can be inspected

The goal is not to discard replay files but to use them within a framework that makes the resulting timeline inspectable. This means documenting the provenance of the timeline itself: which entities were used, which activities transformed them, and which agents performed those transformations. It means separating the recorded data from the interpretive claims built on top of that data. It means making visible the editorial choices that turn a collection of messages into a narrative about what happened.

When a handover package includes a replay file, a written provenance description, and a narrative timeline that explicitly references both, the reviewer has something to evaluate. When the package includes only the replay file and a timeline that appears to emerge directly from it, the reviewer has an assertion without an audit trail. The difference between these two packages is the difference between evidence that can be scrutinized and evidence that must be taken on trust. For a handover reviewer, that difference is the central concern.

Related archival resources

For related reading, this site’s technical articles and article archive provide navigation to published discussions. Those pages do not constitute an incident evidence repository. A handover reviewer should return to the actual recording and documented analysis before making a statement about the event.