Chapter 9: Data and Simulation — Infrastructure for the Learning Loop

Overview

The question in this chapter is: What evidence shows that a robot-data or simulation platform shortens the path to reliable real-world behavior? Motion-capture suits can record a human, teleoperation can record a robot, synthetic rendering can multiply visual conditions, a physics engine can produce contacts, a digital twin can mirror a cell, and a world model can predict a future video. These products all create “data,” but their labels, action semantics, embodiment gaps, and failure modes are different.

The thesis is that data infrastructure must distinguish human capture, robot data, simulation, replay, and world models. An hour of egocentric video is not an hour of torque-labeled robot execution. One thousand synthetic scenes are not one thousand independently validated physical trials. A digital twin that follows a real robot is not automatically a counterfactual simulator. A world model that produces plausible pixels is not necessarily accurate about friction, force, collision, or task success.

Noitom Robotics, DexForce, and SynapX are the three locked deep profiles for this chapter ^{[1] [6] [11]}. They represent three sharply different evidence states. Noitom markets capture, teleoperation, retargeting, and data-factory infrastructure. DexForce publishes a robot, simulation engine, world-model narrative, and detailed operating documentation. SynapX is named by PaXini in a partnership announcement, but its legal identity and independent product evidence remain unresolved. The third profile is therefore an evidence-boundary case, not permission to fill blanks from similarly named entities.

After reading this chapter... - You can distinguish human video, wearable capture, robot teleoperation, autonomous logs, synthetic data, real replay, and world-model rollouts. - You can diagnose where egocentric capture loses contact, force, calibration, or action information. - You can compare Noitom, DexForce, and SynapX across the same identity, product, technology, traction, maturity, interface, WRC, strength, limit, and confidence fields. - You can test whether a simulator predicts real policy ranking rather than merely looking realistic. - You can design a manufacturing learning loop with dataset lineage, split hygiene, replay gates, and controlled real-world promotion.

9.1 Five Data Objects That Must Not Be Blended

Robot learning discussions often use “dataset” for five different objects. Human observation records what people do. Wearables and motion capture add joint or body state. Teleoperation records a robot executing commands under human control. Autonomous logs record the deployed policy and its failures. Simulation generates state and action under a modeled world. The downstream learner may use all five, but it should not pretend their semantics are identical.

The unit of data also matters. Video hours reward long recordings. Episodes reward segmentation choices. Frames reward camera rate. Trajectories can contain success, abort, reset, or idle time. Tasks can be narrow variations or different skills. Scenes can differ only in texture or in geometry and workflow. A defensible corpus reports all relevant denominators and does not convert them into one “scale” number.

Quality is multidimensional. Coverage asks whether the target distribution is represented. Fidelity asks whether states and labels are correct. Synchronization asks whether vision, touch, force, proprioception, and command refer to the same physical instant. Actionability asks whether the target controller can reproduce the action. Governance asks who may use the data, for which purpose, under which consent, license, and retention policy. A larger corpus can be worse on any of these axes.

9.2 Capture Choices: Teleoperation, Wearables, and Egocentric Video

Teleoperation keeps observations and actions on the robot embodiment. It can expose camera images, joint states, commands, tactile values, and operator corrections under one clock. Its weakness is the operator channel. Latency changes contact behavior. A VR controller or glove may not reproduce the robot hand's kinematics. Operators learn the interface, so late demonstrations differ from early ones. A demonstration that succeeds after three hidden resets teaches a different distribution from first-attempt autonomy.

Wearables can improve hand and whole-body state. Inertial suits are portable but drift; optical markers can be accurate in a calibrated volume but suffer occlusion; gloves measure joint proxies but need fit and recalibration. Haptic gloves return some robot contact to the operator, but force bandwidth, direction, and mounting remain limited. DOGlove, for example, is useful research evidence that bilateral force feedback can change contact-rich demonstrations, while its cable maintenance and wrist-mounted hardware constrain in-the-wild scale ^[16].

Egocentric video offers a different scaling route. A head- or wrist-mounted camera observes diverse objects and human strategies without bringing a robot to every site. EgoDex pairs egocentric video with tracked hands; UMI carries an instrumented gripper into the wild; DexUMI uses the human hand as the interface and estimates its motion ^{[12] [14] [15]}. These approaches reduce robot time, but contact can disappear behind fingers, an object, or a tool.

“Contact loss” has several meanings. The camera may not see the contact patch. The system may see contact but not normal or shear force. It may know hand pose but not object compliance or friction. It may miss a failed touch because the operator immediately corrects. It may record human configurations that the robot cannot reach. An egocentric corpus should therefore state whether contact is observed, inferred, instrumented, or absent.

