A robot can do the right thing ten thousand times.
Some of the most useful data comes from the one time it does not.
When software fails, we reopen the app. When a robot fails, something physical has already happened. A wheel slipped. A gripper dropped an object. A sensor lost the world for a second. A person moved in a way the model did not expect.
That moment creates evidence.
The cameras saw something. The LiDAR saw something else. The motor current changed. The control system made a decision. The logs recorded an error. Somewhere inside all of it is the reason the robot failed.
The problem is finding those few seconds again.
From January to April 2026, we worked on Cerebric, an infrastructure idea for Physical AI. We started with a very large question: what would the data and learning stack for robotics look like if someone built it properly from the beginning?
The answer kept getting bigger.
Then one small part became more interesting than everything else.
We started with the whole stack
Our first version of Cerebric was broad.
Data recording. Cloud storage. Synchronisation. Visualisation. Annotation. Model training. Simulation. Deployment. Edge inference. Fleet management.
We put most of it on one slide.
If building an intelligent robot involved a hard software problem, it was probably somewhere on that slide.
The thesis was that robotics teams were rebuilding the same infrastructure internally. Their actual advantage was the behaviour of the robot, but their engineers still had to write logging scripts, align sensors, prepare datasets, manage GPUs and move models into the field.
There was truth in this. There was also too much in it.
The conversations complicated our assumptions. One robotics team did not generate or retain nearly as much data as we expected. Other young teams told us infrastructure was not their problem yet. Researchers pushed back on managed training tools that worked only while they stayed inside a narrow fine-tuning workflow. One team found cloud inference elegant in theory but could not ignore latency beside the robot.
Physical AI did not have one infrastructure problem.
The problem changed with maturity.
An early team might still need data. A team with robots in the field often had the opposite problem: more experience than anyone could inspect.
That was where Cerebric became sharper.
The rare data was the valuable data
Normal operation creates a lot of repetitive data.
A warehouse robot can make the same successful movement thousands of times. An autonomous vehicle can drive through another ordinary junction. A kitchen robot can handle another familiar ingredient. Most of this is useful when a system is young.
Later, the strange moments matter more.
The reflective package that confused the gripper. The pedestrian who appeared in heavy rain. The GPS signal that disappeared near a structure. The ingredient whose shape and texture were different from every previous batch.
These events are rare by definition. They are also the moments that separate a good demo from a reliable product.
In the public material we reviewed, companies kept talking about long-tail scenarios, unusual environments, simulation gaps and field reliability. That did not prove they all needed a search product. But for some teams closest to production, the useful question was no longer how to collect more data. It was how to find the few episodes that could change the next model or release.
The data was not missing.
The memory was.
A robot’s memory is not one file
Searching robotics data is harder than searching a folder of images.
The useful unit is an episode across time.
To understand why a robot fell, you may need the camera frames before it happened, the LiDAR point cloud, the IMU spike, the actuator signal, the command issued by the policy, the software version on the robot and the error that appeared a moment later.
Each stream has its own frequency and timestamp. One may be delayed. Another may be missing. The failure may not even be caused by the model. It could be hardware, an operator, the network or the environment.
That is why a clip alone is often not enough.
In one field-robotics workflow we reviewed, the work after a physical test included pulling the robot logs, labelling and archiving them, then deciding whether the issue was a known bug, operator error or a genuinely new failure.
The engineers had to do detective work before they could do model work.
The narrower Cerebric idea became a search engine for these experiences. Start with a natural-language query, an example failure, a scenario or a signal. Find related episodes across missions. Align the sensor streams. Cluster the duplicates. Let an engineer inspect the evidence and export the useful slice for evaluation or training.
The neat version was simple: find the failures, train on them, get a better model. Reality was harder.
If a search returns hundreds of clips and only a handful are useful, it has not removed manual work. It has moved it. If it misses the rare case that matters, high precision on everything else is not comforting. If it finds an anomaly without enough context, it may point to the wrong cause.
Retrieval had to be fast, but it also had to be trusted.
Search was the wedge, not the whole idea
By March, the search problem had become our clearest entry point.
By April, we found other teams moving toward video search, monitoring and curation for autonomy. That was both validating and uncomfortable. The category was becoming real. It also meant video search alone would not be enough.
The broader Cerebric idea was the full learning loop:
experience → find the failure → build the dataset → train → evaluate → deploy → experience
Data Capture would collect and organise multimodal fleet data. Data Research would help teams visualise missions, search for failures and turn scenarios into training or evaluation sets. Training and Inference would run the models, test them against previous failures and send safer versions back into the field.
The search layer connected the whole thing.
A failure found once should not remain a clip in someone’s downloads folder. It should become a named scenario, a cluster of similar events, a versioned dataset and a regression test for every model that follows.
The same robot should not have to teach the same lesson twice.
We priced the smallest box
We also framed the value too narrowly.
Our early financial model tried to estimate what teams might spend on search and retrieval. We counted software, infrastructure and some of the engineers maintaining internal tools.
In hindsight, that was the smallest box around the problem.
The value was not in finding a clip faster. It was in shortening the distance between a field failure and the next reliable model.
That distance includes debugging, annotation, curation, evaluation, simulation, retraining, release decisions and downtime.
Search was a product wedge.
Reliable autonomy was the economic problem.
This did not make every robotics startup a customer. A team without a real fleet may still be looking for data rather than drowning in it. The largest labs may keep building everything themselves.
We thought the first customers were likely to sit between them: teams close enough to production to have a growing corpus of real experience, but not enough specialised infrastructure talent to turn that corpus into a learning system.
As their fleets grew, the problem compounded. More robots created more data. More environments created more edge cases. More model versions created more questions about what had changed and why.
The opportunity was not only about how many companies we could count. The problem mattered because it sat on the path from a robot that sometimes works to one a customer can trust.
Reality still has the final vote
We did not leave April with every answer.
Could multimodal search achieve the recall required for safety-critical work without creating a review tax? Could it process huge datasets at a sensible cost? Would customers let an external system near sensitive fleet data? Would the product run in the cloud, inside a customer’s environment or beside the robot? Who would buy instead of building?
And finding an edge case did not automatically improve a model. The new model still had to be tested against normal behaviour. It could learn the rare case and regress somewhere else. Retrieval was the start of the learning loop, not proof that learning had happened.
These were not small details.
They were the product.
But the central problem did not go away.
As more robots leave controlled labs, they will record more ordinary operation. The strange moments will still not turn into knowledge on their own.
Someone still has to find them, understand them and feed them back into the system.
Physical AI will not improve only by remembering everything.
It will improve by remembering what mattered.