Robotics Training Data Validation

A raw hour of footage can fail for more than one reason — drifted sync, a calibration that moved mid-session, a coverage cell the spec required but the footage never captured, or a participant whose consent was never documented. Validation runs each of those checks independently on every hour, rather than issuing one overall pass or fail, so it is clear exactly which check an hour failed rather than just that it was rejected.

Video, depth, and pose streams are hardware-triggered off a shared clock using PTP (IEEE 1588). The sync check measures how far those streams have actually drifted apart on that clock and compares it against a fixed rejection ceiling — it is a measured number, not an assumption based on the hardware spec. See the full methodology for how that measurement and ceiling are defined.

The calibration check confirms that camera and depth calibration solved correctly for the session and stayed within drift tolerance throughout — a calibration that was correct at the start but moved during capture still fails this check. The coverage check compares the footage against the coverage cells defined in the capture spec, so a session that ran long but never captured a required task or environment still doesn’t count toward that cell.

Every participant appearing in the footage needs documented consent tied to that specific footage before the hour counts as validated. This is what makes the resulting consent chain traceable clip by clip rather than a blanket claim that consent was obtained.

An hour that fails any of the four checks is not delivered and is not counted toward the validated-hour total — it does not ship as a lower-quality tier. This is what keeps a validated-hour count meaningful: every hour in a delivered dataset has passed the same checks, rather than some passing at a discount.

Because each check is defined against a written capture spec — the sync ceiling, the calibration tolerance, the coverage cells, the consent requirement — a buyer can ask for the sync-error number, the coverage report against the spec, and the consent-chain documentation directly, rather than accepting a general quality claim. The dataset quality checklist covers the same four signals from the buyer’s side of that conversation.