Short answer
A robotics data RFP template is a requirements specification you send suppliers: the model use, target tasks and environments, modalities and capture parameters, coverage, labels, holdout rules, permissions, license terms, delivery format and acceptance tests. Writing it before reviewing supply stops you anchoring on whatever a supplier happens to hold, and its sections map onto the fields of the SourceX buyer request form.
Why write the specification first
Research teams tend to describe data by volume ("500 hours of kitchen video") and procurement teams by format ("MP4, 1080p"). Neither tells a supplier whether their asset fits. A useful specification says which part of the model the data will train or test, what must be visible or measured, how coverage is counted, what may never touch training, and what the license must allow. Each of those decisions also determines whether you need existing assets, commissioned collection or specialist robot data; the sourcing-route guide explains that choice.
The template below is a starting point. Delete the blocks that do not apply: a buyer of SOP text will not need capture parameters, and a buyer of teleoperated episodes will need the robot block in full.
Illustrative specification template
# Illustrative only — field names and values are examples to adapt, not a supplier offer
spec_id: REQ_2026_014
owner: data_program_lead_A (synthetic)
1_purpose:
model_use: visual pretraining | co-training | planner grounding | evaluation
stack_layer: human_demonstrations # robot_actions | procedures | objects | failures | evaluation
what_it_must_not_be_used_for: final policy evaluation (separate set, see 8_holdout)
2_tasks_and_environments:
task_families: [tote_unpacking, shelf_facing, carton_folding]
environment_types: [store_backroom, 3pl_pick_area]
conditions: [day_shift, night_shift, gloved_hands]
include_failures_and_recoveries: true
3_route_and_source:
acceptable_routes: [existing_assets, commissioned_collection]
supplier_geography: United States
4_modalities_and_capture:
video: {viewpoint: head_mounted + fixed_overhead, min_resolution: 1920x1080, frame_rate: constant 30 fps}
extra_sensors: [imu_head] # depth, wrist_camera, eye_gaze as needed
calibration: intrinsics per camera; extrinsics for multi-view rigs
audio: removed | kept (state why)
5_robot_block: # only for robot or handheld-device data
embodiment: humanoid_X (synthetic), two 7-DoF arms, 6-DoF hands
action_space: end-effector delta pose + hand joint targets
control_frequency_hz: 30
episode_format: RLDS | LeRobot | MCAP
sync: shared clock across cameras and proprioception; report max offset
6_coverage:
report_by: [site, operator, task_family, object_category, condition]
diversity_targets: ">= 8 sites; no site > 20% of hours; >= 40 operators"
7_labels:
required: [task_id, step_segments, outcome, hand_visibility_flag]
optional: [language_instruction_per_step, hand_object_contact]
precision: step boundaries within 0.5 s of reference on audit sample
8_holdout:
split_rule: by site (2 sites) and by operator; never mixed into training storage
9_permissions:
people_on_camera: workers notified and consented to AI training use and transfer
third_party_content: client-owned goods only with client approval
de_identification: faces blurred except where blur would hide hands or objects (state rule)
10_license:
permitted_uses: [training, internal_evaluation, fine_tuning]
derivatives: buyer owns annotations, pose estimates and model weights
exclusivity: non-exclusive | exclusive (state field of use)
term_and_deletion: 5 years; deletion certificate on termination
11_delivery:
format: MP4 (H.264) + JSON annotations; one manifest with checksums
transfer: encrypted drive or cloud bucket
12_acceptance_tests: see table below
How to fill the main sections
Purpose and stack layer. State the training or testing role first. "Visual pretraining" tolerates fixed viewpoints and loose labels; "co-training with robot data" needs calibrated cameras and 3D hands. A supplier who knows the role can say honestly whether an asset fits.
Tasks and environments. Name task families and the environments and conditions that matter, including failures. Coverage problems usually come from what was never asked for: night shifts, gloves, damaged items, recoveries.
Capture parameters. Fix viewpoint, resolution, frame rate and calibration where they matter, and say "any" where they do not. Ask for a constant frame rate and real timestamps if you will model actions or progress.
Robot block. For robot or handheld-device data, specify the embodiment, action space (joint or end-effector, absolute or delta), control frequency, episode format and synchronization. Formats differ in structure: RLDS stores each episode as steps holding observation, action, reward, discount and first/last/terminal flags (Ramos et al., 2021), while LeRobotDataset stores Parquet tables plus MP4 video per camera with an info file declaring features and fps (Hugging Face, n.d.). Per-episode metadata is worth naming explicitly; DROID records camera calibration, depth and a language instruction with each episode (Khazatsky et al., 2024). Detail is in the robot trajectory dataset specification.
Coverage. Ask for counts by site, operator, task family, object category and condition, not one total. Published corpora report coverage this way: Ego4D gives hours alongside 931 camera wearers, 74 locations and 9 countries (Grauman et al., 2021).
Labels. List required and optional labels with a measurable precision. For clip-level fields, align with the demonstration clip metadata schema.
Holdout. Write the held-out split rule into the specification and the license. The reasons and patterns are in training datasets vs evaluation datasets.
Permissions and license. Say what consent must cover, how third-party content is handled, which de-identification rule applies and where it must stop, and which uses, derivatives and retention terms you need.
How the template maps to the SourceX request form
The SourceX buyers page leads to a request form. Its fields cover the core of this template:
| Request form field | Template section | Note for robotics data |
|---|---|---|
| Dataset kind | 3_route_and_source | Choose "Physical-world collection" if you need new recordings |
| Modality | 4_modalities_and_capture | Video, sensor data or multimodal; list extra sensors in the description |
| Volume | 6_coverage | Give hours or episodes and the diversity targets behind them |
| Format | 11_delivery | Container, codec, annotation format, episode format |
| Geography | 2_tasks_and_environments | Where the work must be recorded; suppliers are US businesses |
| Language | 7_labels | Language of narration, instructions and documents |
| Timeframe | 2_tasks_and_environments | Recording dates, for packaging or process changes |
| Licensing requirements | 10_license | Permitted uses, derivatives, exclusivity, term |
| De-identification requirements | 9_permissions | The rule and where it must not obscure hands or objects |
| Evaluation criteria | 8_holdout and 12_acceptance_tests | Split rule and the tests a delivery must pass |
Task lists, the robot block and label precision do not have dedicated fields; summarize them in the request and keep the full specification ready for when SourceX follows up.
Parameters that depend on you
Nothing in the template has a universal value. Volume, diversity targets, frame rate, label precision and holdout size depend on your architecture, task, embodiment and intended use. Published numbers describe what one study used; treat them as context, not floors. Where you are unsure, run a small pilot and set the figures from what the pilot shows.
Acceptance tests to attach
| Test (illustrative) | Pass criterion the buyer might set | Evidence requested |
|---|---|---|
| Manifest integrity | Every file listed, checksums match | Manifest plus checksum report |
| Format conformance | All video at declared codec, resolution and constant frame rate | Automated probe output |
| Coverage | Counts by site, operator and task within ±10% of agreed targets | Coverage table from metadata |
| Label quality | Step-boundary error under 0.5 s on a 200-clip audit sample | Audit sheet with reviewer IDs |
| Hand visibility | Both hands visible in at least 70% of sampled frames, if required | Sampling script and results |
| Holdout integrity | No holdout site or operator ID appears in training files | ID cross-check report |
| Permissions | Consent or notice record for every operator ID | Consent register extract |
Full process and dispute handling are in acceptance testing for dataset deliveries. A completed specification also becomes the skeleton of a datasheet for the dataset at delivery.
Limitations of a specification
A specification cannot make an asset contain what it never recorded. Asking existing footage for robot actions, forces or calibrated multi-view geometry will produce either refusals or misleading offers. Over-specifying has a cost too: a strict viewpoint or sensor list can rule out every existing asset and force commissioned collection. Mark each requirement as must-have or nice-to-have so suppliers can tell you which they meet.
Questions to ask suppliers about your specification
- Which sections can the asset meet as it stands, and which would need preparation or new capture?
- What was the asset originally recorded or written for, and how does that limit viewpoint, coverage or labels?
- Can you report coverage by site, operator, task and condition from existing metadata?
- What consent or notice covered the people recorded, and does it extend to AI training and transfer?
- Which third parties (vendors, clients, equipment makers) have rights in any part of the asset?
- Can the holdout rule be applied with the identifiers you hold, such as site and operator IDs?
- Which acceptance tests can you run before delivery, and what evidence will you provide?
Discuss your requirements
A draft is enough to start. Send your requirement to SourceX with the must-haves marked. SourceX reviews it, looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and follows up about potential sources; a request does not guarantee a match. For the wider decision map, see the procurement hub and the humanoid training data guide.
Discuss your humanoid training-data requirements with SourceX
Sources
- RLDS: an Ecosystem to Generate, Share and Use Datasets in Reinforcement Learning — episode and step fields for robot data.
- LeRobot (Hugging Face repository) — LeRobotDataset storage layout and schema file.
- DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset — per-episode calibration, depth and language.
- Ego4D: Around the World in 3,000 Hours of Egocentric Video — coverage reported by wearers, locations and countries.