Chapter 10: Production Data — Deployment as an Improvement Loop

Overview

A production-data loop is more than a large training set. It begins after deployment, when attempts, failures, recoveries, quality outcomes, operator interventions, and retraining approvals accumulate as one traceable unit. Vendors such as Covariant, Dexterity, and Chef Robotics can turn operations in different task distributions into an asset, but their public materials remain first-party evidence of product direction ^[1], ^[2], ^[3]. Improvement in a customer's process still needs to be established by customer-controlled replay.

Manufacturers should separate "the vendor has a lot of data" from "our process gets better." From QT-Opt ^[4] through RoboNet, MT-Opt, and RT-1 ^[5], ^[24], ^[7], large robot datasets have pushed manipulation learning forward. Factory improvement, however, is driven by intervention reasons, reject codes, cycle-time tails, sanitation holds, and recovery paths as much as by model loss. The thesis of this chapter is that deployment is not the end of data collection. It is an experiment that becomes a learning asset only when logging and update authority are deliberately designed.

After reading this chapter... - Distinguish pre-deployment datasets from post-deployment production telemetry. - Design a schema that connects robot attempts, human interventions, recovery, and delayed quality outcomes. - Calculate intervention value from total observation, handoff, reset, labeling, and revalidation effort rather than corrected segments alone. - Define the failure logs, QA traces, replay sets, update approvals, and rollback rights customers should retain. - Separate vendor announcements, paper experiments, and customer-site validation as distinct evidence layers.

The Four Layers of an Operating Loop

Anatomy of Production Telemetry

The easiest mistake is to say that data accumulates automatically. In practice, camera frames, action commands, robot status, PLC events, operator notes, and quality results often live in different systems. Unless these records share an attempt ID, the plant may have many logs without having learnable operating data. The ID should resolve the cell, robot, end effector, tool, product lot, recipe, and software version, as well as any correction applied to misaligned clocks.

A production flywheel requires customer-visible telemetry that connects robot attempts, interventions, failures, downstream quality, and model updates. The cited systems support only bounded components of that synthesis ^[26], ^[27], ^[4]. This is not a claim that any cited system is factory-ready. QT-Opt establishes the value of off-policy learning at real-grasp scale, RoboCat reinserts self-generated data within a bounded robot/task mixture, and runtime-monitoring work forecasts intervention-worthy failure on a small manipulation suite. Manufacturing generalization still requires the cell's sensors, controller, reset procedure, and evaluation denominator to be fixed again.

QT-Opt is an early example of how many real grasp attempts and off-policy learning can create a scale advantage ^[4]. RoboNet and BridgeData widened the idea toward multi-robot and cross-domain data ^[5], ^[6]. RT-1 and RT-X pulled the lineage toward language-conditioned policies and cross-embodiment datasets ^[7], ^[8]. This research lineage matters, but it does not solve every factory telemetry problem.

In production, some of the most important labels appear after the robot action. A pick may succeed and still create a downstream scratch. A pallet may look stable and fail later in transport. A food portion may look acceptable and fail weight or sanitation checks. Production loops therefore need delayed-label design: robot-side events must eventually connect to quality systems.

Task success can diverge from manufacturing acceptance when defects, rework, cycle-time tails, or delayed inspection outcomes are omitted. Runtime-monitoring evidence supports only a bounded part of this operational synthesis ^[26]. Interactive improvement and offline iteration studies expose components of a learning loop, but their experimental success labels do not automatically include a customer's defect, warranty, or sanitation criteria. Immediate completion should therefore be recorded as motion_complete, downstream disposition as process_accept, and later evidence as field_accept, with late defects linked back to the originating attempt.

Delayed labels also introduce attribution error. When a part crosses several cells, the final defect may not identify the operation that caused it. Marking every upstream episode as failure can teach the policy to avoid normal behavior; changing none of them discards the quality signal. Process knowledge should narrow plausible causes, while uncertain labels retain confidence and reviewer identity. Production-data quality depends less on instantaneous labeling than on preserving causality and uncertainty honestly.

