Robot Pretraining Data Quality Checklist

A fine-tuning or post-training dataset is checked against one target task and one target robot: does this specific manipulation succeed enough times, on this specific rig, to fine-tune a deployed policy? A pretraining corpus is checked against a much wider job — teaching general visual, physical and action priors before the model ever sees the target robot — so the same six quality signals from the general robotics dataset quality checklist have to be verified across scale, not just within one collection session.

That distinction matters because a pretraining corpus can pass every quality check on any single clip and still be weak in aggregate, if the clips are diverse-looking but statistically narrow — the same few scenes, the same few object categories, or the same few contributors repeated at large volume. Pretraining-scale quality checking is therefore as much about coverage across the whole corpus as it is about any individual hour of footage.

This checklist is deliberately scoped to sit alongside the general robotics dataset quality checklist rather than replace it: the underlying signals (sync error, validated hours, failure coverage, consent, format) are the same ones used to evaluate a single-task dataset. What changes at pretraining scale is which questions need to be asked of the whole corpus rather than of one collection batch, and that reframing is the focus of the seven checks below. Each check is written as a question a buyer can put directly to a public dataset’s documentation or a custom collection provider, rather than a vague quality standard to take on trust.

At pretraining scale, diversity is checked along at least four axes at once: physical scenes and environments, the range of tasks demonstrated, the object categories involved, and the number and variety of the people performing them. A corpus can look large by hour count and still be narrow if most of that volume comes from a handful of environments or a small pool of contributors.

GEN-0’s own framing backs this directly: the team states that data quality and diversity matters more than sheer volume — see the mixture-planning discussion in how to build a robot pretraining data mixture.

Egocentric human video is not naturally labeled with the actions a robot policy needs to learn from, which is why the labeling method matters as much as the footage itself. EgoScale’s published methodology derives action labels from off-the-shelf SLAM and hand-pose estimation rather than manual annotation, at the scale of its 20,854-hour corpus. Checking label quality means asking what method produced the labels, whether that method is documented, and whether it was applied consistently across the whole corpus rather than on a labeled subset.

GR00T N1’s data pyramid approach takes this further for footage that has no action labels at all: it uses latent actions and inverse-dynamics pseudo-labeling so unlabeled video can still contribute to pretraining, rather than being discarded. A pretraining-scale quality check should ask whether unlabeled footage is being used this way, and if so, what confidence or filtering step is applied before those pseudo-labels are trusted.

For a custom collection, label quality is easier to check than for a public corpus, because the labeling method can be specified in the capture spec itself rather than reverse-engineered from documentation after delivery. Specifying a labeling method up front, and requiring it to be applied consistently across every session rather than on a sampled subset, removes most of the ambiguity that this check has to resolve for a public dataset assembled by a third party.

A single collection session can have clean calibration and still contribute noisy data to a pretraining corpus if the calibration procedure was not applied the same way across every contributor, every rig, and every session over the life of a large collection program. At pretraining scale, this check is about consistency of process across weeks or months of capture, not just correctness on one day.

In practice that means checking whether camera intrinsics were re-derived or reused as a rig ages, whether a rig swap mid-program reset the calibration baseline, and whether the calibration record for each session is stored alongside the footage rather than kept separately where it can drift out of sync with what was actually captured. A corpus with mismatched or undocumented intrinsics across sessions is harder to use reliably for downstream 3D reconstruction and pose estimation, even if any single session looks fine in isolation.

The same cross-stream sync-error check that applies to any robotics dataset applies here, but it needs to be verified across the full pretraining corpus rather than spot-checked on a sample. Video, depth and pose should be hardware-triggered off a shared clock using PTP (IEEE 1588), and every hour — not just a sample batch — should have a documented sync-error number against a fixed ceiling before it is counted as validated. This sits alongside the calibration check above as one of the two hardware-level checks that determine whether a corpus can be trusted for downstream 3D and multimodal training, independent of how diverse or well-labeled its content is.

At pretraining scale this becomes an operational question as much as a technical one: does the collection program log a sync-error number per session automatically, or does verification depend on someone manually sampling a subset of hours after the fact? A corpus where sync error is only checked on a sample can hide sessions where a clock drifted or a trigger failed silently, which is exactly the kind of defect that a validated-hours count is meant to screen out before those hours are counted toward the total.

A pretraining corpus built entirely from clean successful demonstrations does not teach a model what a stall, slip, or correction looks like — the same gap that matters for fine-tuning datasets, but harder to catch at pretraining scale because failure-case coverage tends to shrink as a percentage of total hours the larger a corpus grows, unless it is planned for explicitly in the collection spec.

Checking this at pretraining scale means asking for a failure-case percentage as a stated target in the collection spec, not just a qualitative claim that failures are included. A spec that defines what counts as a failure case (a dropped object, a missed grasp, a recovery attempt) and sets a minimum share of total hours for that category is verifiable after delivery in a way that an unquantified claim is not.

At small scale, a documented consent chain is checkable clip by clip. At pretraining scale — tens of thousands of hours across potentially hundreds of contributors — the check that matters is whether the consent-chain documentation and anonymization pipeline (face, license plate, and screen blurring) were applied systematically across the entire corpus, not whether any single sampled clip looks compliant.

That systematic check has two parts: whether every contributor has a recorded consent record tied to their specific footage, and whether the anonymization pass ran on one hundred percent of delivered hours rather than a subset flagged for manual review. A pretraining corpus assembled from multiple contributors and collection batches over time is only as strong as its weakest batch on this check, since a single unreviewed batch can undermine the licensability of the whole delivery.

A pretraining corpus is only useful if it loads into an existing training stack without a custom parser. Standard formats — RLDS, LeRobot, WebDataset, or HDF5 — should be checked for consistency across the whole delivery, since a corpus assembled from multiple collection batches over time can drift into inconsistent formatting if this is not enforced as part of the delivery spec.

This includes checking that metadata schemas match across batches — the same field names, the same units, the same episode structure — so a training pipeline built against the first batch of a corpus does not need to be rewritten to ingest the second. Format consistency is easy to overlook during collection and expensive to fix after the fact, which is why it belongs in the delivery spec from the start rather than as a post-delivery cleanup step.

Combining the checks above into a single pass/fail reference for evaluating a pretraining-scale corpus, whether it is a public dataset or a custom collection.

Each of the seven checks above can be written directly into a capture spec for a custom pretraining collection, rather than inspected after delivery: target diversity across scenes, tasks, objects and contributors; a defined labeling method; a calibration and sync-error ceiling enforced across every session; a required percentage of failure cases; a documented consent chain per contributor; and a specified delivery format. Planning the corpus against a spec like this from the start is faster and more reliable than auditing a large delivered dataset after the fact.

This is the same spec-first approach described in how to collect robot pretraining data: writing the pretraining spec before collection begins, running a pilot before scaling, and building QA and consent verification into the collection workflow rather than treating them as a final audit step. A custom pretraining collection built against a checklist like this one gives a buyer a verifiable answer to every question in the table above at delivery time, rather than a set of claims that have to be taken on trust.