Retargeting is not a file conversion. It maps human motion to another morphology while preserving task-relevant interaction. Joint angles cannot simply be copied when limb lengths, joint limits, contacts, balance, and tools differ. The mapping needs feasibility checks and a record of what changed. Otherwise “human-scale data” becomes a large collection of infeasible robot targets.

9.3 Deep Profile I — Noitom Robotics

The Korean rendering is 노이톰 로보틱스, the English brand is Noitom Robotics, and the Chinese brand is 诺亦腾机器人. The official privacy notice names Noitom Robotics Technology (Beijing) Co., Ltd. as the website operator and gives a Beijing postal address ^[2]. The captured official sources do not state a foundation date for this robotics entity. Noitom Ltd., the earlier motion-capture company, reports a 2012 foundation, but that date must not be transferred to Noitom Robotics.

Flagship offerings include high-precision human-interaction capture, customized teleoperation, data management and quality assurance, human-to-robot mapping, ModalityNet and the World Compiler concept, and the Adam-U data-collection platform ^{[1] [3] [5]}. Adam-U is a partner-built system combining Noitom motion capture, a PNDbotics body, and Inspire Robotics tactile hands. The official page describes 31 DoF, binocular vision, safety brakes, synchronized motion, force-tactile and visual capture, and a $45,000 preorder starting point ^[5]. Those are issuer and partner configuration statements, not an independent accuracy or throughput benchmark.

The technical center is motion capture converted into robot-usable data. A capture system estimates human state. A retargeter projects that state into robot kinematics and contact constraints. A teleoperation loop sends feasible commands and returns visual or other feedback. A data pipeline synchronizes modalities, assigns task and quality metadata, and exports a training representation. Noitom's “World Compiler” extends this into a proposed layer that uses compact, structured corpora to organize larger, weakly structured data ^[3].

The official event photograph below shows an operator wearing a motion-capture suit and hand-tracking hardware while teleoperating Adam-U at WAIC 2025. It identifies the equipment boundary, but it does not measure latency, retargeting error, or accepted-data yield.

Noitom describes data factories, physical-state organization, and retargeting without publishing an independently benchmarked corpus size ^[3]. Its World Compiler article says it works with close to 100 companies, but does not define paid customer, active production pipeline, dataset volume, accepted episode, renewal, or independent validation. This is an issuer traction statement and conceptual disclosure, not a comparable dataset or deployment metric.

The developer surface is partly disclosed. Official pages claim integration with ROS, Isaac Sim, MuJoCo, C++, and Python and describe a developer-focused Adam-U SDK ^{[5] [4]}. The captured evidence does not establish public package repositories, supported versions, message schemas, deterministic latency, calibration files, licensing, or long-term maintenance. An interface claim is therefore stronger than no interface, but weaker than a reproducible external integration.

Commercial maturity is best described as custom business-to-business data and teleoperation services plus a preorder hardware platform. The maturity of the earlier motion-capture business is relevant background but does not prove the new robotics pipeline's quality. No audited finance, current revenue, gross margin, funding amount, corpus sales, or renewal is disclosed in the captured primary evidence. Adam-U's starting preorder price is public, while service, data-license, integration, annotation, storage, and support prices are undisclosed.

Media-corpus visibility is unmeasured because no complete eligible-news set, window, language policy, and deduplication rule exists. The official profile says the founder presented the data-factory vision at WRC 2024; this is issuer evidence of a past speaking appearance. The official WRC 2026 exhibitor page lists Noitom Robotics at B216 under 诺亦腾机器人科技（深圳）有限公司. This Shenzhen exhibitor entity must not be conflated with Noitom Robotics Technology (Beijing) Co., Ltd., the website operator named in the privacy notice. Booth participation is verified; programme status remains unverified.

Strengths are a long motion-capture lineage, explicit focus on synchronization and retargeting, cross-platform integration claims, and a full capture-to-governance story. Limits are the absence of an independently audited corpus, unspecified SDK reproducibility, unclear separation between legacy Noitom and Noitom Robotics traction, and little public predictive-validity evidence. Confidence is high for the official legal operator, Beijing location, named offerings, and Adam-U disclosed configuration; medium for platform maturity; low for finance, accepted-data throughput, and policy benefit.

9.4 Deep Profile II — DexForce

The Korean rendering is 덱스포스, the English brand is DexForce, and the Chinese brand is 跨维智能. The official legal name is 跨维（深圳）智能数字科技有限公司, rendered on its English site as DexForce Technology Co., Ltd. The official company page reports foundation in June 2021 and headquarters in Nanshan District, Shenzhen, with offices in several other Chinese cities ^[7].