Fleet Learning and the Customer-Site Gap

A vendor loop turns data from many customers into global model improvement. That can be powerful. RoboNet studied heterogeneous embodiments with roughly 15 million frames from seven robot platforms, while MT-Opt shared more than 800,000 reported episodes across a graph of 12 skills in its setup ^[5], ^[24]. These results support broader experience coverage, but their data mixtures and task graphs do not imply transfer to an arbitrary manufacturing process.

Figure 10.1. MT-Opt Figure 2 defines success detectors from desired-outcome examples, collects episodes across robots, and expands and rebalances them across tasks for iterative policy training. Detector-derived binary success is a paper-task label, not customer QA, negative replay, or independently audited production telemetry. Source: Kalashnikov et al. (2021), arXiv:2104.08212, Figure 2, p. 3.

Fleet scale can improve learning coverage, but private failure logs prevent independent assessment of the production distribution. MT-Opt and RoboNet support this claim only within their reported data mixtures and task settings ^[24], ^[5]. Selection bias and undisclosed discarded runs further limit external assessment. Autonomous reset–rollout–verify loops have the same boundary: without robot idle time, verification infrastructure, and discarded failures, trajectory counts cannot establish economics or safety. A customer buying a global prior must still keep a local holdout and negative replay set.

The customer loop has a different target. The customer needs local scrap, downtime, manual assist, and QA rejects to fall. If a global vendor update improves average performance but worsens a specific SKU, the customer must be able to reproduce the failure and request rollback. The stronger the vendor loop, the more explicit the customer's rights need to be.

This makes data ownership more concrete. A customer may refuse to release all raw video, while the vendor may need some data for model improvement. A practical compromise separates raw video, de-identified video, derived features, aggregate failure codes, replay results, and model-update metrics. Sharing can then be negotiated by layer instead of being treated as all-or-nothing.

Intervention Is Not a Free Label

DAgger formalized the idea of querying an expert on states visited by the learner to reduce the distribution shift of behavior cloning ^[23]. ThriftyDAgger later connected novelty and risk estimates to budget-aware handoff, while model-based runtime monitoring used predicted future failure to request human supervision selectively ^[25], ^[26]. HIL-SERL combined demonstrations, a learned reward, off-policy reinforcement learning, and online intervention on a small suite of real contact tasks ^[28]. Together they show powerful ways to turn intervention into data, but all depend on competent supervision, resets, learned reward or failure models, and substantial system engineering.

Figure 10.2. HIL-SERL Figure 3 builds a binary reward classifier from teleoperated success and failure samples, then accumulates 20–30 demonstrations, online policy transitions, and human interventions in two replay buffers. The success-rate, cycle-time, and intervention-rate lines at right are schematic expected trends rather than measured time series, so they do not quantify factory labor or quality improvement. Source: Luo et al. (2025), arXiv:2410.21845, Figure 3, p. 8.

Intervention economics must count operator observation, takeover, reset, labeling, and revalidation time rather than corrected segments alone. The cited intervention and monitoring studies support these components only in their reported settings ^[25], ^[28], ^[26]. Success and human-effort results in those studies are valid only for their robots, tasks, baselines, and evaluation denominators. Translating them into lower total factory cost requires adding supervisor standby, production interruption, discarded parts, and recertification.

Intervention records should distinguish preventive, where the person takes over before a collision or defect; corrective, where an ongoing action is redirected; and recovery, where the cell is restored after failure. Merging all three into successful episodes overstates autonomy. Discarding them all as failure loses rare human recovery strategies. The dataset should retain state and action around the transition, while operating metrics separate autonomous success, assisted success, and safe termination.

Negative results are valuable here. Intervention frequency may fall while undetected quality escapes rise. A conservative risk model may cut throughput, and alarm fatigue may delay takeover. An intervention-policy update should therefore report missed interventions, false alarms, takeover latency, operator workload, and later QA rejects alongside intervention rate. This treats people as safety participants rather than inexpensive data collectors.

