Ten thousand clean hours beat a hundred thousand noisy ones

Every conversation about robot data starts with hours. How many hours do you have, how many can you collect a month, what does an hour cost. It is a convenient number because it is easy to count. It is also close to meaningless on its own.

The number that matters is how many of those hours survive contact with a training pipeline. We call it usable yield, and across our first projects it has ranged from under half to well above ninety percent depending almost entirely on decisions made before anyone pressed record.

Where the hours go

When an episode is rejected, it is almost never for an interesting reason. It is because a stream drifted out of sync, or the operator's hand left the frame during the grasp, or a rig was knocked at the start of a shift and nobody recalibrated it. Boring, mechanical, entirely preventable.

The problem is that none of those failures are visible while recording. A camera that has drifted eighty milliseconds looks exactly like one that has not. You find out weeks later, when someone tries to train on it.

A dataset that is 60% usable is not 60% of a good dataset. It is a dataset you cannot trust without checking every episode by hand.

What we measure instead

On every batch we report three numbers alongside raw hours:

1. Usable yield. The fraction of recorded episodes that pass every automated check and human review. This is the number we hold ourselves to, not gross hours.
2. Coverage against spec. How the delivered episodes are distributed across operators, sites, lighting conditions and task variants, compared to the distribution agreed at scoping.
3. Failure representation. What proportion of episodes contain a genuine failure and recovery, rather than only clean successful runs.

The third one surprises people. Most vendors treat a failed attempt as waste and delete it. But a policy that has only ever seen successful demonstrations has no idea what to do the first time a grasp slips, and that moment arrives within minutes of deployment.

What changed on our side

Checks moved to the device

Sync validation and calibration checks now run on the capture rig itself, and the operator sees a status readout during the session. A failed sensor gets caught in the first minute rather than the following week.

Rejected episodes get re-shot

If an episode fails QA, it is re-recorded against the same protocol. It does not silently disappear from the count, and it does not get delivered with a caveat buried in a README.

We price on delivered, not recorded

This is the part that took the longest internally. Pricing on recorded hours puts the risk of bad capture on the customer. Pricing on delivered, QA-passed hours puts it on us, which is where it belongs, because we are the only ones who can control it.

We write up what we learn as we go. If you want the detail behind any of this, or you are scoping a collection programme, talk to our team.