Flagships span the DexVerse embodied-intelligence engine, DexWorldModel, EmbodiChain development platform, DexForce W1 Pro humanoid, and DexSense vision sensors ^[7]. This chapter treats DexForce as data-and-simulation infrastructure because its issuer narrative connects digital-asset generation, task simulation, model training, and physical deployment. It does not assume that owning a robot body proves simulator quality.

The public developer documentation is unusually operational. W1 manuals cover ROS 2-based mapping and navigation, teleoperation, data recording, calibration, URDF use, automatic modes, and saved files. The software interface also describes a digital-twin mode in which the simulated robot follows physical state and a pure-simulation mode in which commands move only the simulated robot ^{[6] [8]}. These details establish callable workflows, not their success rate.

DexForce documents mapping, ROS 2 integration, teleoperation, recording, and simulation modes without publishing a deployment success rate for those workflows ^[8]. Documentation proves that an operator can invoke and inspect functions. It does not establish map quality across sites, acceptable teleoperation latency, usable demonstration yield, autonomous task completion, or digital-twin predictive accuracy.

The distinction between mirroring and prediction is important. A digital twin that synchronously displays the physical robot is valuable for visualization, logging, and diagnosis. It becomes a predictive simulator only if the virtual response to an unexecuted action forecasts the real response under defined tolerances. Pure-simulation mode provides a testing surface, but its collision, contact, actuator, camera, latency, and object models still require validation.

SDK maturity is documented product integration: ROS 2 commands, services, RViz, URDF, system services, saved pose recordings, and versioned manuals are visible. Public Isaac Sim or Isaac Lab packages, source availability for DexVerse, a complete schema for training datasets, and compatibility tests across simulator releases were not established in the captured sources. The company describes world models and generated data, but model weights, dataset manifests, and independent reproduction are unverified.

Finance and traction remain issuer-qualified. The official company page reports, as issuer figures, more than 50 industries, more than 100 customers, and more than 1,500 scenarios, but the definitions and reporting period are not matched to other firms ^[7]. The official homepage announced RMB 1 billion in Series B financing on June 30, 2026 ^[9]. This is a disclosed issuer event, not an audited revenue or cash-balance statement. Revenue, gross margin, shipment, active robots, renewal, and simulation-software mix remain undisclosed.

WRC status is stronger: the official 2026 organizer page lists DexForce at booth C303 and names W1 Pro, DexVerse, DexWorldModel, and application claims ^[10]. Organizer listing verifies participation and product presentation. It does not independently verify the issuer's model rankings, task success, or commercial scale. Media-corpus visibility is still unmeasured under a complete corpus method.

Strengths are detailed operator documentation, an integrated robot-simulation-model portfolio, explicit digital-twin and pure-simulation modes, and organizer-verified WRC presence. Limits are issuer-only scale and financing disclosure, no independent simulator-to-real ranking study, unclear generated-data lineage, and unverified public Isaac support. Confidence is high for legal identity, foundation, headquarters, documentation, and WRC status; medium for commercial maturity; low for predictive validity, recurring economics, and cross-task policy claims.

The WRC organizer case photograph below shows two physical W1 Pro units in a café-like work setting. It reveals the relation between hardware and task objects, but it does not provide a matched simulated view, digital-twin prediction accuracy, or autonomous success rate.

9.5 Deep Profile III — SynapX

The Korean rendering used here is 시냅엑스 and the English name in the source is SynapX. A verified Chinese brand name, legal entity, foundation date, headquarters, founder, and official domain were not established. Search results for other organizations with similar names are excluded because name similarity is not identity evidence.

The only admitted primary evidence is PaXini's official news page, which names “PaXini and SynapX” in a strategic partnership around OmniVTLA 2.0 ^[11]. The captured page does not expose a detailed article body, a SynapX-authored announcement, a legal identifier, a product catalog, or an independent benchmark. It verifies that PaXini used the name in a partnership headline. It does not verify what SynapX supplied.

Accordingly, flagship products are unresolved. Technology scope beyond association with the named OmniVTLA 2.0 partnership is unverified. Dataset size, capture modality, synthetic renderer, physics engine, world model, teleoperation system, digital twin, SDK, ROS, Isaac, licensing, pricing, deployment, customers, shipment, finance, and employee scale are undisclosed or unverified. None is inferred from PaXini's own broader tactile and data portfolio.

