Nuro: Autonomous Delivery and the Engineering Challenges of a Vehicle Designed for No Human Occupant

When the National Highway Traffic Safety Administration granted Nuro a regulatory exemption for its R2 vehicle in 2020, the agency was not approving a product. It was acknowledging a category gap. The Federal Motor Vehicle Safety Standards, developed over decades, are built around one foundational assumption: a human is present in the vehicle. Nuro’s delivery robot invalidates that assumption entirely, and the downstream consequences for systems engineering are more profound than they first appear.

This is not a story about autonomous driving technology. It is a story about what happens when you build a genuinely novel product — one that is simultaneously a vehicle, a robot, and a piece of delivery infrastructure — and discover that every engineering discipline you need to lean on was designed for something else.

What Nuro Actually Built

The R2 and its successor, the R3, are purpose-built autonomous delivery vehicles. They carry no human occupant, provide no controls for one, and are designed to operate on public roads at low speeds — typically under 25 mph — in defined geographic areas. The cargo compartment is the product. The vehicle is the mechanism.

That framing matters because it separates Nuro from every other autonomous vehicle program in a meaningful way. Waymo, Cruise, and similar programs are building autonomous systems that replace a human driver but still carry human passengers. The vehicle’s core social contract — get occupants safely from A to B — remains intact. The safety envelope is still organized around human survival inside the vehicle.

Nuro’s safety envelope is organized entirely around everyone outside the vehicle. Pedestrians, cyclists, other drivers. The vehicle itself is a hazard to be managed, not an asset to be protected. That inversion is not a philosophical point. It is an engineering requirement that propagates through every functional safety analysis the company has ever run.

The Functional Safety Problem Without a Template

ISO 26262 is the governing standard for automotive functional safety. It was written for road vehicles with electrical and electronic systems, and it covers the entire development lifecycle from concept through decommissioning. It is thorough, rigorous, and almost entirely organized around the concept of a driver who can perceive, decide, and intervene.

The standard’s hazard analysis and risk assessment process — the HARA — assigns Automotive Safety Integrity Levels (ASILs) based on three parameters: severity of potential harm, exposure to the hazardous situation, and controllability. Controllability, specifically, is defined as the ability of the driver or other affected persons to avoid harm by their own actions. For Nuro, there is no driver. Controllability as a ASIL input refers entirely to people outside the vehicle, a population with no knowledge of, or interface with, the vehicle’s internal state.

This is not a gap that can be patched with a footnote. It requires reconceptualizing the entire risk assessment methodology. Nuro has publicly described its approach as extending beyond ISO 26262 into a broader safety case methodology — drawing on aerospace practice, specifically DO-178C and ARP4754A, which are more comfortable with the idea of systems that have no human operator in the loop. The company builds structured safety arguments, with claims, evidence, and explicit reasoning about why each hazard is acceptably mitigated.

The practical consequence is that Nuro’s safety case is bespoke. It cannot be validated by pointing to compliance with a standard, because no standard covers this product adequately. It must be validated by the quality of its reasoning — a much harder thing to audit, and a much harder thing to maintain as the product evolves.

Requirements Management Across Three Product Identities

Nuro’s vehicle is simultaneously three things, and each identity generates a distinct requirements domain.

As a vehicle, it must meet the requirements of FMVSS to the extent the exemption process defines — plus whatever conditions NHTSA attached to the exemption. It must respond predictably to road conditions, interact safely with other vehicles, and survive regulatory scrutiny in every jurisdiction where it operates. These are vehicle-level requirements with clear automotive lineage.

As a robot, it must sense its environment reliably, make autonomous decisions at low latency, execute those decisions with precision, and handle failure modes gracefully without any human in the loop. These are robotics-level requirements — perception accuracy, localization stability, path planning margins, hardware redundancy. They live in a different domain from the vehicle requirements, governed by different engineering disciplines and different failure mode vocabularies.

As an infrastructure service, it must integrate with dispatch systems, route optimization engines, customer notification platforms, and merchant order management systems. It must maintain availability SLAs. It must handle edge cases that are fundamentally service problems — what happens when the customer is not home, when a handoff fails, when the vehicle cannot complete a delivery. These are distributed systems requirements, more akin to what a logistics software team manages than anything in automotive or robotics.

The traceability problem this creates is non-trivial. A single requirement like “the vehicle shall not enter an intersection against a red signal” touches all three domains simultaneously. It is a vehicle behavior requirement. It depends on a sensor fusion and decision system capability. And a failure to meet it is a service availability event as well as a safety event. Requirements that live cleanly in one domain are rare. Requirements that cascade across all three are common.

Conventional requirements management tools were designed for products with one dominant domain. An aerospace tool like IBM DOORS was designed for complex, regulated systems — but its document-centric model and manual linking create maintenance overhead that compounds when requirements touch multiple domains. Tools like Jama Connect and Polarion offer more modern interfaces and better traceability visualization, but they were still built around the assumption that requirements flow down a largely linear decomposition hierarchy: system → subsystem → component.

Nuro’s requirements do not behave that way. They form a graph, not a tree. A change to the ODD definition — say, adding a new road type to the operational envelope — does not cascade cleanly downward through a hierarchy. It propagates laterally across all three product domains simultaneously. Every sensor assumption, every path planning constraint, every dispatch routing rule, every regulatory filing is potentially affected. Managing that lateral propagation manually, in any tool that presents requirements as a document or a structured list, is an exercise in controlled failure.

