How to Version a Robot Pretraining Dataset

A pretraining dataset built through custom data collection is rarely delivered once. An ongoing data collection program runs the same written-spec, pilot, QA, and licensed-delivery pipeline repeatedly, as a series of batches, so new tasks, new environments, and new failure cases can be added to the spec and captured as they are identified, rather than reopening a one-off order every time a model needs more data. That repetition is exactly why versioning matters: without a clear record of which spec a batch was captured against, which QA pass it cleared, and which format fields it shipped with, a buyer training on the accumulated corpus cannot say with confidence what changed between one delivery and the next, or why.

The risk is not hypothetical. If a later batch is quietly captured against a looser read of the spec, or reviewed with a different QA pass than the batch before it, mixing the two into one training run teaches a model on data that looks uniform but is not. Versioning is the discipline that keeps that from happening silently: it names what stayed the same, what changed, and where the record of that change lives, so a buyer can decide whether two batches belong in the same training run or need to be treated separately.

This guide covers how to version a pretraining dataset delivered in batches over time, using the written skill spec, the batch, the data card, the episode schema, and the delivery format already described elsewhere on this site. It is not a stand-alone spec-writing guide — see how to write a skill spec for that — and it is not the ongoing program’s sales page, which covers program structure rather than version tracking mechanics.

A dataset version is not a single number stamped on a zip file. It is the combination of five things that each carry their own record: the written skill spec a batch was captured against, the batch itself as the unit of delivery, the data card that documents that batch, the episode schema every episode in the batch follows, and the delivery format that schema is packaged into. Tracking a version means knowing where each of these five lives and keeping them aligned when any one of them changes.

In an ongoing data collection program, the written skill spec that passed the Spec Pilot carries forward into every later batch rather than being replaced. New tasks, environments, or failure cases identified after delivery are added to the spec as new cells, not as a rewrite of the whole document. That matters for versioning because it means a spec version is additive and traceable: a batch captured early in the program stays valid against the version of the spec it was actually captured under, even after later cells are added for new coverage.

Spec corrections work the same way. If a coverage gap is found during a pilot sample — the kind of gap a diversity plan is designed to catch before scaling — the fix is to correct the relevant cell of the spec and re-validate it, not to discard everything captured so far. Each cell’s version history is really the sequence of batches captured against it, which is why the batch and the spec cell have to be tracked together rather than as separate, unlinked records.

Every batch in an ongoing program passes through the same calibration, sync, and label review as the pilot that originally validated the spec, so later batches do not quietly drift from the quality bar the first batch set. Footage that does not clear the spec’s written accept and reject criteria is rejected and recaptured rather than delivered with a caveat. That consistency is what makes versioning meaningful in the first place: if the acceptance bar moved between batches, a buyer could not treat two batches as the same version even if they were captured against the same spec, because they would not have been held to the same standard.

In practice, that means a version comparison is really a QA comparison. Before mixing two batches into one training run, the question to check is not just "were these captured against the same spec cell" but "did both clear the same calibration, sync, and label review, and does each batch’s data card confirm it."

The batch is the practical unit a buyer can identify a version by: each batch is captured, run through its own QA pass, delivered, and billed per validated hour on its own, with its own data card. That data card is what carries the batch-level identity forward — the jurisdictions of capture, the consent basis, the detector version and pass timestamp, and the reject log all belong to one specific batch, not to the program as an undifferentiated whole.

Underneath the batch, identity also lives at the episode level. The episode schema’s meta.json group carries episode_id, skill_id, site_id, and participant_id for every episode, which is what keeps individual episodes traceable even after several batches have been merged into one training corpus. A buyer can trace any single episode back to the skill and site it was captured for, and back to the batch’s data card, independent of which delivery format that episode was eventually exported into.

Every delivery format on this site — RLDS, LeRobot, WebDataset, HDF5/zarr, and Rerun .rrd — is a projection of the same underlying episode schema, so choosing a format is a packaging decision, not a data-completeness one. But the formats differ in how much version information they carry inside the file itself, and that difference matters when a buyer is comparing batches delivered in the same format over time.

Only the LeRobot layout carries an explicit version string inside the delivered files. For RLDS, WebDataset, and HDF5/zarr deliveries, version tracking has to live outside the file — at the batch and data-card level — rather than being something a loader can read off the format itself.

Every contributor across every batch in an ongoing program signs the same consent release used in the pilot, and every batch ships under the same perpetual, buyer-owned commercial license — the license does not need to be renegotiated batch by batch. That carry-forward licensing is what makes an ongoing program practical, but it does not mean provenance is tracked as one undifferentiated blanket statement for the whole program.

Each batch’s own data card documents its jurisdictions of capture, its consent basis, its de-identification detector version, the pass timestamp, and the reviewer who confirmed it, so any specific batch’s provenance can be audited on its own rather than taken on faith for the program as a whole. Versioning provenance, in practice, means keeping that per-batch data card intact and attached to the batch it describes, even after multiple batches are combined into one training corpus.

Versioning is easiest to plan for before the first batch ships, not after several batches have already accumulated. For a fast, on-demand custom collection, that means writing the skill spec once with explicit accept and reject criteria and naming the delivery format up front, then treating the Spec Pilot’s validated first batch as the baseline version everything else is compared against.

• Write the skill spec with accept and reject criteria and a named delivery format before the first batch is captured, so later comparisons have a fixed reference point.
• Treat the Spec Pilot’s validated batch as the baseline version, with its data card as the first provenance record for the program.
• When a new task, environment, or failure case is identified, add it to the spec as a new cell rather than rewriting the existing cells a prior batch was captured against.
• Hold every later batch to the same calibration, sync, and label review as the pilot, so a version comparison is also a QA comparison.
• Keep each batch’s data card attached to that batch specifically, so provenance and consent can be audited batch by batch rather than for the program as a whole.
• Before mixing batches into one training run, check the data card’s detector version and pass timestamp alongside the format field mapping, since only LeRobot carries an explicit layout version inside the delivered files.