Maturity cannot be responsibly assigned to “product,” “pilot,” or “deployment.” The correct label is partner-announcement evidence only. Official WRC 2026 status is unverified. Media-corpus visibility is unmeasured, and the single partner page cannot be turned into a share-of-voice statistic.

The strength of this profile is methodological: it prevents an ecosystem map from laundering a partner mention into a fully specified company. Its limit is substantive: almost every field remains open. Confidence is high that PaXini published the name and partnership headline; low for identity resolution; and insufficient for products, technology, finance, traction, interfaces, maturity, policy benefit, or comparative ranking.

Before future promotion, the minimum evidence packet should include a SynapX-controlled domain, legal registration, named representatives, dated product or technical documentation, interface terms, and a test whose embodiment, dataset, split, intervention, and metric are disclosed. The PaXini signing photograph below supports only the named partnership around OmniVTLA 2.0. It is not evidence of a SynapX product, dataset, model, or legal identity.

9.6 Same-Scale Profile Comparison

The comparison table keeps “unresolved” visible. A blank does not mean zero, and a partnership headline does not sit on the same evidence rung as versioned operating documentation.

Noitom's and DexForce's claims also answer different questions. Noitom foregrounds capture and representation. DexForce foregrounds generated data, simulation, a world model, and a delivered robot stack. SynapX supplies no comparison-ready technical unit. A buyer should compare a named deliverable—accepted demonstration hour, versioned simulator scene, policy evaluation run, or deployed skill—not the breadth of a website narrative.

9.7 Dataset Scale Without False Equivalence

EgoDex reports 829 hours across 194 tabletop tasks, but those hours are not directly comparable to datasets with different sensors, embodiments, tasks, or quality filters ^{[12] [13] [14]}. EgoDex records egocentric human video and tracked hands. DROID reports 76,000 robot trajectories totaling 350 hours across 564 scenes and 84 tasks. UMI records portable, gripper-mediated demonstrations. Their denominators describe different assets.

For procurement, each dataset should have a “nutrition label.” It should state total raw and accepted duration; episode and task definitions; success, failure, reset, and idle fractions; sensor list and rates; action and control frame; robot and tool versions; operators and sites; object, lot, and scene distribution; annotation provenance; train, validation, and test split; license; consent; and deletion policy.

Hours can hide redundancy. Ten operators repeating one motion in one fixture may give more frames but little new coverage. Conversely, a small failure corpus may be disproportionately valuable if it captures rare jams, misgrasps, sensor dropout, and recovery. The useful denominator is often effective diversity under the target task distribution, not storage size.

Human data is attractive because it scales before robot hardware. Yet its labels are indirect. EgoDex obtains tracked hand joints during recording ^[12]. The action still belongs to a human body. A robot learner needs retargeting, embodiment alignment, or representation pretraining. A method that converts a human video into a robot command should preserve its transformations and uncertainty, not present the result as directly measured robot action.

Robot data is closer to execution but expensive and narrower. Teleoperation can collect successful behavior while underrepresenting autonomous drift. Autonomous logs capture the deployed distribution but only after a policy exists. A healthy loop deliberately mixes success, near miss, failure, intervention, and recovery, with each origin marked.

9.8 Rendering, Physics, Digital Twins, Replay, and World Models

Synthetic rendering, physics simulation, real replay evaluation, and world models solve distinct problems ^{[17] [18] [19] [20]}. Rendering changes pixels and labels. Physics computes state transitions under explicit models. A digital twin binds a virtual asset to a specific physical system. Replay evaluates a policy against recorded or reconstructed real conditions. A learned world model predicts observations or latent states from data.

Synthetic rendering is valuable for camera pose, lighting, material, clutter, segmentation, depth, and rare visual combinations. It can provide perfect labels by construction. The danger is renderer fingerprinting: a model learns textures, edges, noise, or object-generation artifacts that reveal the synthetic domain. Photorealism can reduce visible gaps while leaving contact and causality wrong.

Physics engines expose mass, inertia, friction, compliance, actuator, latency, and contact. Differentiable simulators such as DiffTactile allow gradients through contact and material models under the paper's supported settings ^[17]. TacEx combines soft-body and visuotactile simulation for GelSight-class observations in Isaac Sim ^[18]. Both are method evidence. Neither proves that every commercial sensor or factory material is represented.

A digital twin needs identity and synchronization. Geometry, joint calibration, tool, camera intrinsics, controller, firmware, payload, and cell assets must match a physical serial-numbered system. A live mirror can reveal state and replay incidents. Counterfactual use—asking what would have happened under another command—requires a validated dynamics model. Without that validation, “twin” may mean only a dashboard avatar.

