Setting new_repo_id does not protect the local dataset that LeRobot’s annotation pipeline rewrites. It chooses a separate Hugging Face Hub destination for an upload; the documented writer still modifies local shards in place. Preserve a separate local source copy, inspect the staged labels, and check the rewritten dataset before using it for training.
The LeRobot annotation guide, checked October 15, 2026, describes module outputs staged as JSON Lines (JSONL), a validator, and a single shard writer. This article follows that documented workflow. No annotation model, writer or training job was run.
A separate Hub repository is only one copy boundary
Imagine a working dataset called assembly_source and an intended Hub destination called assembly_annotated. These are illustrative names, not repositories used for this article. Choosing the second name with new_repo_id can keep an upload separate from the source Hub repository. It does not turn the local assembly_source directory into an untouched archive.
Make a working copy before annotation and retain the original dataset’s content identity and metadata. Keep the input revision, episode selection, camera key, annotation settings and model identifier with the working copy. If a label is wrong, those records let you return to the same input instead of trying to reconstruct it from already rewritten shards.
Uploading is a separate decision. The guide documents push_to_hub as the upload control and new_repo_id as the alternative destination; without a new destination, an enabled upload targets the source repository. Check the local working path and the remote destination independently before starting the pipeline.
Read the staged events before they become dataset columns
The staging validator checks relationships that an individual JSON row cannot establish on its own. An event must land on an actual frame timestamp. Speech and interjection rows must have their companions, and each interjection timestamp must have a plan refresh. Visual question answering (VQA) assistant content must have the expected JSON shape. A memory row away from a subtask boundary produces a warning rather than the same hard error.
These checks matter at the boundary between staging and writing. A valid-looking interjection with no matching speech or refreshed plan can leave the resulting training conversation incomplete. Inspect the related rows together before accepting their conversion into the dataset’s language columns.
The validator cannot settle whether the words describe the video correctly. For example, “object released” might refer to a real frame timestamp while appearing before the gripper actually lets go. That is an illustrative semantic error. Compare the label with that frame and its neighbors; timestamp validity alone cannot expose it.
Reopen the working copy before uploading or training
For an initial trial, choose a small, explicit set of episodes. After the writer finishes, reopen that working dataset through the intended reader and trace a few labels back to their source frames:
- Confirm that episode identities and frame counts match the preserved input.
- Follow an interjection through its speech companion and plan refresh.
- Check which persistent subtask or plan applies before and after a transition, alongside the event at its exact frame.
This is a suggested acceptance procedure, not a reported test. Keep the staging outputs until those checks are complete. They explain what the writer consumed if a rewritten column differs from what you expected.
The dataset versioning and lineage guide explains how to retain the accepted result as a derived version. For this pipeline, the immediate safeguard is concrete: preserve the local source before the in-place writer runs, and treat the Hub destination as a separate setting.