Pre-Deployment Data Versus Post-Deployment Data

Pretraining data creates the starting point. Datasets such as Open X-Embodiment and DROID provide priors across robots and environments ^[8], ^[9]. The production flywheel is decided later. A growing pile of failure clips is not enough; each failure has to be tied to why it happened, who intervened, what the inspection system decided, and whether the recovery path worked.

The minimum unit is therefore an attempt, not an image-action pair. An attempt should include SKU or recipe, fixture state, robot mode, controller fallback, operator correction, QA result, and rework status. If that unit survives, a manufacturer can tell whether a model update moved the process KPI. If it does not, the vendor may still improve the global model while the customer loses the explanation for its own throughput and scrap changes.

Pre-deployment data answers one question: what can the model do before it enters the plant? Post-deployment data answers another: what keeps going wrong in this process? The first is a model prior; the second is an operating correction signal. They may live in the same data lake, but they should not be treated the same in release decisions.

Negative data is especially valuable after deployment. Line stops, emergency stops, operator interventions, and QA rejects are not noise to be cleaned away. They are anchors for the next release. The maturity of a production flywheel is measured less by the number of success clips and more by how quickly rare failures become reproducible and fixable.

Covariant: Turning Warehouse Distributions Into Model Assets

Covariant's RFM-1 claim shows why warehouse manipulation is flywheel-friendly ^[1]. Logistics cells face broad SKU and packaging variation, but success or failure is often judged quickly and many pick/sort episodes repeat. That aligns with the lineage from real-robot grasping scale ^[4] to multi-robot and cross-domain data ^[5], ^[6].

Warehouse success does not automatically transfer to all manufacturing. Factory cells often have tighter part tolerances, surface treatments, fixture alignment, and downstream inspection. Bringing a Covariant-style flywheel into manufacturing requires a failure taxonomy before a larger object taxonomy. "Failed to pick" is not enough; slip, occlusion, crushed packaging, wrong bin, excessive force, and downstream reject need separate labels.

The Covariant pattern is strongest where long-tail object variation dominates. Packaging, lighting, bin clutter, and partial occlusion are exactly the kinds of variation that benefit from multiple customer sites. A manufacturer should not pick the highest-SKU cell blindly, though. It should pick a cell where failures are labeled quickly. If labels are late or ambiguous, the flywheel turns slowly.

Precision assembly and cosmetic-sensitive handling require additional caution. Small scratches, burrs, insertion forces, and part deformation are not the same labels as warehouse pick success. Covariant-style vendors may still be relevant, but the manufacturer should require force or tactile instrumentation and downstream QA integration when the domain leaves the vendor's natural evidence base.

Dexterity: Workcell Abstractions and Recovery Flow

Dexterity presents more than a model; it presents an industrial workcell platform ^[2]. That is manufacturing-friendly because the real system includes arms, end-effectors, fixtures, conveyors, PLCs, safety scanners, and operator stations. The policy model is only one part of the workcell.

The key evaluation item is recovery. A polished video of one success matters less than the state the cell returns to after failure and the data left behind. In truck loading, mixed-case palletizing, and tote handling, a retry can create a new collision or product damage risk. Customers should not leave recovery policy and safety envelope entirely inside the vendor black box; at minimum they need replayable logs and update approval rights.

The workcell approach reduces integration burden. Manufacturers often worry less about robot learning itself than about line balancing, safety certification, MES integration, and maintenance training. A platform that packages model and cell architecture together can accelerate early deployment. The trade-off is that the customer may have less ability to repair problems outside the vendor's abstraction.

The central question is who can modify recovery. If operator handoffs rise, the cause might be policy weakness, fixture design, upstream material variation, or line layout. If the recovery state remains hidden inside vendor logic, the customer cannot separate these causes. If recovery state is exportable, the customer can decide whether to invest in layout change, fixture change, policy update, or operator workflow.