Real replay anchors evaluation in recorded reality. A policy can be run against video, reconstructed scenes, or initial states while actions are simulated. SIMPLER explicitly studies whether simulated evaluations reproduce real policy performance relationships and robustness patterns ^[19]. The important product question is not whether the simulated success percentage equals the real percentage. It is whether simulator decisions—ranking, regression detection, and promotion—are predictive enough to reduce risky physical tests.

World models learn transition distributions rather than relying only on hand-authored physics. DreamDojo trains on large-scale egocentric video and post-trains for controllable robotics uses, including planning and policy evaluation ^[20]. Generated futures can cover complex appearances and interactions. They can also be plausible but physically wrong, drift over long horizons, or copy training patterns. World-model output should remain a proposal and evaluation signal until real gates confirm it.

9.9 Sim2Real Is a Predictive-Validity Problem

The usual question—“how small is the reality gap?”—is too vague. A simulator can have good visual similarity and poor control transfer, or imperfect pixels and excellent policy ranking. The needed validity depends on the decision. Training needs a distribution that induces useful representations and actions. Evaluation needs policy ranking and failure modes. Safety analysis needs conservative bounds. Digital-twin diagnosis needs serial-specific state agreement.

Predictive validity can be measured through paired tests. Select policies with known diversity, freeze them, and evaluate them in simulation and reality on the same task protocol. Compare rank correlation, success differences, force and trajectory distributions, and failure confusion. Then perturb lighting, camera, friction, payload, geometry, latency, wear, and object lot. A valid evaluation tool should predict which policy degrades and why.

System identification is one route. PACE, for example, uses 20–60-second real excitation sequences to estimate dynamics parameters before transfer on legged robots ^[21]. Its lesson is not that one brief sequence universally solves Sim2Real. The parameters depend on excitation bandwidth, robot rigidity, firmware, temperature, wear, and modeled effects. Identification has a validity window and should be versioned like software.

Real-to-sim-to-real pipelines reconstruct scenes or demonstrations, optimize in simulation, and return robot behavior. X-Sim exemplifies the route from human demonstration through reconstructed interaction to robot policy ^[22]. Reconstruction errors in object geometry and contact become upstream label errors. The pipeline must preserve confidence and reject scenes that are not reconstructable rather than forcing every video into a synthetic task.

Domain randomization is useful when uncertainty is bounded. Randomizing every parameter over huge ranges can create a robust but inefficient policy or hide a wrong nominal model. The distribution should come from measurements and cover deployment variation. Randomization is not a substitute for identifying sensor latency, actuator limits, collision geometry, or safety-critical contact.

9.10 Leakage, Replay Contamination, and Governance

Data leakage in robotics is broader than duplicate images. A scene can appear in both training and evaluation with a different camera crop. The same object instance can appear under another task name. A human video can pretrain a world model and later enter a replay benchmark. Synthetic variants can share one base mesh or trajectory. A teleoperator can collect the evaluation sequence after seeing the target. A foundation model may already have ingested public benchmark videos.

Splits should therefore operate at the causal unit relevant to generalization. For object generalization, hold out physical instances and product families. For scene generalization, hold out sites and layouts. For operator generalization, hold out people. For maintenance robustness, hold out sensor batches and calibration sessions. For policy evaluation, keep real test episodes, reconstructed assets, and generated derivatives in one lineage group so descendants cannot cross the split.

A dataset registry needs immutable episode IDs and parent-child provenance. Each transform—trim, label, retarget, reconstruct, render, augment, correct, or filter—creates a derived asset linked to its parents, code version, model, parameters, and reviewer. Deleting a source for consent or licensing reasons must identify descendants. This is data operations, not merely machine-learning bookkeeping.

Replay evaluation needs intervention hygiene. If an evaluator manually chooses favorable initial states, drops hard episodes, or tunes thresholds on the test replay, it leaks test information. A policy promotion record should name the frozen checkpoint, simulator and asset versions, episode manifest, exclusions, retries, and the physical confirmation subset.

Security and privacy matter because wearables and egocentric cameras capture people, homes, screens, voices, work practices, and intellectual property. Consent for model training can differ from consent for public release or commercial resale. Face and text blurring does not remove body, location, or trade-secret risk. Data contracts should cover purpose, region, retention, access, deletion, derivative models, and incident response.

9.11 Economics of a Learning Loop

Data price is not cost per hour. A useful economic unit is cost per accepted, reusable episode and ultimately cost per incremental successful task. Capture labor, hardware depreciation, calibration, reset, annotation, quality review, storage, transfer, simulation compute, policy training, real validation, and failed deployment all count.

