How to Write Acceptance Criteria for Egocentric Stereo Human-Demonstration Data

Buying egocentric stereo human-demonstration data is not the same as buying generic video. For robot learning, imitation learning, and foundation-model teams, the dataset is only as useful as the acceptance criteria you put in the statement of work (SOW). Vague language—“high quality,” “synced stereo,” “good poses”—creates disputes after delivery. Precise, measurable criteria let both sides know what “accepted hours” means before a single episode is recorded.

This essay is a practical buyer-facing guide to writing those criteria for egocentric stereo human-demonstration data. It draws on a public sample you can inspect yourself: two episodes, 4,914 frames, 163.47 seconds total (EP001 PC wiring, 121.57 s; EP002 restocking, 41.90 s), published as LeRobot v3 on Hugging Face and available under CC BY-NC 4.0. The core claim behind the sample—and the one your SOW should protect—is simple: timestamps are recorded, not computed.

Why acceptance criteria matter for egocentric stereo demos

Egocentric stereo captures first-person, dual-eye colour video with geometric and temporal structure that monocular clips do not provide. Downstream pipelines depend on that structure: stereo depth and triangulation need a calibrated baseline and low reprojection error; multi-sensor fusion needs device-side timestamps and continuous IMU; policy training needs consistent frame timing and a documented schema such as LeRobot.

If your SOW only says “provide stereo RGB with IMU and poses,” you have not specified:

• Whether stereo is hardware-synced or software-aligned after the fact
• Whether timestamps come from the device clock or are interpolated offline
• What calibration products ship with each batch
• What format the dataset must pass on load
• How scene diversity is counted versus capture capacity

Those gaps turn into rework, rejected batches, and delayed training runs. The sections below translate each risk into paste-ready criteria.

1. Capture geometry and video envelope

Start with the optical and temporal envelope of each accepted episode.

Recommended SOW language

• Dual-eye colour RGB at 1920×1200 per eye, 30 fps, hardware-synced stereo.
• Frame interval must be stable: median, p99, and max frame interval identical at approximately 33.28 ms, with 0 frames out of specification.
• Per-frame timestamps must have 100% coverage, be device-side, and involve no interpolation.

Why this matters: a buyer who only asks for “30 fps stereo” can still receive soft-synced streams with drifting clocks. Hardware sync plus identical median/p99/max interval (~33.28 ms) and zero out-of-spec frames is a concrete pass/fail test. Requiring device-side timestamps with full coverage—and forbidding interpolation—locks in the core claim that timestamps are recorded, not computed.

2. IMU continuity and exposure-window sampling

Egocentric demos are head-worn. Head motion couples tightly to the visual stream, so IMU criteria belong in the same acceptance block as video.

Recommended SOW language

• 6-axis IMU measured at approximately 300.48 Hz.
• 10 IMU samples per exposure window.
• Continuous IMU stream: for a sample of the stated scale, expect on the order of 18,050 continuous samples with 0 gaps greater than 10 ms.
• Per-frame 6-DoF head pose delivered with the visual frames.

Why this matters: sparse or gapped IMU forces downstream teams to invent motion between samples. Specifying measured rate, samples per exposure window, and a hard gap threshold (no gaps >10 ms) makes continuity auditable. Pairing that with per-frame 6-DoF head pose keeps pose and pixels on the same timeline.

3. Stereo calibration products and geometric quality

Stereo without shipped calibration is incomplete. Acceptance should require both the parameter set and quantitative residual checks.

Recommended SOW language

• Ship intrinsic/extrinsic calibration products: K, KB4, R1/R2, P1/P2, Q, IMU↔camera extrinsics, and a calibration version identifier.
• Stereo baseline approximately 60.7 mm.
• Geometric quality gates (from a representative public sample scale): Sampson median 0.166 px, stereo reprojection 0.800 px, 15,811 inliers.

Why this matters: naming the matrices and extrinsics prevents “calibration available on request.” Versioning the calibration package lets you track drift across months of production. Residual metrics (Sampson, reprojection, inlier count) give QA a numeric reject threshold instead of a subjective “looks aligned.”

4. Dataset schema and license

Format friction kills evaluation velocity. Specify the loader and the license up front.

Recommended SOW language

• Deliver as LeRobot v3, loadable via LeRobotDataset().
• Dataset must pass Physical-Intelligence/pi-data-sharing checks.
• License: CC BY-NC 4.0 for the public sample reference; commercial delivery terms as agreed in the SOW.

Why this matters: “compatible with LeRobot” is ambiguous. Requiring LeRobot v3 and successful LeRobotDataset() load is a binary gate. Requiring a pass against Physical-Intelligence/pi-data-sharing further reduces custom adapter work. License clarity avoids downstream redistribution surprises when teams share internal eval forks.