Chef Robotics: The Hard Data of Food Manufacturing

Chef Robotics targets food manufacturing, a domain that sits between factory and service robotics ^[3]. Its data is unusual. Materials are wet, slippery, deformable, and recipe-dependent; portioning depends on appearance, weight, hygiene, and changeover rules. The same scooping motion can become a different distribution when temperature, viscosity, container depth, allergen changeover, or cleaning state changes.

Food flywheels therefore depend more on QA label design than vision-only success rate. Portion weight, spill, smear, missing ingredient, contamination hold, and operator correction must be attached to the episode. If only the vendor owns those labels, the manufacturer loses the explanation for recipe and process improvement. If the customer owns them, the robotic cell also becomes a quality-improvement sensor.

Food is an extreme contact-rich case. Materials flow, clump, stick, and change over time. Vision can see the surface but not viscosity or stickiness directly. Weight sensing, force-torque, utensil state, container geometry, and sanitation schedule need to connect to policy data. A ChefOS-style platform should be evaluated by how well it binds those operating labels.

Food also depends on worker acceptance. Human operators judge taste, appearance, hygiene, and speed together, and they often preserve quality through small adjustments. A robot that replaces that work should treat operator correction as teaching signal, not merely failure. "Do not scoop that edge" or "scrape this ingredient more slowly" can become recipe-specific policy data if it is logged.

Non-US Scale Comparison: AgiBot World

AgiBot World is a different kind of scale reference ^[10]. A large manipulation platform is valuable because it compares many embodiments and tasks at once. But public dataset scale is not the same as production telemetry. Customer-site exceptions, line stops, operator overrides, and warranty claims usually do not enter public robot datasets.

That distinction separates "many trajectories" from a closed flywheel. Trajectory count helps pretraining. A production flywheel closes only when it records which trajectory blocked or approved the next release.

AgiBot-style scale still gives manufacturers a useful comparison. When a vendor says it has a large dataset, ask whether the source is public dataset scale, proprietary production telemetry, or simulation rollout. Each has a different value. Public datasets are comparable, proprietary telemetry is closer to operations, and simulation can generate variation quickly.

None of the three replaces QA-linked factory replay. Simulation has contact-fidelity limits. Public datasets rarely contain customer IP or line stops. Vendor telemetry may not be visible at customer-specific granularity. Scale comparison is not meant to dismiss vendor claims; it is meant to identify which gaps remain.

Figure 10.3. AgiBot World Colosseo Figure 1 combines the authors' reported 1M+ trajectories, 100+ robots, human-review loop, and GO-1 comparison in one teaser. The corpus counts and bar values come from the authors' data and evaluation; they are not independent production evidence containing customer line stops, quality decisions, or update replay. Source: AgiBot-World-Contributors et al., 2025, arXiv:2503.06669, Figure 1, p. 1.

Data Rights and Operating KPIs

The most important line in a production-vendor contract may be the data-rights clause, not the model performance table. Customers should be able to aggregate, analyze, and export the episodes, QA labels, stop reasons, operator notes, and update results generated by their own cells. Even if the vendor uses the data to improve a global model, the customer must still be able to explain its process improvement.

Vendor deployment claims remain first-party until the customer can replay failures, inspect update effects, export data, and exercise rollback. Company materials document only their reported deployments and workflows ^[29], ^[2], ^[3]. For example, the 854-placement sample and reported success/time statistics in Dexterity's Instinct introduction define what that company observed in its trailer-loading fleet. Without an external audit, a disclosed sampling frame, or a controlled comparator, they should not be read as universal readiness for other processes.

Operating KPIs are also different from model KPIs. A higher success rate can still be a factory failure if cycle-time tails grow, rework is pushed downstream, or operator intervention increases. A production flywheel dashboard should track pick success, recovery success, manual-assist time, scrap and rework, quality rejects, safety stops, and update rollbacks together.