Let accepted yield be y, raw collection hours be H, and total collection and processing cost be C. Then accepted-hour cost is C/(Hy). A higher-speed operation can be worse if contact is lost or synchronization fails. The yield definition should require complete sensors, valid action, task label, outcome, no privacy violation, and reproducible calibration.

Simulation has a different cost curve. After a scene and asset are built, many variants may be cheap, but asset construction, physics tuning, renderer maintenance, GPU time, and validation remain. World-model rollout shifts cost toward training and inference while adding calibration and uncertainty monitoring. The correct comparison includes the physical tests still required after virtual screening.

The business model also changes incentives. A hardware sale rewards unit delivery. A data service may charge by raw or accepted hour. A platform may charge by seat, API, storage, or compute. A model vendor may retain improvement rights. Procurement should define ownership of raw recordings, derived labels, simulator assets, policies, telemetry, and trained weights before collection begins.

9.12 Manufacturing Walkthrough: Build a Connector Learning Loop

Consider the connector-seating cell from Chapter 8. The new objective is not only to operate it, but to create a learning loop that improves across connector lots, socket tolerances, cables, lighting, and sensor replacement without contaminating evaluation.

Step 1: Define the decision. The loop must predict whether a candidate policy can be promoted to a guarded physical trial. This makes policy ranking, false promotion, and missed regression more important than photorealism alone.

Step 2: Define the episode. An episode begins before the connector is grasped and ends with verified seating, safe withdrawal, quarantine, or human takeover. Pre-contact approach, first touch, search, insertion, latch event, inspection, and recovery receive timestamps. Resets remain inside the record.

Step 3: Instrument reality. Record cameras, hand and arm state, wrist force, tactile data, command, controller mode, safety events, board and connector lot, calibration, firmware, and operator interventions on one clock. Create immutable hardware and episode identities.

Step 4: Choose capture sources. Use teleoperation for embodiment-valid actions, autonomous logs for policy failures, and wearable or egocentric recording only for complementary human strategy. Mark absent human-side contact force rather than inferring it as measured.

Step 5: Establish accepted yield. Reject episodes with missing clocks, dropped modalities, wrong calibration, unknown reset, unsafe action, ambiguous outcome, or consent failure. Keep rejected metadata so the data factory cannot improve its reported yield by silent deletion.

Step 6: Build the simulator asset. Version socket and connector geometry, material and friction assumptions, camera, hand, controller delay, force limits, and collision models. Bind the digital twin to specific physical serials and firmware.

Step 7: Calibrate with paired trials. Execute a small designed set of safe trajectories in real and simulated cells. Fit only parameters supported by excitation. Reserve some paired trials for validation, and monitor residuals across temperature and wear.

Step 8: Generate variations. Vary lighting, pose, lot geometry, friction, cable stiffness, and sensor noise within measured distributions. Tag every synthetic episode with source assets, parameters, renderer, physics, and policy versions.

Step 9: Freeze leakage-safe splits. Hold out connector and board lots, a fixture, a sensor replacement batch, and time periods. Keep real episodes and every replay, reconstruction, or rendered descendant in the same split family.

Step 10: Test predictive validity. Evaluate several frozen policy checkpoints virtually and physically. Compare their ordering, false-seat detection, peak force, damage, recovery, and intervention. Do not tune against the final physical holdout.

Step 11: Promote through gates. A world-model or simulator result can nominate a policy. Static limits and safety review gate it. Shadow or reduced-speed execution precedes production speed. A person retains stop and rollback authority.

Step 12: Feed failures back. Classify every real miss as perception, geometry, contact, dynamics, latency, controller, policy, safety, or process. Decide whether to update data, model, asset, parameter, or operating procedure. Do not label every failure “Sim2Real.”

Manufacturing Cell Checkpoint

The task schema needs assembly, connector and board lot, geometry revision, grasp, target pose, force and search limits, expected contact signature, success inspection, failure class, retry, quarantine, and human authority.

The data schema needs immutable episode and lineage IDs; sensor, robot, tool, fixture, firmware, calibration, model, renderer, simulator, and asset versions; source type; consent and license; split family; transformation parents; outcome; intervention; and reviewer.

KPIs include accepted episode yield, usable contact-event density, synchronization loss, label disagreement, policy rank correlation between virtual and real tests, false promotion, missed regression, first-pass yield, damage, human minutes, compute and collection cost, and time from failure to validated update.

Safety ownership stays outside the learned model. Production owns process and material. Quality owns seating and damage definitions. Safety owns physical limits and promotion gates. Data engineering owns lineage, access, and deletion. Simulation owns asset validity. Learning owns checkpoints and evaluation. The integrator owns real-time execution and rollback. Suppliers own contracted interfaces and version support.

