The contract was one signature away when the buyer’s counsel asked who owned models trained on the delivered episodes, and the call went quiet for a long moment. Nobody had put the question in the RFP. The clause that eventually surfaced in the vendor’s MSA granted reuse rights over “aggregated and derived data”, which is to say, over the buyer’s task distribution. That deal survived. The assumption that the important questions were already in the document did not.
The obvious RFP challenges are the ones buyers plan for: price, volume, timeline. Those rarely sink a data program. What sinks programs are the questions that never make it into the document, because the buyer did not know the failure mode existed until it arrived inside a delivery.
I run teleoperation rigs for a living, which means I also read the RFPs that reach us. The pattern is consistent: the sections buyers write carefully (pricing tables, volume schedules) cover the risks they have already survived, and the sections they skip (sync tolerances, consent chains, schema versioning) cover the risks they have not met yet. An RFP is a map of its author’s scar tissue.
This post covers the five challenges we most often see missing, why each one stays hidden until it costs money, and the specific question or clause that fixes it. All five fixes are built into the templates in the Robotics Data Buyer’s Playbook.
Key Takeaways
- The five hidden RFP challenges: undefined sync and calibration specs, licensing and reuse traps, throughput fiction, missing consent chains, and format drift between deliveries.
- Each has a one-question or one-clause fix that costs nothing to include and is expensive to omit.
- The common thread: RFPs fail on what they do not ask. Vendors answer the questions in the document, not the ones you meant.
Challenge 1: The Sync Spec That Nobody Defines
A sync spec is the maximum allowed time offset between data streams (cameras, joint states, actions) in a delivered episode, and most RFPs never state one. The omission stays hidden because unsynced data plays back fine to a human eye. It surfaces months later as an imitation learning policy that plateaus below expectations, because the state-action pairs it learned from were misaligned by tens of milliseconds.
The fix: state a tolerance and demand measurement. Our recommended RFP language: “Maximum time-sync error across all streams shall be 10 ms; vendor shall describe how sync is measured, how often it is rechecked during production, and how violations are flagged in delivered metadata.” A vendor who has never measured their sync error will reveal it in one sentence, which is exactly what you paid the question to find out. The same applies to calibration: require per-rig intrinsics and extrinsics files with every delivery and a stated recalibration cadence.
Challenge 2: The Licensing Trap in the MSA
The licensing trap is contract language granting the vendor rights to reuse your delivered episodes, your task definitions, or data derived from them for other customers or their own models. It hides in the master service agreement rather than the RFP response, usually as one clause about “aggregated or derived data.” Your task list and environment setups are competitive information; a reuse clause quietly donates them to whoever buys from the same vendor next.
The fix: ask it in the RFP, before the MSA exists: “Who owns delivered data and models trained on it? Do you retain any right to reuse our episodes, task definitions, or derivatives for any other purpose?” Then score the answer on your vendor scorecard and treat broad reuse rights as disqualifying. Negotiating this after signature means bargaining from a position you already gave away.
Challenge 3: Throughput Fiction
Throughput fiction is a capacity claim (“we can scale to any volume”) unsupported by the arithmetic that produces real hours: rig count times shifts times operators times usable-hour yield. It stays hidden because it fails late, four or six weeks into a ramp, when a vendor sized for 40 hours a week is contractually committed to 150 and quality starts absorbing the difference.
The fix: make the multiplication mandatory. RFP question: “For our program spec, state the number of rigs and operators you would dedicate, the sustained hours per week that supports, and your actual delivered volume for your largest program in the last six months.” Any credible operation knows these numbers instantly. On teleoperation specifically, sustained real-world throughput per bimanual rig runs far below the naive shift math once you account for resets, calibration checks, operator breaks, and QA rejections; in our own operations, a single ALOHA-class rig sustains roughly 20 to 30 usable hours per week, not the 60 to 80 the shift calendar implies.
Challenge 4: The Missing Consent Chain
A consent chain is the documented link between every delivered episode and the signed consent of every human in it: teleoperators, egocentric camera wearers, and bystanders captured in frame. RFPs skip it because it feels like legal boilerplate. It becomes real the day your model ships in a product and your counsel asks whether the training data included identifiable people who never agreed to it, a question with GDPR and biometric-law consequences you cannot retroactively fix.
The fix: two RFP questions. “Describe what operators and captured participants sign, and how consent records map to delivered episodes.” And: “What is your process for faces and bystanders in egocentric capture: avoidance, blurring, or documented consent?” Public egocentric corpora set the reference point here; Ego4D and EgoExo4D shipped with documented consent and privacy processes (arxiv.org/abs/2110.07058; arxiv.org/abs/2311.18259), and a commercial vendor should clear the bar academic datasets already cleared.
Challenge 5: Format Drift Between Deliveries
Format drift is schema change between deliveries from the same vendor: a renamed key in an HDF5 file, a reordered camera list, a new compression setting, an action space silently rescaled. Single-delivery evaluation cannot catch it by definition, which is why it hides through every pilot and surfaces as a broken training pipeline at 2 a.m. before a deadline. The ecosystem’s convergence on versioned formats (LeRobot’s dataset versions, RLDS episode specs, MCAP channel schemas; github.com/huggingface/lerobot, github.com/google-research/rlds, github.com/foxglove/mcap) exists precisely because ad hoc schemas drift.
The fix: contract the schema, not just the format. Require a written schema document as an RFP deliverable, version it as a contract appendix, and add the clause: “Schema changes require written notice one delivery cycle in advance; unannounced schema changes constitute delivery failure.” Then validate mechanically: a loader script in CI that runs on every delivery costs a day to write and catches drift while it is still the vendor’s problem.
Why These Five Stay Hidden
The common mechanism behind all five challenges is delayed feedback: each failure surfaces weeks or months after the decision that caused it, in a different team’s backlog. Sync defects appear as ML debugging tickets. Licensing traps appear in legal review of a partnership, a year later. Throughput fiction appears as a slipped training milestone that gets blamed on the schedule, not the contract. Because the pain lands far from the RFP, the RFP never learns. The fix is not vigilance, which does not scale; it is putting the five questions into a template so they get asked by default, on every deal, including the ones that feel too small or too friendly to need them. Friendly deals with partner labs are where we see the format-drift and consent gaps most often, precisely because nobody wanted to send paperwork to a friend.
The Five Challenges at a Glance
| Hidden challenge | Why it stays hidden | Cost when it surfaces | The one-line fix |
|---|---|---|---|
| Undefined sync/calibration spec | Bad sync looks fine in playback | Weeks of training debugging | Require ≤10 ms tolerance, measured and rechecked |
| Licensing reuse trap | Lives in the MSA, not the RFP | Task distribution leaks to competitors | Ask ownership and reuse questions in the RFP; disqualify broad reuse |
| Throughput fiction | Fails weeks into ramp, not at signing | Missed training milestones | Demand rigs × shifts × yield arithmetic plus 6-month delivery history |
| Missing consent chain | Feels like boilerplate until launch | Legal exposure you cannot backfill | Require consent-to-episode mapping and a bystander policy |
| Format drift | Invisible in any single delivery | Broken pipelines, silent data corruption | Version the schema in the contract; validate every delivery in CI |
Frequently Asked Questions
What is the most expensive hidden challenge in robotics data RFPs?
Format drift and undefined sync specs compete for the title. Sync problems corrupt what the model learns; format drift breaks the pipeline that feeds it. Both are cheap to prevent with one RFP requirement and expensive to diagnose after delivery.
How do I verify a vendor’s throughput claim?
Ask for the arithmetic: dedicated rigs, operators, shifts, and usable-hour yield, plus actual delivered volume on their largest recent program. As a sanity check, a bimanual teleop rig sustains roughly 20 to 30 usable hours per week in real operations.
What licensing terms should disqualify a data vendor?
Any retained right to reuse your episodes, task definitions, or derivatives for other customers or their own models. Ownership of delivered data and models trained on it should sit with the buyer, stated in the RFP response before the MSA stage.
Do consent requirements really apply to teleoperation data?
Yes. Teleoperators are identifiable humans generating biometric-adjacent data, and egocentric capture routinely includes bystanders. Require consent records that map to delivered episodes, matching the standard public datasets like Ego4D already meet.