Nuro: The Systems Engineering Story Behind Building an Autonomous Delivery Vehicle from Zero
There are roughly two ways to build an autonomous vehicle. The first is to take an existing vehicle platform — a Pacifica, a Jaguar I-PACE, a Lexus RX — and layer autonomy hardware and software onto it. The second is to start from a blank sheet and design the vehicle around the autonomy system, not the other way around.
Nuro chose the second path. Their R2 and subsequent platforms are purpose-built, occupant-free autonomous delivery robots intended for public roads at low speed. That design decision sounds clean in a press release. In practice, it created a systems engineering challenge with almost no precedent in the automotive industry: how do you certify, validate, and operate a motor vehicle when the entity the entire regulatory framework exists to protect — the human occupant — is not present?
The answer involves custom FMVSS exemptions, a reinterpretation of SOTIF from first principles, a sensor architecture designed for dense urban environments rather than highway edge cases, and a requirements management challenge that spans hardware, firmware, behavior stack, and operational constraints simultaneously. This is an analysis of how Nuro approached each of those problems, and what the industry can learn from watching a company build a new category of vehicle in real time.
The FMVSS Problem: A Safety Framework Built for Occupants
Federal Motor Vehicle Safety Standards were written with one consistent assumption: there is a human being inside the vehicle who may be killed or injured in a crash. Virtually every standard in the FMVSS corpus flows from that premise. FMVSS 208 governs occupant crash protection. FMVSS 214 covers side door strength to protect people seated adjacent to a door. FMVSS 138 requires tire pressure monitoring systems so a driver can take corrective action. The logic is consistent and, for a conventional vehicle, sensible.
Nuro’s vehicle has no occupants. The protective structures FMVSS 208 requires exist to keep a human body alive in a frontal collision. They are not necessary in a vehicle with no human body. More importantly, they add mass, and mass in a low-speed urban vehicle represents a different kind of safety tradeoff: a heavier Nuro vehicle striking a pedestrian is more dangerous than a lighter one.
This inversion — where regulatory compliance would actually make the vehicle less safe by the relevant metric — is not a gap in FMVSS. It is a consequence of applying a human-occupant framework to a non-occupant vehicle. Nuro pursued FMVSS exemptions with NHTSA explicitly on this basis, arguing that the purpose of the safety standards is to reduce harm, and that deviating from specific requirements achieves that purpose more effectively for a vehicle of this type.
The systems engineering implication is substantial. An exemption petition is not simply a legal document. It is, functionally, a requirements document. Every exemption Nuro receives is bounded by conditions: operational speed limits, geofencing requirements, sensor coverage specifications, and reporting obligations. Those conditions become constraints that propagate throughout the vehicle’s requirements hierarchy. A speed limit baked into an exemption petition becomes a functional requirement on the drive-by-wire system, a test requirement in the validation suite, a parameter in the operational design domain definition, and a monitoring requirement on the fleet management stack. The exemption is the top-level requirement. Everything below it must trace to it.
Managing that traceability across disciplines — mechanical, electrical, software, regulatory — is exactly the kind of cross-domain linkage that breaks down in document-centric requirements management environments. When the governing constraint lives in a PDF filed with a federal agency, and the implementation lives in firmware developed by a different team on a different toolchain, the connections between them require explicit, maintained traceability — not assumptions of organizational memory.
SOTIF in a World Without a Driver
ISO 21448, Safety of the Intended Functionality, was developed to address a class of hazards that ISO 26262 does not cover: failures that occur not because a system malfunctions, but because the system performs exactly as designed in a situation the design did not anticipate. SOTIF is particularly relevant to perception and prediction systems, which can produce confident, hardware-correct outputs that are nonetheless wrong about the world.
SOTIF’s framework assumes a driver. Its residual risk allocation relies on the assumption that a sufficiently attentive human operator can detect and respond to a situation the automation system has misjudged. The known safe behavior in many SOTIF scenarios is driver takeover. For Nuro, there is no driver to take over. The vehicle must either handle the situation autonomously or achieve a safe state through its own intervention — pulling to the side of the road, stopping in place, or issuing a remote assistance request.
This forces a more conservative interpretation of SOTIF’s “known unsafe scenarios” category. In a conventional ADAS application, a scenario that a human driver would recognize and respond to appropriately can be allocated to the driver as a residual risk. Nuro cannot make that allocation. Every scenario the perception and prediction stack cannot handle must either be eliminated from the operational design domain or resolved by an onboard safe-stop capability.
The practical consequence is that Nuro’s ODD definition — the geographic, environmental, and situational envelope within which the vehicle is permitted to operate — becomes a primary safety mechanism, not a commercial boundary. The ODD is where SOTIF’s “known unsafe scenarios” get addressed. If the vehicle cannot safely navigate a scenario, the scenario is excluded from the ODD. That exclusion must then propagate back through requirements: the behavior stack must detect when the vehicle is approaching ODD boundaries, the geofencing system must enforce geographic constraints, and the operations team must understand what environmental conditions trigger ODD exits.
The ODD, in other words, is simultaneously a safety argument, a regulatory commitment, and a system requirements document. Every boundary it draws creates downstream requirements. And those boundaries are not static — they evolve as validation data accumulates, as exemption conditions are updated, and as the software stack’s demonstrated capability envelope expands. Requirements management for a system like this is not a one-time activity. It is a continuous, multi-domain change management process.
Sensor Architecture for the Low-Speed Urban Problem
Most public discourse about autonomous vehicle sensor suites focuses on highway or suburban arterial scenarios: long sight lines, well-marked lanes, predictable road users. Nuro’s operating environment is different. Low-speed urban delivery routes mean dense pedestrian traffic, narrow streets, frequent stops, driveways, delivery zones, and road users who do not behave predictably because they do not expect an autonomous vehicle to be present.
The sensor requirements for this environment are not simply a scaled-down version of highway AV requirements. They are qualitatively different. Close-range detection matters more than long-range detection. The ability to classify a child crouching near a curb at three meters matters more than detecting a vehicle at 200 meters. Robustness to occlusion from parked delivery trucks, street furniture, and dense pedestrian crowds matters more than robustness to low-sun highway glare.
Nuro’s sensor suite on the R2 — which achieved NHTSA exemption — included a combination of cameras, radar, and lidar arranged for 360-degree coverage with overlapping fields of view. The redundancy architecture is not simply about hardware failure. It is about ensuring that no single occlusion scenario can simultaneously blind all sensing modalities covering the same spatial sector. Two sensors failing independently is a hardware reliability problem. Two sensors being simultaneously blocked by a double-parked truck is an ODD design problem. The architecture has to address both.
From a requirements standpoint, this creates a sensor coverage specification that is inherently spatial — it must be expressed in terms of angular coverage, detection probability at specified ranges, and degraded-mode behavior, not just component-level specifications. A requirement that says “the vehicle shall include lidar” is not a safety requirement. A requirement that says “the vehicle shall maintain greater than 0.95 detection probability for a 0.3m target at all azimuths within 15m under rainfall up to 50mm/hour” is a safety requirement. The difference between those two formulations represents a significant portion of Nuro’s systems engineering workload.
Those spatial, probabilistic sensor requirements must then trace bidirectionally: downward to component specifications, sensor placement constraints, and software processing requirements; upward to the safety case, the SOTIF analysis, and the FMVSS exemption conditions. Any change in sensor hardware — a new lidar generation, a camera with different sensitivity characteristics — requires re-verification of the coverage requirements and re-evaluation of every artifact that traced to them.
The Requirements Management Challenge Across Domains
What makes Nuro’s systems engineering challenge structurally distinct from a conventional automotive program is the degree to which requirements from different domains are functionally interdependent rather than merely hierarchically related.
In a conventional vehicle program, the regulatory requirements, chassis requirements, powertrain requirements, and ADAS requirements are largely separable. A change in powertrain architecture does not typically invalidate a roof crush strength requirement. The domains have interfaces, but the interfaces are relatively well-defined and stable.
In Nuro’s vehicle, the domains are tightly coupled in both directions. The vehicle’s speed capability is a mechanical parameter, a safety architecture parameter, a regulatory compliance parameter, and an ODD boundary parameter simultaneously. A change in the drive-by-wire speed limiter does not just affect the powertrain requirements — it potentially affects the FMVSS exemption conditions, the SOTIF residual risk allocation, the sensor detection range requirements, and the ODD definition. Every change is potentially a multi-domain change.
Managing requirements under those coupling conditions requires a model that makes interdependencies explicit and traversable. When an engineer changes a speed parameter, the requirements management system should surface every downstream requirement that cites that parameter — not because a human thought to link them, but because the model captures the actual dependency structure of the system.
This is the environment in which graph-based, model-connected requirements management tools have a structural advantage over document-based approaches. A requirements document can record that a speed limit exists. It cannot easily answer the question: if this speed limit changes, what else changes? Tools like Flow Engineering, which represent requirements as nodes in a connected graph with typed relationships, make that traversal explicit. A change to a top-level constraint propagates visibly through the connected network of derived requirements, revealing impact scope before implementation begins rather than after integration fails.
Nuro has not published its internal requirements toolchain, and this analysis does not presume to describe it. The point is architectural: the nature of their systems engineering challenge — tightly coupled, multi-domain, continuously evolving, with regulatory artifacts as top-level requirements — is precisely the environment in which document-centric management breaks down and model-connected approaches earn their overhead.
What the Industry Can Learn from Nuro’s Approach
Nuro is a small company by automotive standards, operating without the supplier infrastructure, regulatory track record, or institutional knowledge that established OEMs bring to a vehicle program. What they have is a clearly defined envelope and a disciplined approach to proving they stay inside it.
That alignment between regulatory strategy and systems engineering strategy is instructive. The FMVSS exemption process forced Nuro to define, in writing, filed with a federal agency, exactly what their vehicle does and does not do. That precision — uncomfortable and constraining — is also the foundation of a tractable verification and validation program. You can validate a system against a precisely defined ODD. You cannot validate a system against “it works in most cases.”
The absence of a human occupant forced a more honest safety argument. There is no driver fallback to absorb residual risk. Every unhandled scenario is either excluded from operation or addressed in the system. That discipline, imposed by the design choice, produces a safety case that is more complete — and more verifiable — than one that relies on human intervention as a catch-all.
The sensor architecture challenge — specifying coverage in probabilistic, spatial terms rather than component terms — represents a maturity in how AV requirements are written that the broader industry is still developing. Requirements at the right level of abstraction, traceable to the safety case, are a prerequisite for validation that actually closes.
None of this is simple. Nuro has faced commercial headwinds, program restructurings, and the ordinary brutality of building new technology categories in a market that does not yet fully exist. But the systems engineering approach embedded in their work — define the envelope precisely, make dependencies explicit, let the regulatory commitment drive the requirements — is replicable. And as low-speed autonomous systems scale from delivery robots to logistics platforms to campus vehicles, the engineering patterns Nuro developed will matter more, not less.