Nuro: The Systems Engineering Behind Autonomous Delivery Vehicles

Nuro occupies a genuinely unusual position in the autonomous vehicle landscape. The company does not build robotaxis. It does not retrofit existing passenger vehicles. It builds purpose-built, low-speed autonomous delivery pods—vehicles explicitly designed so that no human can ride inside them, not as a feature limitation but as a foundational engineering constraint.

That single design choice cascades into one of the more interesting systems engineering problems in the industry: how do you certify something that no existing standard was written for?

What Nuro Actually Builds

Nuro’s vehicles—publicly referred to across generations as R1, R2, and the third-generation platform—are small, electrically powered, enclosed cargo pods. At roughly half the width of a standard passenger car and limited to 25 mph in operational deployments, they are optimized for last-mile delivery in residential environments. Cargo bays replace passenger compartments. There is no driver seat, no steering wheel, no occupant restraint system.

The operational design domain is deliberately constrained: geo-fenced suburban streets, predetermined delivery routes, low-speed interactions with pedestrians and cyclists. This is not a vehicle trying to solve all of autonomous driving simultaneously. It is a vehicle trying to solve one specific problem—residential delivery—completely enough to operate without human supervision.

That focus shapes everything downstream, including the regulatory strategy, the sensor architecture, the safety case structure, and the requirements engineering process.

The Regulatory Gap: FMVSS Was Not Written for This

The Federal Motor Vehicle Safety Standards represent decades of accumulated requirements built around one central assumption: there is a human in the vehicle. FMVSS 208 governs occupant crash protection. FMVSS 201 covers interior impact. Seat belt requirements, airbag deployment thresholds, interior geometry constraints—a substantial fraction of the FMVSS corpus exists to protect people riding in the vehicle.

Nuro’s vehicles have no occupants. That makes strict FMVSS compliance both technically irrelevant for large sections of the standard and actively distorting for the engineering program. Designing an occupant restraint system into a vehicle that carries only cargo is not just unnecessary cost; it represents requirements derived from the wrong hazard model.

NHTSA recognized this problem and has an established mechanism for addressing it: the temporary exemption under 49 CFR Part 555. Manufacturers can petition for exemption from specific FMVSS requirements when complying would prevent the development of a technology that provides safety benefits equivalent to or greater than the standard achieves. The exemption is time-limited (up to three years, renewable) and scoped to a limited production volume.

Nuro received its first NHTSA exemption in 2020—the first ever granted for a fully driverless vehicle—covering specific provisions of FMVSS 500 (low-speed vehicles) and FMVSS 208. The exemption was not blanket permission to ignore safety. It was permission to argue a different safety case: that a vehicle carrying no human occupants, operating at low speed, with a full autonomous system providing continuous monitoring, achieves safety outcomes at least as good as the standards were designed to produce, through a different mechanism.

That distinction matters enormously for how Nuro’s systems engineering organization structures its work.

The Safety Case Without the Human Fallback

Conventional automotive safety engineering operates against a background assumption that is so pervasive it often goes unstated: there is a human driver who can notice unexpected situations, take manual control, and serve as the final layer of the safety architecture. ISO 26262’s functional safety framework, SOTIF (ISO 21448), and most OEM safety processes are built with this assumption embedded.

Nuro’s platform eliminates it entirely and does not replace it with a remote operator in the decision loop for normal operations. The autonomous system is the only active agent. There is no human fallback. The safety case must be closed without one.

This changes the structure of the safety argument in several ways.

Hazard analysis scope expands. For a conventional vehicle, hazard analysis focuses primarily on failures that produce outcomes the human driver cannot recover from in time. When there is no human driver, every hazard that the autonomous system might fail to detect, classify, or respond to appropriately must be analyzed and mitigated within the system itself. The fault tree grows substantially.

The sensor architecture carries the safety argument. Nuro’s vehicles deploy a dense array of cameras, radar, and lidar. In a human-driven vehicle, sensors are supplementary—they extend human perception. In Nuro’s vehicle, they are constitutive of the safety function. Sensor failure modes, coverage gaps, degraded-weather performance, and edge-case classification errors are not reliability concerns at the margins; they are primary safety concerns at the center of the hazard analysis.

Behavioral requirements must be complete. A human driver brings embodied world knowledge—intuitions about children chasing balls, cyclists wobbling, drivers backing out of driveways. An autonomous system has only what its requirements specify and its training data captures. The behavioral requirements for Nuro’s system must account for scenarios that a human driver would handle through general competence, not because they were specifically trained. Writing those requirements completely and verifiably is a non-trivial systems engineering problem.

The safety case document must stand alone. When Nuro files with NHTSA or responds to state DMV requirements, the safety case cannot reference “driver discretion” or “driver response” as a mitigation. Every residual risk must either be mitigated within the system or accepted through explicit argument. That places high demands on the traceability chain from top-level safety goals to individual system requirements to verification evidence.

Holding Two Standards Frameworks Simultaneously

Nuro’s systems engineering organization operates at the intersection of two distinct regulatory and standards frameworks that were developed independently and do not naturally align.