Data rights do not necessarily mean copying every raw video. A plant may restrict video export because it contains worker identity or customer-product information while still retaining attempt indexes, event codes, synchronized trajectories, quality labels, model/controller versions, and replay decisions. Raw video without event schema and version information is also insufficient for reproducing regressions. Contracts should divide raw, masked, derived, and aggregate layers, then specify retention, permitted use, deletion, and vendor-exit procedures for each.

One Release Gate for Safety, Quality, and Replay

A production update should not ship merely because the training job finished. The first stage is a frozen replay set containing routine cases as well as past line stops, manual interventions, quality escapes, sensor drift, tool wear, and supplier-lot changes. The second is shadow evaluation: the new policy receives the same observations but has no actuator authority, allowing command divergence and approaches to safety boundaries to be inspected. The third is a canary deployment limited by cell, shift, and product family. Only then should quality and safety owners review process KPIs and event logs together and decide whether to promote or roll back.

Replay is not simply watching video again. Policy inputs, internal state, action candidates, low-level controller, safety interlocks, and PLC transitions must be reconstructed with compatible versions. A stochastic policy that cannot be made fully deterministic should be tested across seeds, not only with one fixed seed. Contact work also needs a distinction between simulator replay and physical-fixture replay. Simulation can screen many variations quickly, but it cannot finally approve real friction, compliance, and sensor drift ^[11].

A quality gate protects a lower bound for each risk class rather than approving an average. Fewer safety stops may mean better control, but it may also mean weaker hazard detection. False stops, missed hazards, product damage, slowdown around human entry, and retry count during recovery should be read together. Quality review likewise needs defect classes—cosmetic, dimensional, assembly, contamination—and confidence by product lot. A rare failure with too little evidence should remain "unresolved; block promotion," not be converted into a statistical win.

Change units should stay separable. Updating the perception encoder, action policy, low-level controller, grasp planner, safety threshold, and tool calibration at once destroys causal attribution. Except for urgent security or safety patches, changes should be small and linked to dataset lineage and approver identity. Rollback must restore not only a model file but compatible preprocessing, control parameters, tool calibration, and PLC state machine.

PoC Design Walkthrough: Comparing Three Vendor Types

Assume a manufacturer wants to automate a cell that removes high-mix packaged parts from totes and sends them to inspection. A Covariant-style vendor may be attractive because SKU diversity and warehouse picking are close to its evidence base. A Dexterity-style vendor may approach the same cell as a complete workcell with conveyors, safety, robot motion, and human handoff. A Chef Robotics-style vendor may not be a direct candidate, but its food-manufacturing lens is useful if the packaging is deformable, sticky, or tightly tied to QA labels.

The first week should freeze logging, not robots. SKU, lot, bin pose, gripper mode, robot attempt, operator intervention, and inspection result should share one key. The team should apply part of the same schema to current human work. If the plant does not understand how people recover from failure, it cannot judge whether robot recovery is good.

The second week should give each vendor the same replay pack: perhaps 30 successes, 30 failures, and 10 rare failures. Ask Covariant-style vendors about long-tail object variation and reject linkage. Ask Dexterity-style vendors about recovery state and PLC handoff. Ask every vendor for update-before and update-after replay results and customer data export boundaries.

The third week should split KPI dashboards. Robot success, cell throughput, manual assist, downstream reject, safety stop, and update rollback should be viewed separately. One average success rate hides too much. If throughput improves while downstream rejects rise, the flywheel is turning in the wrong direction.

At the end of the PoC, record more than the winning vendor. Record which failure codes remain unexplained, which fields were not exportable, and which KPI improved at the expense of another KPI. That record is often more valuable for the next negotiation than the first model result.

Another exit criterion is internal independence. If the system only works while the vendor team is on site, the flywheel is not yet a customer asset. Field engineers should read replay results, quality teams should interpret defect-code shifts, and maintenance should connect sensor drift to the data schema before the next cell is added.

Finally, include finance. A higher robot success rate does not prove ROI if manual assist remains high, rework moves downstream, or sanitation time increases. The economics of a production flywheel appear when labor substitution, fewer quality escapes, lower downtime, and lower engineering support cost move together.