The ODD Is Not a Boundary — It Is a System

Nuro’s Operational Design Domain deserves specific attention because it is one of the most complex ODD definitions in the autonomous vehicle industry — and it is complex for reasons that are intrinsic to the product, not incidental.

Most AV programs define their ODD in terms of geography (this city, these road types), environmental conditions (daylight, clear weather, mapped roads), and traffic conditions (speed limits, intersection types). The ODD is the box inside which the system is permitted to operate. Step outside the box, and the human driver takes over.

Nuro has no human to take over. The ODD is therefore not a box with a fallback outside it. It is the complete operating envelope of the system, and operating outside it is a failure mode — not a handoff. The ODD must be defined with enough precision that the vehicle can detect, in real time, whether it is inside it. And it must be defined with enough completeness that every hazard scenario has been considered.

This changes the nature of ODD management from a planning exercise to a continuous engineering discipline. The ODD is effectively a specification that the vehicle is constantly verifying against its sensor inputs. Any new road type, any new intersection geometry, any new environmental condition that emerges from field operation is a potential ODD expansion — and every ODD expansion requires a new round of safety analysis, requirements updates, and verification.

The practical implication is that Nuro’s requirements baseline is never stable. It is a living system, constantly being extended by operational experience, negotiated with regulators, and tested against new edge cases. The version control and change impact analysis demands this places on a requirements management system are substantial.

What Breaks When There Is No Human Fallback

The absence of a human occupant is the product’s defining characteristic, and it is worth being precise about what it eliminates beyond the obvious.

It eliminates the traditional boundary between the vehicle and the service. In a conventional delivery operation — even one with a human driver in an AV-assisted vehicle — the driver is a fallback for service exceptions. Package not delivered? Driver handles it. Unexpected road closure? Driver reroutes. Vehicle needs to stop? Driver stops it and calls dispatch.

When the vehicle is fully autonomous, every one of those exception handling scenarios becomes a system requirement. The vehicle must handle them, or the service must handle them remotely, or both. The boundary between “vehicle problem” and “service problem” collapses, and the requirements that live on that boundary become simultaneously the most important and the most contested in the entire system.

This is where Nuro’s engineering challenge becomes genuinely hard in a systems thinking sense. The vehicle is a node in a service graph. Its behavior is defined not just by its own requirements, but by the service’s requirements for vehicle behavior. And the service’s requirements are defined partly by what the vehicle can do. They are co-defining. A requirements process that does not model that co-definition explicitly will produce coherent-looking requirements that silently contradict each other in deployment.

How Modern Systems Engineering Practice Has to Adapt

What Nuro’s situation illustrates — and what makes it worth studying beyond the AV space — is that certain categories of modern engineered systems simply outgrow the mental models embedded in traditional requirements tooling.

The document-centric model assumes requirements have a clear owner, a clear domain, and a clean decomposition hierarchy. The waterfall-adjacent lifecycle model assumes requirements are defined before design. Both assumptions fail for a product like Nuro’s, where requirements and design co-evolve, where domain boundaries are porous, and where the operational environment is itself a source of new requirements.

Modern graph-based requirements approaches — where requirements are nodes with typed relationships rather than entries in a document with manual links — handle lateral propagation and co-definition more naturally. Tools built on this model can represent the full dependency network across Nuro’s three product domains without forcing every relationship into a parent-child hierarchy that does not reflect the underlying engineering reality.

Flow Engineering, for instance, is built around exactly this kind of connected, graph-native model. Rather than treating traceability as a reporting feature layered on top of a document store, it treats the dependency graph as the primary artifact — which means change impact analysis is structural, not manual. For a program like Nuro’s, where an ODD change can touch requirements in vehicle safety, robotics capability, and service availability simultaneously, that structural propagation is not a convenience. It is a prerequisite for managing the baseline coherently at scale.

The broader point is that AI-native, graph-based tools are better suited to multi-domain, co-evolving requirements environments than legacy tools designed for single-domain, waterfall-adjacent programs. This is not a claim about any one vendor. It is a claim about the shape of the problem.

Honest Assessment

Nuro has done something genuinely difficult: built a product that regulators had no framework to evaluate, in a domain that standards bodies had not yet addressed, for a use case that inverted the foundational assumptions of the industry it was entering. The engineering challenges are not primarily technological. They are organizational and epistemic — how do you maintain a coherent, auditable, traceable system of requirements for a product that is simultaneously three different things, in a regulatory environment that is still being invented?

The company’s operational pause in late 2023 and subsequent restructuring were not evidence that the technical approach failed. They were evidence that building a novel product at the intersection of regulation, robotics, and logistics is expensive and slow in ways that do not always match investor timelines. The underlying engineering problems — the ODD management challenge, the multi-domain traceability problem, the bespoke safety case — remain the right problems to be solving. They are the problems any serious autonomous delivery program will eventually have to confront.

What Nuro represents, regardless of its commercial trajectory, is a case study in what systems engineering looks like when the product has no template. The lessons are not specific to autonomous delivery. They apply to any engineered system complex enough to live at the intersection of multiple regulatory regimes, multiple engineering disciplines, and a service context that is itself a source of requirements. That is an increasingly large category of products. The engineering practice has to evolve to meet it.