The most valuable robotics data might be what the simulation gets wrong.

There’s an interesting question developing in robotics: as simulation gets better, which real-world data becomes more valuable—and which becomes easier to replace?

Some companies are investing heavily in collecting demonstrations of people performing physical tasks. Others are creating virtual environments, generating synthetic training data and transferring what robots learn into the real world. Many combine the two.

Both approaches make sense. But the balance between them matters for businesses supplying training data.

I’ve been investigating the possibility of building a distributed physical-data collection network through existing industrial businesses. Instead of constructing artificial environments where people repeatedly perform tasks for cameras, why not collect information from workplaces where those activities are already happening?

A manufacturing company might have technicians repairing machinery. A marine services business might maintain equipment in environments that are difficult to reproduce. A construction company might have skilled tradespeople working with tools and materials that vary considerably from one job to the next.

With appropriate equipment, permissions and licensing agreements, some of that work could potentially become useful training or evaluation data.

What if simulation needs less of it?

There’s a significant commercial question: what happens when simulation becomes good enough to generate much of the information robotics developers need?

DexForce’s EmbodiChain report describes generating training trajectories in simulation and testing the resulting policies on real robots. Hesai’s Kosmo announcement describes turning captured physical spaces into simulation-ready environments.

Those developments could reduce the amount of physical recording required for some tasks. That’s good for robotics developers. It could be less good for a business whose proposition is simply selling enormous quantities of raw demonstrations.

But simulation isn’t magic. A virtual environment depends on assumptions about how the physical world behaves, and those assumptions have to come from somewhere.

The history inside the machine

A simulated machine might include a model of bearing wear. But how accurately does that model represent the real machine after ten years of maintenance, imperfect repairs and unusual operating conditions?

A simulated technician might perform the documented repair procedure. What about the experienced technician who recognizes that the procedure is wrong for this particular machine because they’ve encountered the same failure repeatedly?

Those are the situations that interest me—not because they automatically produce valuable datasets, but because they might contain information that is difficult to generate faithfully without observing the real thing.

Simulation can model rare failures and imperfect conditions too. The question is whether its assumptions and predictions hold up against evidence from the equipment and workflows it is meant to represent.

Teaching and testing are different markets

Suppose a developer trains a robot primarily in simulation. Eventually, somebody needs to establish how it performs in the real world.

That creates a potential need for independent evaluation evidence: actual failures, operating conditions and outcomes that were not simply generated by the training environment.

Historical records that cannot directly teach a robot a physical movement might still help developers identify failure scenarios, define expected outcomes or test the decisions of specialized industrial systems.

Those records do not, by themselves, establish that a physical robot is safe or reliable. Appropriate real-world testing remains necessary. And evaluation material needs careful separation from training data if it is to provide an independent test.

That is a different market from demonstration collection—and it changes how I would approach the businesses generating the information.

Ask about the exceptions, not the hours

Rather than asking a manufacturer how many hours of video it can supply, I’d want to understand its operational history.

• What goes wrong?
• What happens infrequently?
• What takes years of experience to diagnose?
• What information has been preserved about those events?
• What rights could legitimately be licensed without exposing confidential customer information or compromising the business?

Some records might have little commercial value. Others could be useful to developers building specialized industrial systems. The only way to know is to connect the information to a real buyer requirement and test whether it improves performance or reveals a meaningful weakness.

I’m becoming increasingly interested in that process. The future of physical AI probably won’t be determined by who collects the most footage. It may depend on who can establish that the information they supply adds something the developer’s existing methods are missing.

And that’s a question worth spending some time on before buying a warehouse full of cameras.