The first is vehicular safety: FMVSS, FMCSS, and the functional safety framework of ISO 26262, which addresses hardware and software failures in electrical and electronic systems. ISO 26262 provides rigorous methodology for Automotive Safety Integrity Levels (ASIL), fault analysis, and safety lifecycle management. It was written for systems in vehicles that have human operators, but its core analytical methods apply reasonably well to purpose-built autonomous platforms.

The second is autonomous system behavior: SOTIF (ISO 21448), which addresses hazards arising not from failures but from functional insufficiency—the system works as designed but the design is not sufficient for all situations it encounters. SOTIF is newer, less mature, and harder to apply rigorously. The boundary between “the system failed” (ISO 26262 territory) and “the system was never specified to handle this” (SOTIF territory) is genuinely difficult to define in practice.

For Nuro, both frameworks apply simultaneously, and they interact. A sensor that degrades in heavy rain may produce a classification error that looks like a SOTIF gap but is actually a hardware degradation covered by ISO 26262. A behavioral requirement that is underspecified creates a SOTIF exposure, but the underspecification may itself originate in the failure to fully analyze a hazard that should have been in the ISO 26262 scope.

Managing this intersection requires requirements tooling that can represent both types of requirements and the relationships between them—not just a document hierarchy, but a connected model where the derivation paths from safety goals to system requirements to component specifications to test evidence are visible and traceable.

Operational Design Domain as Requirements Boundary

One of Nuro’s most consequential systems engineering decisions is how it defines and enforces its Operational Design Domain. The ODD is the specification of conditions under which the autonomous system is designed to operate: geography, weather, time of day, road type, speed range, traffic conditions.

For Nuro, the ODD is not just a product limitation—it is a requirements boundary. Everything inside the ODD must be handled completely. Everything outside the ODD triggers a defined fallback (for Nuro’s platform, typically a safe stop in place, since there is no human to hand off to). The ODD definition is therefore a primary input to the behavioral requirements specification, and changes to the ODD propagate changes through a large portion of the requirements tree.

This creates an interesting dynamics for the requirements process. Expanding the ODD to new geographies or weather conditions is not a simple add-on. It requires new hazard analysis, new behavioral requirements, new verification evidence, and potentially new safety case arguments for NHTSA. The requirements management discipline around ODD changes is where the quality of Nuro’s systems engineering process is most directly tested.

Where the Toolchain Challenge Lives

Requirements management at this level of complexity—spanning vehicular safety standards, autonomous behavioral requirements, ODD boundary conditions, sensor architecture specifications, and regulatory compliance evidence—cannot be managed in documents. The traceability demands alone exceed what document-based tools can reliably support.

The connections that matter are not sequential (requirement → test case). They are graph-structured: a single top-level safety goal decomposes into multiple system requirements, each of which has relationships to hazards, design decisions, FMVSS exemption arguments, verification activities, and open issues. A change to the ODD definition may affect requirements across multiple subsystems simultaneously. A new edge case identified in field operations may need to be traced back to find which safety goal it challenges and whether existing requirements cover it.

Tools like IBM DOORS have the depth of traceability support but impose document-centric workflows and significant administrative overhead that slows the iteration pace autonomous system development requires. Jama Connect offers cleaner interfaces and better modern integration, but its underlying model is still primarily hierarchical rather than graph-based. Polarion and Codebeamer provide strong process control for regulated industries but were built around conventional software development lifecycles rather than the AI-enabled sensor systems at the core of autonomous vehicles.

This is the domain where AI-native tools designed specifically for systems engineering begin to show their relevance. Flow Engineering, for instance, is built around a connected graph model where relationships between requirements, hazards, design decisions, and verification evidence are first-class objects—not annotations appended to documents. For programs where a single change to an ODD boundary or a sensor degradation threshold needs to propagate visibly through the full requirements tree, that architectural difference matters operationally, not just aesthetically.

The broader point is not specific to any one tool: the requirements engineering process for a program like Nuro’s has structural properties—dense cross-references, bidirectional traceability, frequent AI-driven iteration—that favor modern, graph-aware toolchains over adapted document management systems.

Honest Assessment of Nuro’s Position

Nuro has done something genuinely difficult: it has navigated a novel regulatory pathway, built a purpose-built autonomous platform from scratch, and operated commercially in multiple states. The NHTSA exemption it secured in 2020 was a meaningful achievement that required a credible safety case, not just a regulatory petition.

At the same time, the company has faced the headwinds common to autonomous vehicle development: the gap between demonstration and scaled deployment is wide, the cost of safety case maintenance at scale is high, and the operational complexity of managing a growing fleet in diverse residential environments compounds over time.

The systems engineering problems Nuro faces are not solved by good organizational intention. They require rigorous hazard analysis, complete behavioral specification, disciplined ODD management, and traceability infrastructure that can support NHTSA filings, internal reviews, and continuous field-driven iteration simultaneously. Whether any AV company—Nuro included—has fully solved those problems at scale remains an open question.

What is clear is that Nuro’s engineering program represents the frontier case for automotive systems engineering methodology: a domain where every requirement must be derived from first principles, where no standard fully applies, and where the safety case must be argued from the system up rather than from the standard down. The lessons from that work—about hazard analysis without human fallback, about ODD as requirements boundary, about the limitations of document-based traceability—will eventually matter for the broader industry as autonomy penetrates more vehicle programs.

That makes Nuro’s approach worth understanding, regardless of how the company’s commercial trajectory develops.