The team should also decide which data becomes shared learning and which remains plant-private. A vendor may need failure examples to improve a global model, but the plant may need to protect customer product information or worker identity. The practical answer is not to block all sharing; it is to define export layers. Raw video, masked video, trajectories, event codes, and aggregate metrics can have different rules.

Production data also needs retention policy. Some logs should be kept for model improvement, some for quality audit, and some only long enough to diagnose a release. If retention is undefined, the data lake becomes a liability. If retention is too short, the plant cannot investigate slow regressions caused by supplier changes, tooling wear, or model updates.

The PoC should establish an exception-review cadence before full deployment. A weekly review that samples only successful cycles teaches little. The useful meeting begins with unresolved exceptions: repeated miss reasons, manual-assist clusters, downstream quality escapes, safety stops, and cases where the vendor update improved one KPI while hurting another. Those exceptions should become the next replay pack.

Support cost is another data signal. If a vendor can only resolve failures by sending senior engineers on site, the system may still be valuable, but the manufacturer should treat that support pattern as part of the flywheel. Which failures can local engineers diagnose? Which require vendor-only tools? Which disappear after a model update but remain unexplained? Operational independence should improve with every cell.

Simulation and synthetic data belong in the same review, but they should not be allowed to erase production evidence. Simulation can widen variation and screen rare events, while public datasets such as DROID or AgiBot World help compare manipulation coverage ^[11]. The acceptance gate still has to be customer replay: supplier packaging changes, worn fixtures, sanitation state, and operator handoff often differ from simulated or public conditions.

Finally, plan vendor exit even when the relationship is healthy. A production flywheel is durable only if episode exports, defect-code mappings, update records, and replay sets can survive a vendor change. Exit planning is not distrust. It is how the manufacturer keeps a process asset while vendors, model families, and robot hardware continue to change.

Manufacturing Cell Checkpoint

The table asks the same question differently for each category. Warehouse flywheels revolve around object distribution and exception mining. Workcell flywheels revolve around recovery and line integration. Food flywheels revolve around material variability and QA labels. The phrase "production data" hides different required fields and rights in each domain.

Open Questions and Failure Modes

First, a manufacturer may confuse global vendor model improvement with local process improvement. Second, binary success/failure labels without failure reasons accumulate data while erasing process cause. Third, automatic updates can hide the difference between short-term performance gains and long-term quality regressions. Fourth, in food and manufacturing domains with hygiene, quality, and safety constraints, camera-only logs often discover contact failures too late.

The open question is that production telemetry is mostly company-private. Public papers explain the direction of robot learning, but override, rework, downtime, and safety-stop distributions are rarely published. Manufacturers should not stop at skepticism. They should use contracts, PoC design, and internal instrumentation to own their own telemetry.

Figure 10.4. Production improvement gate from deployment to acceptance or rollback. This diagram is not a performance claim; it summarizes the operational chain that carries capability evidence through replay and quality decisions into release authority. Source: author-created SVG.

What to Learn Next

The next chapter turns to the hand and sensor choices that make these flywheels possible. The same operating log has very different value depending on whether the cell uses suction, two fingers, custom tooling, or a five-finger hand.

References

