How Long Does Custom Robotics Data Collection Take?

The published timeline has two distinct parts. Before capture starts, a buyer and the pipeline agree a written skill spec — the task, the geometry, the condition budget, the reject rule, and the acceptance test — on a working call, plus an optional spec pilot to prove that spec at low volume. Once the spec is signed, the clock the site publishes begins: a median of 48 hours to the first validated batch where coverage is already deep, or three to four weeks where coverage is thin and operators still need to be recruited and vetted.

Scaling from that first batch to full volume does not restart the clock or the process. The identical pipeline — same spec, same accept and reject rules, same billing unit — simply runs at the volume the spec calls for, with the same per-batch QA and coverage reporting the whole way through.

A custom collection runs through the same seven-stage pipeline regardless of how deep or thin coverage is: discovery, specification, sourcing, capture, annotation and QA, anonymization, and licensed delivery. Discovery and specification happen before the spec is signed and are not counted in the published speed numbers; sourcing, capture, annotation, QA, anonymization, and delivery happen after, and that is the window the 48-hour and three-to-four-week figures describe.

Where coverage is already deep, the first validated batch lands in a median of 48 hours from a signed spec. That speed comes from a warm, already-screened contributor pool matched to the spec’s named cells, not from skipping consent, per-batch QA, or anonymization — every batch still clears the same reject rule and acceptance test regardless of how fast it ships.

See fast, on-demand data collection for the full breakdown of what makes that 48-hour figure possible.

A spec pilot is a small, fast first batch captured against the exact spec a full collection will use, run specifically to surface the real reject rate, coverage fill, and sync numbers before committing to full volume. Because the pilot uses the identical pipeline, spec, and accept criteria as the full collection, scaling afterward is not a new process risk — nothing is re-negotiated or re-specified between the pilot and full volume, only the number of validated hours captured changes.

A pilot is optional, not a mandatory step that adds time to every engagement. A buyer with a familiar spec and well-served population often moves straight to full volume; a pilot earns back its time on an unfamiliar condition mix, a rare embodiment, or a spec the buyer is not yet confident is complete, because it catches a coverage or reject-rate problem at low volume instead of at full scale.

QA runs per batch, not only at the end of the engagement: each batch is checked against the acceptance test and coverage is reported against the spec as it ships, rather than in one pass after everything is captured. Items that fail the reject rule are recaptured at no extra cost to the buyer rather than delivered anyway, which is why the published speed figures describe validated data, not raw footage that still needs a separate review pass before it is usable.

See video dataset quality assurance for how per-batch QA and the reject log work.

Working backward from a training deadline, the two numbers to plan against are the same ones the pipeline publishes: a median of 48 hours to a first batch in deep coverage, or three to four weeks where coverage is thin. A buyer with a hard deadline and a thin-coverage spec should start specification and sourcing well before the three-to-four-week mark, since vetting operators — not capture or QA — is the actual bottleneck in that case.

A spec pilot is the cheapest way to de-risk that plan: it turns an assumption about reject rate and coverage fill into a measured number before the buyer has committed the full budget or the full timeline to scaling. On-demand top-ups against the same accept criteria can then be run afterward if a training deadline shifts or a gap is found late.