Nuro and the Regulatory Frontier: Engineering Safety Cases Without a Map

A Vehicle Class That Did Not Exist

In February 2020, the National Highway Traffic Safety Administration granted Nuro a two-year exemption from several Federal Motor Vehicle Safety Standards for its R2 autonomous delivery pod. The exemption covered standards that assume a human occupant — crash protection, glazing requirements, rearview mirror rules. Nuro’s vehicle carries no people. The safety logic shifts entirely outward: protect the pedestrian, the cyclist, the driver of the car that just encountered a 2,000-pound robot in a school zone.

This was not a paperwork victory. It was the opening of an engineering obligation that has no complete playbook. Nuro had to construct a safety case for a vehicle category that FMVSS was never written to address, using functional safety and SOTIF frameworks that were built around human-occupied passenger cars, and present that argument convincingly to a federal regulator evaluating something it had never seen before.

The result is one of the most demanding systems engineering exercises in the autonomous vehicle industry — not because the hardware is exotic, but because the proof burden is almost entirely self-constructed.

What the Standards Actually Say (and Don’t Say)

ISO 26262 is the baseline automotive functional safety standard. It covers electrical and electronic systems in road vehicles and defines a rigorous process for hazard analysis, safety goal derivation, and verification at every stage of the development lifecycle. It is genuinely useful. It is also explicitly scoped to vehicles up to 3,500 kg gross vehicle mass, with a design philosophy rooted in occupant protection and driver-in-the-loop operation.

ISO 21448 — SOTIF, Safety of the Intended Functionality — extends the safety conversation to hazards arising from functional insufficiencies: sensors that can’t see well enough, perception algorithms that fail on edge cases, situations where the system does exactly what it was designed to do and still produces a dangerous outcome. SOTIF is closer to Nuro’s core problem, but it was drafted with assisted-driving systems in mind, not fully driverless platforms in uncontrolled urban environments.

UL 4600 provides a standard for evaluating the safety of autonomous products and is one of the few frameworks that directly addresses driverless systems. It requires a complete safety case document with explicit arguments, evidence, and traceability — a structure Nuro has had to build out in detail.

The gap between these frameworks and Nuro’s operational reality is significant. A conventional ADAS program applies 26262 with well-worn processes: decompose the vehicle into subsystems, assign Automotive Safety Integrity Levels, run fault tree analysis, close out each safety goal with test evidence. A driverless pod operating mixed-traffic residential streets, interacting with pedestrians who may not understand what they’re looking at, carrying food instead of a family — the hazard space is different in kind, not just degree.

Nuro cannot lean on industry precedent for how to handle a child running toward a stationary R2 on a sidewalk. It has to define the operational design domain precisely enough that the regulator can evaluate whether the ODD is reasonable, build a behavioral competency argument from scratch, and tie every edge-case scenario back to testable requirements.

Building a Safety Argument Without Occupant Protection as Anchor

Conventional automotive safety cases have a useful organizing principle: protect the occupants. Secondary pedestrian protection considerations exist, but the primary safety obligation gives the argument structure. Remove the occupant and that anchor disappears.

Nuro’s safety case has to be organized around a different principle: minimize harm to all road users in every scenario the vehicle might encounter, across an ODD that includes schools, crosswalks, intersections without signals, and the general unpredictability of residential neighborhoods.

This requires starting from hazard analysis and risk assessment at a level that does not inherit much from prior programs. The team has to define what constitutes an unacceptable outcome for a pedestrian struck at various speeds by a vehicle designed with a crumple zone optimized for the absent occupant. They have to characterize sensor performance degradation in rain, glare, and occlusion scenarios — not against a regulatory test procedure, but against a self-defined acceptable detection envelope that must be defensible in regulatory dialogue.

SOTIF’s framework for unknown unsafe scenarios becomes particularly demanding in this context. SOTIF distinguishes between scenarios the team knows about and has addressed, scenarios that are known but unresolved, and scenarios that are entirely unknown. For a vehicle type without operational history in large-scale deployment, the unknown-unknown space is large. Nuro’s engineering process has to include explicit mechanisms for discovering what it doesn’t know — through simulation, closed-course testing, limited public road operation, and systematic review of safety-critical edge cases from analogous vehicle types.

Every one of those mechanisms has to be documented in a way that survives external scrutiny. This is not engineering documentation in the ordinary sense. This is evidence in an ongoing regulatory proceeding.

The Infrastructure Problem: Traceability at Regulatory Scale

