What Is Batch Delivery in Data Collection?

In data collection, a batch is a unit of finished data that has passed QA against the agreed spec. Batch delivery means each batch is handed over once it clears, instead of being held back until the whole program is done. The value for a buyer is feedback. A first batch shows real reject rates, coverage and format on real footage, so the spec can be corrected before the remaining volume is captured. A single final delivery gives that feedback only when all the work is finished, which is when a wrong assumption costs most. The site’s own wording is rolling delivery per validated batch.

Firsthand states that batches are rolling and delivered per validated batch. The first validated batch arrives in a median of 48 hours from a signed spec where coverage is already deep, and in three to four weeks where contributors must be recruited first. A Spec Pilot, a small, fast first batch, is the optional starting point. After the first batch, delivery is rolling, and on-demand top-ups run against the same spec after each training run. Each batch is checked against the signed accept criteria, failed items are recaptured, and delivery ships under a perpetual, irrevocable, buyer-owned commercial license that is non-exclusive by default. Cadence, volume per batch and later-batch turnaround are not stated.

Both end with the same dataset. The difference is when you see it and how much you hold at each point. A single final delivery hands over everything at the end of the program, while batch delivery hands over validated pieces along the way. Because each batch is checked on its own, a problem found in batch one, such as a thin condition cell or a stream that is not in the format your loader expects, can be fixed in the spec before it is repeated across the program.

Batch delivery is not a lower bar. The site states that every batch passes the same calibration, sync and label review as the pilot, and that failing episodes are rejected rather than delivered with a caveat. What changes is cadence, not standard. The first table below compares the two on the attributes the site states and marks the rest as not described.

On this site each batch ships with a data card, consent artefacts and a reject log. The data card records the jurisdictions of capture, the consent basis and the de-identification pass, and notes which spec cells were captured and what was rejected. Coverage is reported per batch against the skill spec, as fill rates by condition rather than one hour count.

The data follows the canonical episode schema, the layout every delivery format projects from, with meta, streams, annotations and calibration groups. The format is set once in the original spec and held constant across later batches, so a training pipeline does not re-integrate a new layout each time data arrives. The named formats are RLDS, LeRobot, WebDataset, HDF5, zarr and Rerun .rrd.

A Spec Pilot is the first batch: small, fast and captured against the exact spec a full collection would use, with the same reject log and coverage reporting. It is optional, and a buyer with a familiar spec often moves straight to full volume. Production then runs the same spec, accept criteria and billing unit at higher volume, billed per validated hour, per batch.

In an ongoing program the spec keeps changing between batches. New tasks or failure cases are added as new cells and prior cells are not rewritten. A top-up after a training run is a new batch against the same spec, so the new data stays consistent with what the buyer already holds. How often batches run is not stated.

The official format documentation describes structures built from units rather than one monolith, though none of it describes Firsthand’s pipeline. RLDS defines a dataset as episodes that each contain steps, and its optional episode_id is meant to be unique across datasets so they can be merged easily. WebDataset stores samples in numbered tar shards and states that any collection of shards can be read. LeRobotDataset v3 stores many episodes per Parquet and MP4 file and resolves episode boundaries through metadata, not file names. The site does not state how a Firsthand batch maps to episodes, files or shards, so confirm that in the spec.

Start from a described gap, which becomes a written skill spec with accept and reject criteria. Then write the items the site leaves open into the spec as requirements: batch cadence, volume per batch, turnaround for second and later batches, minimum term, SLA terms and price. Name the delivery format once, and ask for the data card and reject log with every batch. Exclusivity, where a program needs it, is a separate term in the order form, which governs over any summary on a website. When the scope is ready, request a custom dataset.

What is batch delivery in data collection?

Delivering a custom dataset as a series of validated batches over time instead of one final hand-off. Each batch is checked against the written spec before it ships.

Is batch delivery the same as rolling data delivery?

On this site, yes: it states rolling delivery per validated batch. Rolling describes the cadence, and each batch is still validated first.

What does each batch include?

A data card, consent artefacts and a reject log, with coverage reported per batch against the skill spec.

How fast does the first batch arrive?

A median of 48 hours from a signed spec where coverage is deep, and three to four weeks where contributors must be recruited first.

How often do later batches arrive?

Not stated. The site gives no cadence interval, volume per batch or turnaround for second and later batches, so ask in the spec conversation.

Does the licence change between batches?

No. The perpetual, irrevocable, buyer-owned commercial licence, non-exclusive by default, carries forward across batches without renegotiation.

Can the format change between batches?

The format is set once in the spec and held constant across later batches, so the training pipeline does not re-integrate a new layout.