1. Covariant (2024). RFM-1: Robotics Foundation Model. Company technical post.
2. Dexterity (2025). Dexterity Foresight: AI Platform for Industrial Robot Workcells. Company product page.
3. Chef Robotics (2025). ChefOS: AI Robotics Platform for Food Manufacturing. Company product page.
4. Kalashnikov, Dmitry (2018). QT-Opt: Scalable Deep Reinforcement Learning for Vision-Based Robotic Manipulation. arXiv.
5. Dasari, Sudeep (2019). RoboNet: Large-Scale Multi-Robot Learning. arXiv.
6. Ebert, Frederik (2021). Bridge Data: Boosting Generalization of Robotic Skills with Cross-Domain Datasets. arXiv.
7. Brohan, Anthony (2022). RT-1: Robotics Transformer for Real-World Control at Scale. arXiv.
8. O'Neill, Abby (2023). Open X-Embodiment: Robotic Learning Datasets and RT-X Models. arXiv.
9. Khazatsky, Alexander (2024). DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset. arXiv.
10. Team AgiBot-World (2025). AgiBot World Colosseo: A Large-scale Manipulation Platform for Scalable and Intelligent Embodied Systems. arXiv.
11. Li, Xingyu (2024). Evaluating Real-World Robot Manipulation Policies in Simulation. arXiv.
12. Toyota Research Institute (2024). Large Behavior Models for Robot Manipulation. Company technical post.
13. Physical Intelligence (2024). pi0: A Generalist Robot Policy. Company research post.
14. Black, Kevin (2024). pi0: A Vision-Language-Action Flow Model for General Robot Control. arXiv.
15. Octo Model Team (2024). Octo: An Open-Source Generalist Robot Policy. arXiv.
16. Zhao, Tony Z. (2023). Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware. arXiv.
17. Chi, Cheng (2023). Diffusion Policy: Visuomotor Policy Learning via Action Diffusion. arXiv.
18. Mandlekar, Ajay (2021). What Matters in Learning from Offline Human Demonstrations for Robot Manipulation. arXiv.
19. Yu, Jiawen (2025). ForceVLA: Enhancing VLA Models with a Force-aware MoE for Contact-rich Manipulation. arXiv.
20. Ha, Huy (2024). Universal Manipulation Interface: In-The-Wild Robot Teaching Without In-The-Wild Robots. arXiv.
21. Choi, Hojung (2026). In-the-Wild Compliant Manipulation with UMI-FT. arXiv.
22. Figure AI (2025). Helix: A Vision-Language-Action Model for Generalist Humanoid Control. Company announcement.
23. Ross, Stéphane, Gordon, Geoffrey J., and Bagnell, J. Andrew (2011). A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning. AISTATS.
24. Kalashnikov, Dmitry et al. (2021). MT-Opt: Continuous Multi-Task Robotic Reinforcement Learning at Scale. arXiv.
25. Hoque, Ryan et al. (2021). ThriftyDAgger: Budget-Aware Novelty and Risk Gating for Interactive Imitation Learning. arXiv.
26. Liu, Huihan et al. (2023). Model-Based Runtime Monitoring with Interactive Imitation Learning. arXiv.
27. Bousmalis, Konstantinos et al. (2023). RoboCat: A Self-Improving Generalist Agent for Robotic Manipulation. arXiv.
28. Luo, Jianlan et al. (2025). Precise and Dexterous Robotic Manipulation via Human-in-the-Loop Reinforcement Learning. Science Robotics.
29. Dexterity (2026). Introducing Instinct. Company engineering report.
30. Aravind Rajeswaran et al. (2018). Learning Complex Dexterous Manipulation with Deep Reinforcement Learning and Demonstrations. Robotics: Science and Systems.
31. Tongzhou Mu et al. (2021). ManiSkill: Generalizable Manipulation Skill Benchmark with Large-Scale Demonstrations. NeurIPS Datasets and Benchmarks.
32. Suraj Nair et al. (2022). R3M: A Universal Visual Representation for Robot Manipulation. CoRL.
33. Jiayuan Gu et al. (2023). ManiSkill2: A Unified Benchmark for Generalizable Manipulation Skills. ICLR 2023.
34. Yongchao Chen et al. (2025). Code-as-Symbolic-Planner: Foundation Model-Based Robot Planning via Symbolic Code Generation. IROS.
35. Zhongxuan Li et al. (2026). UniBiDex: A Unified Teleoperation Framework for Robotic Bimanual Dexterous Manipulation. arXiv preprint.
36. Javier Romero et al. (2017). MANO: A Hand Model with Articulated and Non-rigid Deformations. SIGGRAPH Asia 2017.