There is an engineering challenge inside the safety challenge that often goes undiscussed: how to maintain coherent traceability across a requirements architecture that is evolving in real time, covers multiple hardware generations and software stacks, and has to be auditable by external parties who were not present for the engineering decisions.

Nuro operates in a domain where the requirements and their rationale are not just internal engineering artifacts — they are the primary output the company presents to NHTSA, state regulators, and in some cases the public. A requirement that changes has to carry its change history, its upstream safety goal linkage, and its downstream verification evidence with it. If a sensor specification is updated after new fog-condition test data comes in, that change has to propagate legibly to every safety argument that depends on it, and the team has to be able to demonstrate that propagation to a regulator who is asking hard questions about software version 7.2.1 while the engineering team is already on 9.0.

This is where requirements management stops being a process preference and becomes a technical dependency. Manual traceability management — requirements in spreadsheets, safety goals in documents, test evidence in a separate database — breaks down under this load. The connections between artifacts become stale. Engineers leave and take with them the institutional knowledge of why a particular requirement was written the way it was. Regulatory review timelines stretch to years, and the team that prepared the original submission may not be the team defending it.

Nuro has invested in requirements and traceability infrastructure commensurate with this challenge. The company uses Flow Engineering to manage the connected requirements, safety goals, and traceability that underpin its safety case work. For a program operating in regulatory white space — where the engineering team is effectively writing its own standard and then proving it meets that standard — having requirements modeled as a connected graph rather than as disconnected documents is not a productivity improvement. It is what makes the safety argument coherent and auditable over time. When a safety goal changes, the downstream requirement impacts are visible immediately. When a regulator asks what evidence closes out a particular hazard, the answer can be navigated rather than assembled by hand from multiple repositories.

This kind of infrastructure also matters for the argument structure itself. UL 4600 explicitly requires a safety case with goal-argument-evidence structure. That structure maps directly onto connected, traceable requirements — the safety goal at the top, the sub-arguments that decompose it, the evidence that closes each branch. A tool that models requirements as nodes in a graph, with explicit typed relationships between them, produces the artifact shape that a structured safety case demands.

What Nuro Has Had to Build From Scratch

The engineering teams at Nuro have not simply applied existing safety engineering processes to a new vehicle. They have had to construct several things that did not exist before their program required them:

An ODD specification method for residential delivery. The operational design domain for a residential delivery robot is not well-characterized by prior automotive or robotics standards. Nuro has had to define how to specify the ODD precisely enough that system behavior at ODD boundaries can be evaluated and tested.

Pedestrian interaction behavioral norms. Conventional AV programs have the benefit of traffic codes as a behavioral reference. Pedestrian behavior near a robot with no visible driver requires explicit modeling of interaction scenarios, including non-compliant or unexpected behavior from people who have never seen the vehicle type before.

External appearance safety contributions. The R2’s physical design — softer outer surfaces, a lower nose profile, the absence of a conventional front-end structure — is itself a safety argument. Translating physical design choices into safety case evidence requires a framework that does not exist in standard FMVSS or ISO 26262 guidance.

Regulatory communication architecture. NHTSA exemption applications are engineering arguments presented to a non-engineering audience with enforcement authority. Writing those arguments requires translating complex system safety reasoning into accessible, auditable prose without losing technical precision — a genre of document that AV teams are still learning to produce well.

The Broader Pattern

Nuro’s situation is unusual in degree but not unique in kind. Every AV program that operates at scale eventually encounters the boundary of what existing standards cover. Programs deploying Level 4 trucks, urban robotaxis, or low-speed campus shuttles all face versions of the same problem: the standards were written for something slightly different, and the gap is the team’s responsibility to characterize and close.

What makes Nuro’s case instructive is how visible the gap is. The FMVSS exemption is a public acknowledgment that the existing regulatory framework does not apply as written. That visibility forces the engineering discipline that every novel AV program needs but that some avoid until a regulatory event forces it.

The lesson is not specific to delivery robots. Any engineering team operating at the edge of an existing standard — in aerospace, defense electronics, medical devices — faces a version of the same obligation: construct a rigorous safety argument, maintain traceable evidence that supports it, and keep that argument coherent as the program evolves over years and across team changes.

That is a systems engineering problem. The teams that handle it well treat requirements, safety goals, and evidence as a connected, maintained artifact — not as documentation produced after the engineering is done.

Nuro built one of the most demanding safety cases in the AV industry not because it had the best standards to work from. It did it largely without them.