Ongoing Custom Data Collection Programs

A one-off custom egocentric order answers a fixed brief: a written spec, a Spec Pilot that proves it, and a delivery that closes out the engagement. An ongoing data collection program takes the same pipeline and keeps it running as a series of batches after that first pilot, so a buyer can keep adding coverage — new tasks, new failure cases, new scenes — as their model’s needs change, instead of treating each new data need as a separate order from scratch.

The unit of work does not change between a one-off order and an ongoing program: it is still a validated hour of first-person video, captured under a written spec, checked against a QA bar, and delivered under a license. What changes is the cadence — batches recur rather than a single delivery closing the engagement — and the fact that the spec itself is allowed to grow between batches as new requirements are identified.

A one-off order fits a fixed, known need: a defined set of tasks and scenes that will not meaningfully change once delivered. An ongoing program fits a model that is actively being trained, evaluated, and deployed, where testing or deployment keeps surfacing new failure cases and coverage gaps — the same dynamic described by the data flywheel, where a model’s failures are observed, turned into a new data requirement, and closed with targeted collection, then the cycle repeats.

Because the spec, pilot, and delivery pipeline are already proven after the first pilot batch, later batches in a program do not need to re-run the full specification process from zero — only the new or changed portion of the spec needs to be written up and piloted before the next batch scales.

An ongoing program starts exactly the way a one-off order does: a written skill spec covering the tasks, scenes, objects, and streams in scope, proven on a small, fast Spec Pilot batch before any volume is committed. The pilot is QA’d and delivered with a reject log and coverage report, the same reporting a full batch gets, so the spec and accept criteria are confirmed on real footage first.

What makes the engagement a program rather than a one-off is the decision, after that first pilot is accepted, to keep the same spec — and the pipeline that validated it — running as additional batches are scoped, rather than closing the engagement once the first delivery ships.

Each new requirement — a new task, a new failure case a deployed model surfaced, a scene or object variant that was thin in earlier coverage — is written up as a new cell added to the existing skill spec, the same way any task or scene is specified in a custom order: a clear start, end, outcome, and object set. The prior cells in the spec are not rewritten; the spec grows additively as new cells are appended.

Where a new cell represents a meaningfully different task or environment from what the pilot already validated, that cell can be piloted on its own small batch before it is scaled into a full-size batch, the same gap-driven pilot-then-scale approach used for a brand-new one-off order — applied to one cell of a larger, ongoing spec rather than to a whole new engagement.

Every batch in an ongoing program passes through the same QA gate as the pilot that validated the spec: 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 QA are rejected rather than delivered with a quality caveat, in every batch, not only the first.

This is the same consistency principle that holds a large-scale, single-order collection together across many contributors and sessions — a fixed calibration procedure and QA bar applied uniformly — extended across time instead of only across volume within one order. A reject log accompanies each batch, so the buyer can see what was screened out in that batch specifically.

A data flywheel is the loop an ongoing program is built to support: a model is tested or deployed, its failures are observed, those failures are written up as a new skill spec cell, targeted data is collected against that cell, and the retrained model is tested again. Each turn of the loop converts a specific, observed weakness into a precise data request rather than a generic instruction to "collect more."

Within an ongoing program, that loop maps directly onto the batch cadence: an observed failure becomes a new or updated spec cell, the next batch captures against it, and the data card that ships with that batch records which cells were captured and what was rejected — so each turn of the flywheel is documented, not just the first one.

Every contributor across every batch in a program signs the same consent release that governs a one-off order, and every session carries its own consent record through delivery — consent is handled per session throughout the program, not renegotiated at the start of each new batch. Anonymization is applied with the same scope used elsewhere on the site, per session, as part of the standard pipeline.

Licensing does not need to be re-established batch by batch either: delivery across the program ships under one perpetual, buyer-owned commercial license, the same licensing model used for any order size on this site, so each new batch becomes a permanent addition to a training pipeline the buyer already owns outright rather than a separately licensed asset.

Each batch in an ongoing program delivers in the same format the training pipeline expects — RLDS, LeRobot, WebDataset, HDF5, zarr, Rerun .rrd, or raw streams with metadata — specified once as part of the original spec and held constant across every later batch, so a pipeline does not need to re-integrate a new format each time a batch arrives.

Billing stays on the same unit across the program: per validated hour, per batch, rather than a single lump-sum price for the whole engagement. This keeps each batch’s cost tied directly to the validated hours it delivers, the same way a single pilot or one-off order is billed.

An ongoing program starts the same way any custom order does: a written brief covering the tasks, scenes, objects, and streams currently in scope, run through a Spec Pilot before any volume is committed. The difference is in planning for growth — flagging up front that this is expected to continue as a series of batches, so the spec, consent process, and delivery format are set up to extend cleanly as new cells are added later.

From there, each new requirement that emerges from testing or deployment is written up as a new spec cell and scheduled into the next batch, following the same pilot-or-scale decision used for any new cell: pilot it first if it is meaningfully new, or fold it directly into the next scaled batch if it closely matches a cell the spec has already proven.