In a world with a billion intelligent machines, deploying the next one will be an ordinary act of engineering. A team will choose the work it wants done, adapt a capable machine to it, establish that it can do the job and put it into service. Much of the work underneath will already exist.
That is the world to reason backwards from.
Today, the journey from collecting data to a machine doing useful work contains a substantial amount of engineering that each team must assemble. Recordings must become usable training data. Models must become reliable behaviour. Simulated results must survive contact with real conditions. Failures must be traced, corrected and tested again.
The robot may be physically capable of the job long before the team can demonstrate that it will perform it reliably, safely and at an acceptable cost. The time between those two states limits how quickly the industry can put its progress to use.
For a billion machines to become practical, deployment has to become repeatable. The engineering required for the next deployment has to inherit more of the work completed for the last.
We have seen versions of this transition before. The PC gave builders a common computing architecture. Cellular networks made a handset useful far beyond the place it was purchased. Cloud services made computing capacity something a software team could consume on demand. Uber could begin with people already carrying connected computers with GPS.
Each new company could start further ahead because something it needed had become available to everyone.
Robotics needs that same accumulation of reusable work. Models, simulators and development tools already supply important pieces. The remaining opportunity is to turn more of the work within and between them into services that teams can use without building the process themselves.
This foundation will be assembled through specific problems solved well enough that other teams stop having to solve them again. A useful tool earns adoption. Compatible tools remove more work together. Over time, enough companies depend on them that their existence becomes an assumption. That is when development tools become infrastructure.
The test of each addition is straightforward: does it bring forward the date a customer can put a machine into useful operation?
An ambitious target is to halve the time from first data to a deployment-ready policy for comparable tasks, then halve it again:
Each reduction must preserve the required safety, reliability and economics. The time has to come out of manual work, waiting, integration and avoidable repetition. The measure is the complete journey to a policy that can run the machine at the required standard.
Data quality is an early place to make that intervention because it sits where the learning process begins. A recording can be easy to store and difficult to learn from.
Images, robot states and actions must describe the same event. An action paired with the wrong observation, an inconsistent measurement or an incomplete recording can create a problem that only becomes apparent further into development.
The cost of preventing these problems is already substantial. Skild AI reports spending three dollars on quality control for every dollar it spends collecting data.
Automating verification, correction and normalisation addresses both the work of preparing data and the avoidable rework caused by defective inputs. The immediate ambition is to turn QC that occupies a team for months into a process one person can supervise in hours. Its value is the time removed from the path to a deployable policy.
The prepared data then enters training. The resulting policies must be tested across simulation and reality, evaluated against the task, and brought to deployment readiness. Each step exposes the next delay. Work on training, real-to-sim and sim-to-real transfer, evaluation and policy readiness follows the same objective: compress the remaining distance to useful operation.
The connection between these services matters.
Data already checked should arrive ready for training. A trained policy should carry the information needed to evaluate it. A failure should retain the conditions needed to reproduce it. Each new capability should reuse the customer’s earlier work, making the next step easier to adopt and the whole process faster to repeat.
The customer’s route to deployment supplies the sequence of problems. Removing them supplies the reason to adopt the next service.
As the engineering required per deployment falls, more applications become worth deploying. More deployments create demand for more machines. Larger production runs can lower hardware costs, making further applications viable. Shortening development brings productive work forward; reducing repeated engineering changes how many deployments a team can support.
Once machines are working at scale, the problem expands into inference: running their models throughout their working lives. Every active machine creates continuing demand for model execution. Fleets need dependable operation, controlled updates and a way to turn experience from the field into improvements.
Services that carry tested policies into operation and return field failures to development can support both preparation and daily use, provided they meet the machines’ latency, reliability and cost requirements.
Development creates the installed base; inference serves it for as long as the machines operate.
From the far side of a billion intelligent machines, this accumulation of software will look like an obvious prerequisite. In the present, it is a succession of concrete engineering problems. Every one removed lets the next team begin further ahead.
Oru’el is beginning with data quality.