5. Public sample as the reference artifact

Do not accept a vendor’s first batch without a published reference. A inspectable sample turns marketing claims into reproducible checks.

The public sample for this category is available at https://huggingface.co/datasets/tatezhou/ego-stereo-cn-v1 and on the product site https://10khoursdata.com. It contains:

SOW tip: Point your acceptance appendix at this sample (or an equivalent sealed fixture) and require each production lot to meet or beat the same numeric gates under the same measurement scripts.

Important narrative boundary for scene libraries: only EP001 and EP002 are our-device captures in the library story. Do not write SOW text that treats other library clips as our-device recordings.

6. Scene library vs. production capacity

Buyers often confuse a scene library (content diversity for scoping) with capture capacity (how many accepted hours can ship per month). Separate them in the SOW.

Scene library (scoping reference)
A scene library of 85 clips / 9 families can be cited for coverage planning:

• Factory assembly: 20
• Electronics assembly: 19
• Home: 17
• Food & agriculture: 10
• Garment & sewing: 8
• Packaging: 6
• Retail: 2
• Warehouse logistics: 2
• Kitchen: 1

Use this to discuss task mix and edge cases. Do not treat non-EP001/EP002 library clips as our-device stereo captures.

Production capacity
Specify delivery throughput separately: capacity of 10,000+ accepted hours/month. “Accepted” should mean hours that already passed your stereo, IMU, timestamp, calibration, and schema gates—not raw recorded time.

Paste-ready SOW checklist

Copy this block into your RFP or SOW appendix and edit thresholds only where your program needs stricter gates.

[ ] Dual-eye colour RGB, 1920×1200 per eye, 30 fps, hardware-synced stereo
[ ] Frame interval: median = p99 = max ≈ 33.28 ms; 0 frames out of spec
[ ] Per-frame timestamps: 100% coverage, device-side, no interpolation
      (core claim: timestamps recorded, not computed)
[ ] 6-axis IMU ~300.48 Hz; 10 samples per exposure window
[ ] IMU continuity: 0 gaps >10 ms (sample reference: 18,050 continuous samples)
[ ] Per-frame 6-DoF head pose aligned to visual frames
[ ] Stereo baseline ~60.7 mm
[ ] Geometric QA: Sampson median ≤ 0.166 px; stereo reprojection ≤ 0.800 px;
      inliers ≥ 15,811 at sample scale (or equivalent density on production lots)
[ ] Ship calibration: K, KB4, R1/R2, P1/P2, Q, IMU↔cam extrinsics, calibration version
[ ] Deliver LeRobot v3; must load with LeRobotDataset(); must pass
      Physical-Intelligence/pi-data-sharing
[ ] Public-sample reference: 2 episodes / 4,914 frames / 163.47 s
      (EP001 PC wiring 121.57 s; EP002 restocking 41.90 s)
[ ] License / commercial terms documented (sample: CC BY-NC 4.0)
[ ] Scene-mix planning may reference 85 clips / 9 families; only EP001/EP002
      are our-device captures in that narrative
[ ] Monthly capacity stated in accepted hours (reference: 10,000+ accepted hours/month)
[ ] Soft delivery gate: batch rejected if any hard checkbox above fails

How to use the checklist in procurement

1. Attach the public sample URL in the SOW so engineering can reproduce measurements before kickoff.
2. Define “accepted hour” as an hour that already cleared video, IMU, timestamp, stereo QA, calibration packaging, and schema checks.
3. Separate scoping from supply: use the 85-clip / 9-family library for content design; use 10,000+ accepted hours/month for volume commitments.
4. Keep EP001/EP002 as the our-device reference in any library narrative to avoid over-claiming device provenance.
5. Require calibration versioning so later lots remain comparable to the lot you validated in week one.

Teams that write criteria this way spend less time arguing about “sync quality” and more time training on data that actually loads, triangulates, and fuses.

Soft next step

If you are drafting an SOW now, start from the public sample—two episodes, 4,914 frames, 163.47 s of hardware-synced egocentric stereo with device-side timestamps, continuous IMU, shipped calibration, and LeRobot v3 packaging—then paste the checklist above into your appendix.

• Sample dataset: https://huggingface.co/datasets/tatezhou/ego-stereo-cn-v1
• Product site: https://10khoursdata.com
• Contact: tate@10khoursdata.com

Ask for a walkthrough of how the sample’s timing, IMU, and stereo residuals were measured, then mirror those same scripts as your acceptance tests. That is the shortest path from a vague “stereo demo data” line item to a shippable, auditable supply of egocentric human demonstrations.