Identify the timing events
Camera exposure, sensor measurement, command issuance, and command execution are different events. Ask which one each timestamp describes and whether streams share a clock or a documented relationship. A timestamp column does not by itself establish synchronization. The buyer needs enough context to interpret when an observation became available relative to the action associated with it.
Inspect the pairing policy
Controllers and cameras may produce records at different rates. Determine whether a delivered step uses the nearest image, the most recent available image, or another rule. Document interpolation, resampling, and dropped records. These choices can change what information the model is allowed to use, particularly when a future observation is paired with an earlier action.
Review transitions that expose errors
Use movements, contact events, or gripper changes that are identifiable in both the observations and records. Compare several points in an episode rather than one matching frame. A constant offset and a changing mismatch require different investigation. Retain the evidence reviewed and the source’s explanation instead of treating a visually plausible replay as a complete timing validation.
Set the task-specific requirement
The acceptable association depends on the learning problem and action interface. Describe which events must remain correctly paired and whether raw timing records are required for independent reconstruction. If a source cannot establish the needed timing, document the limitation before selection. Fiund can discuss these requirements for the particular proposed collection without assuming all robot datasets use the same timing scheme.
Review checklist
- Define timestamp events and clocks
- Document the step-pairing rule
- Inspect multiple identifiable transitions
- State timing evidence required for review