Short answer
A robotics dataset needs documentation beyond a file listing: why it was collected, which robots, sensors and people it involves, how it was labeled, what it should not be used for, and what rights attach. Datasheets, data cards and dataset cards give the structure. Adapt them with embodiment, action space, synchronization, calibration and permission fields, and reject undocumented offers.
The buyer's problem
Image and text datasets can often be judged by browsing. Robotics datasets cannot. A trajectory archive may hold the right number of episodes and still be unusable because action conventions are undocumented, calibration is missing or the camera clock is unknown. The evidence a buyer needs sits in documentation, and documentation is often the first thing a supplier has not written.
This page adapts existing dataset-documentation formats into a checklist for physical-world data. It supports the review steps in the dataset evaluation checklist and the sample review in requesting and reviewing dataset samples.
Three documentation formats
Datasheets for Datasets. Gebru and colleagues proposed that every dataset be accompanied by a datasheet documenting its motivation, composition, collection process, recommended uses and more, by analogy to the datasheets that accompany electronic components (Gebru et al., 2018). The paper includes prototype datasheets for two existing datasets. It is a set of questions, not a format file.
Data Cards. Pushkarna and colleagues describe Data Cards as structured summaries of the essential facts about a machine learning dataset that stakeholders need across its lifecycle, reporting two case studies and lessons from deploying more than 20 Data Cards (Pushkarna et al., 2022). The emphasis is on information for different readers, not only the dataset's builders.
Dataset cards on the Hugging Face Hub. A dataset card is the README.md in a dataset repository, rendered on the dataset's page. The documentation recommends documenting potential biases and how the data should be used, and a YAML metadata block at the top of the README (fields such as language, pretty_name, tags, license and task_categories) describes license, language and size and supplies tags for discovery (Hugging Face). For robotics data, that header is a useful machine-readable minimum. It is not enough on its own.
None of these was written for physical-world data. They omit the questions a robot-learning team must ask.
What robotics datasets need added
| Documentation area | Added robotics fields |
|---|---|
| Motivation | Intended task family, intended embodiment, intended use (pretraining, imitation, evaluation) |
| Composition | Episodes, hours, sites, operators, objects, success and failure counts by stratum |
| Embodiment | Robot or human capture device, kinematics, end effector, sensors; see cross-embodiment robot datasets |
| Action space | Joint vs end-effector, absolute vs delta, control frequency; see action space and control frequency |
| Sensors and time | Streams, frame rates, clock sources, synchronization method, drift; see sensor synchronization requirements |
| Calibration | Intrinsics, extrinsics, hand-eye, per-session records; see calibration requirements |
| Collection process | Teleoperation interface, scripts, operator instructions, resets, who judged success; see teleoperation data collection requirements |
| Labeling | Definitions, annotators, guidelines, agreement checks, known label noise |
| Preprocessing | Redaction, filtering, resampling, compression, with versions |
| Splits | How train, validation and test were separated; see training vs evaluation datasets |
| Format | Container, schema, version; see robot learning data formats |
| Rights and people | Source, consent basis, permitted uses, exclusions, third-party content, retention |
| Maintenance | Version history, contact, errata process |
DROID is a concrete example of what a robotics collection records per episode: camera calibration, depth and language instructions, collected by 50 data collectors across North America, Asia and Europe over 12 months on one replicated rig (Khazatsky et al., 2024). The point is not that every dataset needs the same fields, but that these facts exist for the supplier to report and for the buyer to ask about.
Illustrative robotics data card (skeleton)
<!-- Illustrative only - synthetic values; adapt to your requirement -->
---
pretty_name: workplace_task_demos_v0
license: custom-commercial (see LICENSE_SUMMARY)
task_categories: [robotics]
tags: [manipulation, egocentric, force]
---
# Dataset card: workplace_task_demos_v0
## Purpose and intended use
Imitation learning for tabletop assembly; not for person identification.
## Composition
Episodes by site (site_017: 410, site_021: 122), operator count 14 (operator_A01-A14),
success/failure counts per task, object list in objects.csv.
## Embodiment and capture
Human wearing head camera and instrumented tool; no robot actions recorded.
## Action space
None recorded. Hand pose tracks derived by method X, version Y.
## Sensors, time, calibration
Streams, rates, clock source, measured drift per session, calibration files per session.
## Collection and labeling
Scripts, operator instructions, annotator guidelines, agreement measured on 10% re-annotation.
## Splits
By site and by time; held-out set not to be mixed into training.
## Rights and permissions
Source and consent basis, allowed uses, exclusions, third-party content register.
## Known limitations
Happy-path bias; limited lighting variety; blurred regions listed per clip.
## Versions and contact
Review checklist: judging a supplier's documentation
Mark pass, fail or not-determinable, and request evidence.
- A named document (datasheet, data card or dataset card) exists and is versioned.
- Intended and out-of-scope uses are stated.
- Composition is reported by stratum, not as a single total.
- Embodiment, sensor and action-space fields are filled, or stated as absent.
- Synchronization and calibration are documented per session, not only in general.
- Labeling method includes definitions, guidelines and a quality measure.
- Redaction and filtering steps are listed, with their effect on content.
- Split method is stated and independent of the buyer's evaluation needs.
- Rights, consent basis and third-party content are described in the same document or referenced from it; see provenance and chain of custody.
- Known limitations are stated candidly.
Related specifications live elsewhere: a requirements specification states what you need, while a robot trajectory dataset specification states the fields a trajectory collection should deliver. The card documents what the supplier actually produced, so compare the two line by line.
Red flags: marketing language in place of fields, totals with no breakdown, "available on request" for every technical detail, and documentation that contradicts the sample.
Limitations
A datasheet is a statement by the party that made the dataset. It can be wrong, incomplete or out of date. Cross-check it against a sample and, where it matters, an independent audit. Documentation also does not itself create rights or consent. Conversely, a well-documented dataset can still be unsuitable for your architecture; documentation lets you find that out sooner. Teams should also expect to write their own internal card for any dataset they combine or relabel.
Questions to ask suppliers
- Is there a datasheet, data card or dataset card, and which version corresponds to this offer?
- What are the intended uses and out-of-scope uses?
- How are episodes broken down by site, operator, object and outcome?
- Which embodiment, sensors and action space apply, or are absent?
- How are time synchronization and calibration documented per session?
- How were labels produced, and how was their quality measured?
- What preprocessing, redaction or filtering was applied, in which versions?
- How were splits made, and which sets are meant for evaluation only?
- Where are consent basis, permitted uses and third-party content documented?
Discuss your requirements
If you want documentation requirements built into a purchase, describe the dataset kind, evaluation criteria and licensing requirements to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. See the humanoid training data guide and the procurement hub.
Describe the workplace demonstration data your robotics project needs
Sources
- Datasheets for Datasets — Datasheets for Datasets: motivation, composition, collection process, recommended uses.
- Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI — Data Cards: structured summaries of dataset facts, 20+ deployed cards.
- Dataset Cards (Hugging Face Hub documentation) — Hugging Face dataset cards: README.md with YAML metadata block.
- DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — DROID per-episode calibration, depth and language; 50 collectors, 12 months.