# Event Report: Zoox on Measurable Software Assurance at AV & AI USA 2026 > Source: > Published: 2026-10-29 18:38:41+00:00 **TL;DR:** Zoox’s Selvam Somalraju argued at Autonomous Vehicles & AI USA 2026 that following safety standards such as ISO 26262 shows what was done, not how much safer the software is. He presented a four-pillar assurance framework and a six-step method that turns weighted best-practice scores into a failure rate, an ODD-specific risk estimate and, finally, a deployment decision. At Autonomous Vehicles & AI USA 2026 in Anaheim (August 26–27), Selvam Somalraju of Zoox gave a talk titled *“From Standards to Safety: Building a Measurable Software Assurance Framework for Autonomous Vehicles.”* Many safety talks stay at the level of principles. This one tried to answer a specific question: once you’ve followed the standards, how do you put a number on how much safer the software actually is? ## Key takeaways - At AV-level failure targets, proving safety through testing alone would take an impractical amount of time. The workable path is frozen software, a feasible test campaign, and a structured body of evidence. - Existing standards such as ISO 26262, DO-178C, IEC 61508 and EN 50128 raise the required rigor with the integrity level, but they are mostly qualitative and weren’t written for ML components or software that changes every week. - The framework organizes assurance work into four pillars: in-house software, third-party dependencies, development and test tooling, and software interfaces. - The central idea is a chain from weighted best-practice scores, to an estimated failure rate, to ODD-specific risk, to a deployment decision. - Zoox published its own Safety Case Framework in August 2026, built on the same ideas. ## Why AV software is a different problem Somalraju started from a gap: for most systems, there is no explicit US regulation that defines safe software behavior. That leaves engineering teams to answer three questions on their own. What is the correct behavior? Why is it correct? Did the system actually do it? In consumer software, bugs mostly cost market share. In safety-critical systems, they can cost lives and lead to lawsuits or regulatory action. AV software sits firmly in the second category, at a scale few industries have dealt with before. He explained why testing alone can’t carry the argument. If a software safety goal is set at something like one failure per 10⁷ hours, showing that statistically would require far more test hours than any program can run. The practical alternative, familiar from ISO 26262 Part 6 and DO-178C, is to freeze the software, test it for a feasible duration within the operational design domain (ODD), and build confidence through evidence such as requirements traceability, code coverage and static analysis. He noted that the figures on his slides were illustrative, meant to show the order of magnitude rather than real targets. ## The water filter analogy To show how assurance activities relate to one another, he used water treatment as an analogy. Purification is a series of filters, each with its own purpose and some overlap. Adding filters costs money and reduces yield. Skip one and you still get water, just with more impurities. And different regions set different limits. Software assurance works the same way. Every activity costs engineering time and slows delivery. Skipping one still produces working software, only with a higher chance that errors get through. Safety integrity levels decide how much is required. The goal isn’t zero errors. It’s matching the amount of assurance to the risk. ## Where current standards fall short He walked through the standards the industry already relies on: ISO 26262 (automotive), DO-178C (aerospace), IEC 61508 (industrial) and EN 50128 (rail), plus newer AV-specific ones such as ISO 21448 (SOTIF), UL 4600 and ISO/PAS 8800 for AI. A common pattern is that higher integrity levels require more structural code coverage, stricter coding rules and tighter traceability from requirements to code. The limits he pointed out: these standards are built around checklists and qualitative rigor, not numbers you can calculate. None of them anticipated machine learning components or software that ships weekly instead of once per model year. And behavior that depends on the ODD isn’t well captured by one fixed integrity level. In short, they tell you whether you followed the practices, not how much safer the result is. ## A four-pillar framework - **In-house software:** usually the largest effort, often more than the other three pillars combined. It needs a complete artifact chain from requirements through design, implementation, verification and traceability, with rigor scaled to each component’s integrity level. He recommended starting early because the volume of artifacts is large and feeds the other pillars. - **Third-party dependencies:** assess their safety impact, then qualify or replace components whose source you don’t control. - **Development and test tooling:** establish confidence in compilers, build systems and test frameworks, and qualify any tool that could hide an error. - **Software interfaces:** document every message field, its producer and consumer, and trace it back to a requirement. ## From checklist to number The method he presented runs in six steps: 1. Score each component. Weight every applicable best practice by its assurance benefit, score how well it was satisfied, and calculate a weighted satisfaction ratio. 2. Map that ratio to a predicted base failure rate using a defined model. 3. Adjust for component characteristics such as code size, the share of safety-relevant code, and diagnostic coverage. 4. Combine the failure rate with exposure to specific operating scenarios within the ODD. 5. Roll the scenario-level estimates up into an expected incident rate for the component. 6. Compare it with a target. The gap becomes the basis for a deployment decision. The result supports concrete decisions: approve a component, restrict the operational domain, or trigger a software update. He stressed that the example scores and weights on his slides were illustrative and not Zoox data, and that no estimate is perfect. The value is having a consistent, data-driven basis for decisions under uncertainty, one that makes risk visible, comparable and actionable. Zoox’s [Safety Case Framework](https://zoox.com/journal/safety-case-framework), published on August 12, 2026, is a public example of this approach. It combines structured hazard analysis (HARA, FMEA, FTA and STPA), an ISO 26262-based process for hardware and software, and quantitative risk assessment, with safety targets benchmarked against real-world human driving data. ## Practical lessons - **Start early.** The artifacts are numerous and hard to produce after the fact. - **Invest in tooling.** Automated coverage, traceability and reporting are what make this scale. - **Calibrate rigor to risk.** Not every component needs the same level of assurance. - **Treat it as a living process.** Standards and tooling both need to evolve along with the software. ## The Fixstars perspective The pillar that stood out most to us was tooling. In embedded AI, the toolchain between a trained model and the code that runs on the target keeps growing: graph compilers, quantization tools, vendor inference runtimes such as TensorRT, and hand-tuned kernels. Each of these can change numerical behavior. In the framework Somalraju described, they count as tools that could hide an error, so they need defined confidence levels and, where it matters, qualification evidence. In practice, that means optimization work has to produce evidence of its own: accuracy comparisons before and after quantization on data that reflects the ODD, layer-by-layer checks where outputs drift, versioned toolchains and reproducible builds. A speedup that can’t be traced and verified is hard to use in a safety argument. The same goes for third-party inference libraries, which fall under his second pillar. ## Conclusion The talk didn’t claim to make autonomous driving easy. Its argument was that turning qualitative best practices into a number gives teams a more consistent and defensible way to decide when software is ready, and where the next hour of assurance work will do the most good. ## FAQ ### Why can’t AV software safety be proven through testing alone? At the failure rates autonomous vehicles target, demonstrating a safety goal statistically would take far more test hours than any program can run. Standards such as ISO 26262 Part 6 and DO-178C instead combine a feasible test campaign on frozen software with a structured body of evidence, including requirements traceability, code coverage and static analysis. ### What are the four pillars of the software assurance framework presented by Zoox? In-house software, third-party dependencies, development and test tooling, and software interfaces. In-house software usually takes the most effort, often more than the other three combined. ### How can compliance with best practices be turned into a risk number? The method weights each applicable best practice by its assurance benefit, scores how well it was satisfied, maps the result to a base failure rate, adjusts for component characteristics such as code size and diagnostic coverage, combines it with scenario exposure in the operational design domain, and compares the resulting incident rate with a target. ### How does this apply to AI model optimization toolchains? Graph compilers, quantization tools and inference runtimes can change numerical behavior, so under this framework they count as tools that could hide an error. Teams need evidence such as before-and-after accuracy comparisons on representative data, versioned toolchains and reproducible builds. If your team is porting or optimizing AI models for embedded platforms and needs results you can verify, take a look at our [AI Model Porting & Optimization](https://www.fixstars.com/en/products-services/ai-model-optimization) service. Moving AI onto embedded or edge hardware? Fixstars engineers port and optimize AI models and embedded software for your target chips, including NVIDIA Jetson and DRIVE, Renesas R-Car, and Qualcomm Snapdragon. [Request a free assessment](https://www.fixstars.com/en/contact?type=embedded-software-development) #### Author ##### **Miho Yoneda** Marketing Lead at Fixstars Solutions