Short answer
For robotics data, provenance is the verifiable record of who recorded each item, where, when, with what device and under what permissions, plus every processing step since. Chain of custody adds who held the data at each hand-off and how integrity was kept. Ask for item-level records and checksums at each hand-off; a single statement about a dataset's origin does not substitute.
Why recorded physical work needs more than a license label
For text corpora, provenance is mostly licensing lineage: where a document came from and under what terms. Recorded physical work adds people, sites, devices, calibrations, robots, operators and annotation passes, and each can change what you may do with an item or how far you can trust it.
License labels alone are unreliable even in the simpler case. The Data Provenance Initiative audited 1,800+ text datasets and found that, after re-annotation, 66% of the Hugging Face licenses it analyzed fell into a different use category, often a more permissive one than the author's own license; it also cut the share of "Unspecified" licenses from 72%+ to 30% (Longpre et al., 2023). That audit covered text, but the failure mode carries over. A tag on a repository or a line in a sales sheet is not provenance. Trace the item back to the source and read the original terms.
Two chains to document
The custody chain is technical: capture, storage, processing and transfer, with the integrity of the bytes preserved at each step. The rights chain is contractual: the person or business that recorded or created the material, each agreement that passed rights along, and the license you receive. A dataset can have a clean custody chain and a broken rights chain, or the reverse. Evaluate both.
| Stage | Record at this stage | Evidence to request | Weak data it exposes |
|---|---|---|---|
| Capture event | Recorder, site, date, task, operator or demonstrator ID | Capture log or session register | Items with no known origin |
| Device and configuration | Device or robot ID, firmware and controller versions, calibration session | Device register; calibration files | Mixed hardware presented as one rig |
| Ingest and storage | Who received the files, where, under what access | Ingest log with checksums | Gaps between capture and the supplier's copy |
| Processing | Transcoding, redaction, synchronization, retargeting, with tool versions and input/output checksums | Processing log | Unreproducible or silently altered files |
| Annotation | Vendor or team, guideline version, QA sample | Annotation register | Labels from unknown hands |
| Selection and aggregation | What was filtered out; which sources were mixed | Selection rules; source flags per item | Cherry-picked or blended data presented as uniform |
| Transfer to the buyer | Manifest, checksums, method, date | Signed manifest | Corruption or substitution in transit |
Pooled robot corpora show why per-contributor origin matters. Open X-Embodiment combined more than 1 million trajectories from 22 embodiments contributed by 21 institutions (Open X-Embodiment Collaboration, 2023). Each contributor's data may come with its own hardware, operators and terms.
Robot-specific provenance
Robot episodes carry provenance that video does not. The embodiment and controller version determine what an action value means, and a change in gripper, retargeting mapping or camera mount splits the data into populations that should not be pooled blindly. DROID replicated the same rig at 13 institutions and recorded camera calibration, depth and a language instruction with each episode (Khazatsky et al., 2024). Those per-episode fields are the kind of record that lets a buyer separate stations and sessions later. The field-level schema is in the robot trajectory dataset specification.
Illustrative item-level provenance record
# Illustrative only — synthetic identifiers; fields are examples to adapt
item_id: ep_000412
source:
recorder: supplier_org_A (synthetic)
site_id: site_017
capture_date: 2026-03-04
operator_id: operator_A12 # pseudonymous; key held by supplier
device_id: rig_07
firmware: fw_2.3.1
calibration_session: cal_0319
robot: # robot data only
embodiment: humanoid_X (synthetic)
controller_version: ctrl_5.1
teleop_interface: vr_controllers
permissions:
notice_version: notice_v3
consent_record_id: cons_0088
third_party_flags: [client_goods]
processing:
- {step: sync_cameras, tool: sync_tool 1.4, in_sha256: "…a1", out_sha256: "…b7"}
- {step: redact_screens, tool: mask_tool 0.9, in_sha256: "…b7", out_sha256: "…c3"}
annotation: {vendor: annotator_B, guideline: v2.1, qa_sample: qa_0045}
custody:
- {from: supplier_org_A, to: buyer, date: 2026-05-20, method: encrypted_transfer, manifest_sha256: "…d9"}
license: {item: sched_1_row_412, restrictions: [no_redistribution, internal_use]}
Pass/fail checks
| Check | Pass looks like | Fail looks like |
|---|---|---|
| Every item resolves to a capture event | Unresolved items are removed and listed | "Origin varies" or "various sources" |
| Rights chain closes | An agreement at each link from recorder to seller; the seller states what title it can warrant | A grant clause with no underlying agreements |
| Mixed sources are flagged per item | Each item marked as supplier-recorded, licensed-in, public, synthetic or scraped | One label for the whole lot |
| Public components traced | Original license text reviewed for each; see public dataset commercial license checks | Reliance on a repository tag |
| Hand-offs are checksummed | A manifest hash at each transfer; processing logs show input and output hashes | No checksums, or only at final delivery |
| Processing is reproducible | Tool names and versions recorded | "Cleaned and normalized" with no detail |
| Annotation is attributable | Vendor, guideline version and QA sample recorded | Labels from unnamed sources |
| Versions are controlled | Changes create a new version with a change log | Silent replacement of files |
| Deletions propagate | A record of what was removed and from which copies | Removal requests that stop at the original |
Documentation that carries provenance
A datasheet is a natural container. Gebru and colleagues propose that every dataset be accompanied by a datasheet documenting its motivation, composition, collection process and recommended uses (Gebru et al., 2018); the collection-process and composition sections are where provenance claims should live. See datasheets for robotics datasets and the overall evaluation checklist, where provenance is one gate of ten.
EU-facing buyers have a further reason to ask. The EU AI Act includes rules for general-purpose AI models and data governance requirements for high-risk systems, and it entered into force on 1 August 2024 (European Parliament and Council of the EU, 2024). Whether and how those rules apply to you depends on your system and role; see EU AI Act and GDPR considerations. This is not legal advice.
What provenance records cannot prove
- That the record is true. A log is an assertion. Checksums show a file has not changed since it was hashed, not that it shows what the log says. Independent sampling and audit rights test the claims; see retention, deletion and audit rights.
- That permission exists. Provenance shows who recorded and who passed the data along. Whether notice or consent was adequate for your use is a separate diligence question, covered in worker consent and identifiable people.
- That the data fits your task. Clean origin and poor coverage can coexist.
- That nothing is missing. Selection rules explain what was left out only if the supplier records them.
Red flags
- Provenance given as one paragraph for the entire dataset.
- Data "collected by third parties" with no agreements to show.
- No device, firmware or calibration records on robot data.
- Items re-encoded or edited without a processing log.
- Public data blended in with owned data and no per-item flag.
- A license statement that cannot be matched to a recorded source.
Questions to ask suppliers
- Can every item be traced to a capture event, a site and a date, and what happens to items that cannot?
- Who recorded the data, and which agreements carry their rights to you, and from you to us?
- What device, firmware, controller and calibration records exist for each session?
- Which processing steps touched the files, with which tools and versions, and are input and output checksums logged?
- Are public, licensed-in, synthetic and supplier-recorded items flagged individually?
- Who annotated the data, under which guideline version, and with what quality check?
- What manifest and checksums will accompany each transfer, and who signs them?
- How are corrections, removals and withdrawals recorded, and do they reach every copy?
Discuss your requirements
State the provenance records you need in the requirement you send through the buyers page, so suppliers can say what they can evidence before any license is drafted. SourceX looks for US businesses that hold the data you describe, checks the data and the supplier's licensing permissions, agrees pricing and allowed uses in a license, and coordinates delivery and payment. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match, and nothing is contracted until a supplier agrees. See also the procurement hub, the humanoid training data guide, the acceptance tests for deliveries and the catalog's training-data due diligence checklist.
Explore sourcing and licensing options with SourceX
Sources
- The Data Provenance Initiative: A Large Scale Audit of Dataset Licensing & Attribution in AI — audit of 1,800+ text datasets and license mislabeling.
- Datasheets for Datasets — datasheets as the container for composition and collection-process records.
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) — EU AI Act and its entry into force on 1 August 2024.
- Open X-Embodiment: Robotic Learning Datasets and RT-X Models — pooled corpus across 22 embodiments and 21 institutions.
- DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — per-episode calibration metadata and a rig replicated at 13 institutions.