Augmenting Real-Word Data: Where Validation and Development Meet

Augmenting Real-Word Data: Where Validation and Development Meet

Autonomous systems are moving rapidly from labs and testing grounds into the real world. We see this most clearly with Physical AI, as autonomous vehicles, drones, and humanoid robots increasingly perceive, reason, and act in complex environments. As these systems become more capable and more widely deployed, demonstrating that they can operate safely becomes critical.

So how can we ensure that autonomous systems operate safely? The key is having the right data and the tools to curate, evaluate, and validate it. Data is a critical piece for both development, validation, and safety. The right data is sourced primarily from the real world, from the Operational Design Domain (ODD) where the Physical AI system will operate. Real-world data is the anchor. Everything else builds around it.

Real world data is what actually happened, including the situations nobody thought to model. That’s its fundamental value. What real-world data cannot provide on its own is sufficient coverage. You only get what the fleet encountered, so rare, dangerous events remain rare, which is exactly where synthetic data generation earns its place. Not as a replacement for real-world data, but as the way to extend it, turning events the fleet did encounter into the dangerous and rare variations it didn’t.

Another challenge is what happens to that data once you have it. In many organizations, development, validation, and safety have evolved as separate functions, each building its own pipeline around the same underlying data. Development builds a pipeline, because training is the obvious first use. Validation builds its own. Safety assembles its evidence from somewhere else again. Same raw data, same preparation work, three separate efforts. All of the real world drive data has to be denoised and cleaned. All of it has to be labeled, at the object level and at the scenario level. And across all three, you need to understand not only which situations occur, but how frequently they occur in the real world. Development needs that. Validation needs that. Safety needs that. That sequence, raw log in and usable data out, train and validate, and feeding back as more data comes from the fleet and synthetic data is generated: that is the data flywheel.


Build the data foundation once, then use it to serve the distinct needs of development, validation, and safety. The workflows and outputs may differ, but they should all build on the same prepared, structured, and continuously evolving data. A unified data flywheel eliminates duplicated infrastructure and preparation across development, validation, and safety, improving productivity while reducing cost. It also gives validation and safety a common foundation in real-world evidence, augmented by simulation where additional coverage is needed.

The question isn’t what I can do with all this data. It’s how do I unlock the value in it. The answer depends on where you’re starting. Some companies already sit on a lot of data they can’t get value out of, because the pipeline that was built for training and validation can’t use it. Their immediate need is to rebuild the pipeline once, properly. Others are just standing up a fleet, fifty cars running their main ODDs, a few thousand new miles a day, and they have the easier path, because building a unified pipeline makes all the gathered data useful from day one.

Safety has a clear date that needs to be met. UNECE WP.29’s R185 takes effect globally in January of 2027 and requires a documented safety case, audited for coverage of the conditions the vehicle is reasonably expected to face. That evidence comes out of the same data pipeline, which means a pipeline that wasn’t built to produce it becomes an expensive problem come January. The most advanced programs are already treating the safety case as an engineering output of the development and validation process, rather than something assembled at the end for the regulator.

This is where the industry should be going, and it’s the decision OEMs are making right now as they build their pipelines. At Foretellix we’ve already built it, it’s available today, and we’re ready to support you.

 

You might also like

Gil Amid

What is UNECE WP.29 R185?

UNECE WP.29 R185 introduces a new requirement for autonomous vehicle certification: manufacturers must provide evidence of reasonable Operational Design Domain…