9.13 Evidence Ladder and Procurement Questions

A company diagram is evidence of intended architecture. Documentation is evidence that an interface exists. A dataset card is evidence of definitions. A paper benchmark is bounded method evidence. A matched simulator-real study is evidence of predictive validity. A production cohort is evidence of sustained benefit. These rungs should not be collapsed.

Procurement should ask for a sample episode with raw and calibrated streams, the schema and clock specification, acceptance and rejection rules, and a lineage graph. It should request a simulator validation report with paired real trials, not only rendered videos. It should identify software versions, offline behavior, support periods, export rights, deletion, and model-improvement rights. Finally, it should price a reproducible second-site deployment rather than a one-off demonstration.

9.14 Limitations and Open Questions

First, the three profiles have unequal evidence. Noitom and DexForce control official domains. SynapX does not have a resolved first-party identity in the evidence packet. The resulting asymmetry is a finding, not a gap to fill by speculation.

Second, issuer metrics use incomparable units. “Close to 100 companies,” “1,500 scenarios,” funding, preorder price, dataset hours, and task counts do not share a denominator. They are retained with source, date, and qualification.

Third, public documentation does not expose enough data quality. Accepted yield, contact-event density, failure fraction, operator learning, calibration drift, intervention, and privacy rejection are rarely reported. Corpus size therefore cannot establish learnability.

Fourth, simulation validity is task-specific. Rigid tabletop manipulation, tactile elastomers, legged dynamics, and factory cable insertion need different models and tolerances. No source establishes one simulator as universally predictive.

Fifth, world-model evaluation remains young. Pixel plausibility, action controllability, task outcome, force consistency, uncertainty calibration, and long-horizon stability can disagree. A generated future should not bypass feasibility, controller, collision, force, or human safety authority.

Sixth, leakage is difficult to audit for large pretrained models. Public videos, derived meshes, benchmark scenes, and proprietary customer data can overlap without a common registry. Claims of zero-shot generalization need stronger lineage disclosure.

Seventh, media-corpus visibility was not measured under a complete policy. WRC 2026 is organizer-verified only for DexForce. Noitom's 2024 speaking reference is issuer history, and SynapX remains unverified.

Open questions follow. Can accepted robot experience grow without hiding reset labor? Can human video acquire reliable contact and action labels at scale? Can a simulator maintain predictive ranking after firmware, wear, or object-lot change? Can a world model expose calibrated uncertainty instead of only plausible video? And can customers retain enough data and asset portability to change vendors without rebuilding the learning loop?

Relation to Prior Surveys

This chapter extends the hand-and-touch discussion from Chapter 8. A tactile sensor produces a stream only after geometry, calibration, timing, and contact are defined. Chapter 9 asks how that stream joins vision, proprioception, action, outcome, and lineage. Teleoperation and tactile-learning papers supply mechanism evidence; the company profiles supply product and documentation evidence. Neither alone establishes a production learning loop.

The agentic-coding comparison is instructive. Software can often stage an exact artifact, run deterministic tests, and restore a snapshot. A physical staging environment cannot clone wear, friction, cable routing, people, or a damaged connector exactly. Robot CI/CD must therefore combine virtual screening, bounded physical experiments, safety authority, and irreversible-world logs.

What to Learn Next

Chapter 10 moves from infrastructure to the models that consume it: VLAs and world models connecting language, perception, action, and factory constraints. The key question becomes not “how much data or simulation exists?” but “which model interface turns them into an action proposal that a real controller can execute and a factory can verify?”

Carry three requirements forward. Every model input needs lineage. Every simulated or generated result needs a validated decision envelope. Every action output needs feasibility, real-time control, safety, and outcome verification outside the model. These boundaries turn a learning loop into factory infrastructure rather than a sequence of impressive demos.

References

