Egocentric Data Collection Pilot

An egocentric data collection pilot — called a Spec Pilot — is a small, fast first batch of episodes captured against a buyer’s written skill spec. Its purpose is to prove the spec and the accept criteria on real footage before a buyer commits to the full volume of a custom collection, so the exact reject rate, coverage fill, and sync quality a buyer would get at scale are measured early, while the cost of being wrong is still small.

A pilot is not the same thing as a free sample pack. A sample pack shows existing footage already captured for a different purpose; a pilot is captured fresh against the buyer’s own written spec, so it proves that specific spec rather than a generic example of egocentric data.

Committing to full volume on a spec that has never been run against real footage means betting on how the plan reads on paper, not on what the data actually looks like once captured. A pilot replaces that bet with a measured result: the reject rate, coverage depth, and stream count the written spec actually produces, at low volume, before a larger commitment.

The pilot result can then be scored on the same criteria a buyer would use to evaluate any data source — sync error, annotation depth, license terms, consent handling, reject policy, and billing unit — before scaling. If the pilot surfaces a gap (a task definition that reads ambiguously, a label that needs tighter guidance), that correction happens once, on a small batch, rather than being repeated across the full order.

A pilot starts from the same written skill spec a full collection uses: the tasks to demonstrate, the scenes and objects involved, which streams to capture (RGB is the baseline; depth, IMU, and hand pose are added where the spec calls for them), which labels the training pipeline needs (hand pose, action segments), and the delivery format the pipeline expects.

A pilot does not require a larger standing program or a long-term commitment to start — a focused written brief covering tasks, scenes, and required streams and labels is a normal starting point for both a pilot and a full order.

A pilot delivers a small batch of episodes captured against the written spec, structured and labeled exactly as the spec defines — the same streams, the same action-segment and hand-pose labels where ordered, and the same delivery format (RLDS, LeRobot, WebDataset, HDF5, zarr, Rerun .rrd, or raw streams with metadata) the full order would use.

Alongside the episodes, a pilot ships with a reject log and a coverage report against the spec — the same reporting a full custom collection gets — so a buyer is scoring the pilot on exactly what a full order would look like, not on a simplified preview.

Pilot episodes pass through the same QA process as any egocentric order: calibration and synchronization checks on every active stream, and label and annotation review for hand pose and action segments where those are included. Episodes that fail are rejected rather than delivered with a quality caveat, and the reject decisions are recorded in the reject log that ships with the batch.

Because a pilot runs at low volume, a buyer can review every delivered episode against the written spec directly — checking that task definitions were followed consistently, that labels are aligned to the observation at each step, and that coverage of the specced tasks and scenes is adequate — before deciding whether to scale.

Turnaround depends on the scope specced and how deep existing coverage is for the tasks and scenes requested. Where coverage is already deep, a first batch can turn around with a median of 48 hours; broader or more novel specs run on the order of three to four weeks, the same range that applies to a full custom collection, since a pilot runs through the identical pipeline at a smaller scale rather than a shortened process.

Because a pilot is a smaller batch than a full order, its absolute turnaround is often faster in practice even within that range — but the pipeline steps (spec review, capture, QA, delivery) are the same ones a full collection goes through.

Pilot episodes ship under the same license as a full custom collection: perpetual, buyer-owned, and non-exclusive by default, not a hosted-access or research-only arrangement. Every contributor signs a consent release before capture, and that consent record travels with the episode through delivery; anonymization of bystander faces, plates, and screens is applied as a standard part of the pipeline for pilot batches the same way it is for a full order.

Billing for a pilot is per validated hour, the same unit used for a full collection — a pilot is priced as a smaller quantity of the same billing unit, not a separately structured trial fee.

Once a pilot batch is reviewed and accepted, the same written spec — corrected for anything the pilot surfaced — scales directly into the full order, without restarting the specification process. The streams, labels, and format already proven in the pilot carry forward, so the full collection is an extension of the validated plan rather than a new negotiation.

If the pilot does surface a correction — a task definition that needs tightening, a label that needs clearer guidance, a scene or object set that needs broadening — that correction is made once, on the small pilot batch, and the full order runs against the corrected spec rather than repeating the issue at volume.