1. Noitom Robotics (2026a). About Noitom Robotics. Official company and leadership source.
2. Noitom Robotics (2026b). Privacy Notice and Website Terms. Official legal-operator and Beijing address source.
3. Noitom Robotics (2026c). The World Compiler and ModalityNet. Official concept and issuer-traction source.
4. Noitom Robotics (2026d). Noitom Robotics Official Product and Service Portal. Official capture, teleoperation, QA, and integration source.
5. Noitom Robotics (2025). Adam-U: Purpose-Built Humanoid Data Collection Platform. Official partner configuration and preorder source.
6. DexForce (2026a). DexForce Product Documentation Center. Official manuals and developer documentation.
7. DexForce (2026b). About DexForce. Official legal identity, foundation, headquarters, product, and issuer-traction source.
8. DexForce (2026c). W1 Advanced Software Features. Official mapping, teleoperation, recording, and simulation-mode documentation.
9. DexForce (2026e). DexForce Official Homepage and Financing Disclosure. Official issuer news index.
10. World Robot Conference (2026). DexForce 2026 Exhibitor Profile. Organizer source for booth and named products.
11. PaXini (2026). PaXini and SynapX: Strategic Partnership around OmniVTLA 2.0. Official partner source; SynapX identity remains unresolved.
12. Hoque, R. et al. (2025). EgoDex: Learning Dexterous Manipulation from Large-Scale Egocentric Video. arXiv:2505.11709; ICLR 2026. Terry's reading note #76.
13. Khazatsky, A. et al. (2024). DROID: A Large-Scale In-The-Wild Robot Manipulation Dataset. arXiv:2403.12945.
14. Chi, C. et al. (2024). Universal Manipulation Interface: In-The-Wild Robot Teaching Without In-The-Wild Robots. arXiv:2402.10329.
15. Xu, M. et al. (2025). DexUMI: Using Human Hand as the Universal Manipulation Interface for Dexterous Manipulation. arXiv:2505.21864. Terry's reading note #8.
16. Zhang, H. et al. (2025). DOGlove: Dexterous Manipulation with a Low-Cost Open-Source Haptic Force Feedback Glove. RSS 2025; arXiv:2502.07730.
17. Si, Z. et al. (2024). DiffTactile: A Physics-based Differentiable Tactile Simulator for Contact-Rich Robotic Manipulation. ICLR 2024; arXiv:2403.08716.
18. Nguyen, D. H. et al. (2024). TacEx: GelSight Tactile Simulation in Isaac Sim. arXiv:2411.04776.
19. Li, X. et al. (2024). Evaluating Real-World Robot Manipulation Policies in Simulation. arXiv:2405.05941.
20. Gao, S. et al. (2026). DreamDojo: A Generalist Robot World Model from Large-Scale Human Videos. arXiv:2602.06949.
21. Bjelonic, F. et al. (2025). Towards Bridging the Gap: Systematic Sim-to-Real Transfer for Diverse Legged Robots. arXiv:2509.06342. Terry's reading note #82.
22. Dan, P. et al. (2025). X-Sim: Cross-Embodiment Learning via Real-to-Sim-to-Real. arXiv:2505.07096.
23. Ruijie Zheng et al. (2026). EgoScale: Scaling Dexterous Manipulation with Diverse Egocentric Human Data. arXiv:2602.16710. Terry #38.
24. Chi Zhang et al. (2025). UniTacHand: Unified Spatio-Tactile Representation for Human to Robotic Hand Skill Transfer. arXiv:2512.21233. Terry #16.
25. Zilin Si et al. (2025). ExoStart: Efficient Learning for Dexterous Manipulation with Sensorized Exoskeleton Demonstrations. arXiv:2506.11775.
26. Various (2024). Touch100k: A Large-Scale Touch-Language-Vision Dataset for Touch-Centric Multimodal Representation. arXiv:2406.03813.
27. Binghao Huang et al. (2024). 3D-ViTac: Learning Fine-Grained Manipulation with Visuo-Tactile Sensing. arXiv:2410.24091.
28. Yevgen Chebotar et al. (2019). SimOpt: Learning Robotic Skills in Simulation with Sim-to-Real Transfer. DOI:10.1109/icra.2019.8793789.
29. Wenhao Yu et al. (2017). Preparing for the Unknown: Learning a Universal Policy with Online System Identification. DOI:10.15607/rss.2017.xiii.048.
30. Josh Tobin et al. (2017). Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World. DOI:10.1109/iros.2017.8202133.
31. Javier Romero et al. (2017). MANO: A Hand Model with Articulated and Non-rigid Deformations. DOI:10.1145/3130800.3130830.
32. Lerrel Pinto et al. (2016). Supersizing Self-supervision: Learning to Grasp from 50K Tries and 700 Robot Hours. arXiv:1509.06825.
33. Chelsea Finn et al. (2016). Unsupervised Learning for Physical Interaction through Video Prediction. arXiv:1605.07157.
34. Eric Rohmer et al. (2013). V-REP: a Versatile and Scalable Robot Simulation Framework. DOI:10.1109/iros.2013.6696520.
35. Brenna D. Argall et al. (2009). A Framework for Learning from Demonstration. DOI:10.1016/j.robot.2008.10.024.