Nuro: Engineering Autonomous Delivery Vehicles Under FMVSS Exemption
How the only NHTSA-exempted autonomous vehicle company structures safety requirements when the rulebook doesn’t exist yet
In February 2020, NHTSA granted Nuro a temporary exemption from several Federal Motor Vehicle Safety Standards — specifically those requiring human controls such as steering wheels, pedals, and mirrors. The vehicle in question, the R2, was designed without any provision for a human occupant or driver. It was the first such exemption ever issued for a purpose-built autonomous vehicle in the United States.
That exemption sounds like a competitive advantage. In engineering terms, it functions more like a liability: Nuro agreed to demonstrate safety without being able to point to a standard and say “we comply.” They had to define what safety means for a vehicle class that didn’t exist, submit that reasoning to federal scrutiny, and build a verification program against criteria they largely wrote themselves.
This is an unusual position for an engineering organization. Most automotive safety work is interpretive — you read FMVSS, ISO 26262, and UN regulations, then demonstrate compliance through analysis and test. Nuro’s engineers had to do something harder: argue from first principles what a driverless, low-speed, goods-only vehicle should do when it encounters a child running into the street, a cyclist passing on the right, or an emergency vehicle with lights running. Then they had to prove they’d met those arguments.
The Engineering Organization Behind the Exemption
Nuro was founded in 2016 by Dave Ferguson and Jiajun Zhu, both former members of Google’s self-driving car project. The company’s engineering structure reflects its unusual product scope: unlike most autonomous vehicle programs, Nuro has never been building toward a robotaxi or freight hauler. The target was always a small, low-speed, sidewalk-adjacent delivery vehicle operating in residential and commercial zones.
This focus shapes how the organization is structured. Nuro runs a tightly integrated hardware-software development cycle, building the vehicle chassis, sensor suite, compute stack, and autonomy software in-house. The safety engineering function is not a compliance gate at the end of that pipeline — it is embedded across mechanical, electrical, and software subteams from the outset. This reflects an approach common in aerospace that remains rare in automotive: safety requirements are authored before design decisions are made, not after they are rationalized.
The safety case is the organizing artifact. Everything else — sensor placement, braking system redundancy, fail-operational versus fail-safe behavior, geofence logic — is traceable back to claims in that safety case. When those claims change, as they did substantially between the R1 prototype, the R2 production vehicle, and the subsequent third-generation platform, the requirements traceability network has to update accordingly.
That traceability burden is not trivial. It is, in many respects, the central engineering process challenge Nuro faces that traditional OEMs do not.
What It Means to Write Requirements for External Safety
Conventional automotive safety engineering is built on a specific threat model: protect the people inside the vehicle. Crumple zones, airbags, seatbelt pretensioners, head restraints, side-impact door beams — the entire FMVSS structure for crashworthiness assumes there is a human body inside the vehicle that needs to survive a collision.
Nuro’s R2 has no occupants. There is no one inside to protect.
This inverts the safety requirement hierarchy entirely. The primary protection obligation shifts to vulnerable road users (VRUs) — pedestrians, cyclists, and other drivers who might interact with or be struck by the vehicle. The engineering question becomes: what should this vehicle do, and what should it be constructed of, to minimize harm to people outside it?
This is not a theoretical reframing. It has direct consequences for materials selection, exterior geometry, energy-absorbing structure placement, and behavioral requirements for the autonomy system.
On the materials side, Nuro’s R2 used a lighter, more deformable outer structure than a conventional passenger car — partly to reduce impact energy transferred to a struck pedestrian, and partly because without occupant protection requirements, the vehicle could be designed thinner and lighter overall. The tradeoff is that the vehicle itself is more vulnerable to damage, which is operationally acceptable if it protects the person it hits.
On the behavioral side, this reorientation produces requirements that have no FMVSS equivalent. How should the vehicle respond when a child darts into its path from between parked cars? What is the maximum acceptable approach speed in a school zone? How does the vehicle communicate its intent to a pedestrian waiting to cross? These are not questions with regulatory answers. Nuro’s engineering teams had to write the requirements, justify them to NHTSA, and build verification tests for them — often simultaneously.
The NHTSA exemption petition itself, which runs to hundreds of pages of technical documentation, functions as a public version of this reasoning. It’s the closest thing to a regulatory record that exists for this vehicle class.
Requirements Evolution Across Vehicle Generations
Nuro has now operated through multiple development cycles: the R1 mule platform used for early testing, the NHTSA-exempt R2, and a third-generation vehicle developed as the operational envelope expanded. Each generation represents not just a hardware refresh but a requirements revision forced by operational learning.
The R1 was never intended for public roads. It was a sensor and software testbed that allowed the team to develop the autonomy stack and identify edge cases before committing to production tooling. Requirements at this stage were primarily functional — the vehicle needed to navigate predefined routes, recognize standard object classes, and stop for obstacles. The safety case was developmental.
The R2, which began public deliveries in Houston and Mountain View, operated under more stringent requirements because it operated around actual pedestrians and cyclists. Deployment revealed threat scenarios that desktop analysis had underweighted: delivery zones where residents hadn’t been notified of the vehicle’s presence, areas with high concentrations of children or elderly pedestrians, interactions with cyclists who behaved unpredictably around an unfamiliar vehicle type.
These observations fed directly back into requirements. Speed limits in residential zones were tightened below what the original design envelope specified. The detection and response requirements for occluded pedestrians — people partially hidden by parked vehicles or landscaping who might enter the vehicle’s path — were revised upward in stringency. The behavioral specifications for what the vehicle does when it cannot make forward progress (a blocked driveway, a double-parked truck) grew from a short list of simple stop-and-wait behaviors to a more nuanced set of rules governing wait time, repositioning logic, and remote assistance escalation.
This iterative tightening of requirements through deployment experience is normal in safety-critical engineering. What makes Nuro’s situation unusual is that there is no regulatory floor below which the requirements cannot drop. In conventional automotive engineering, FMVSS compliance is a minimum — you can exceed it but not fall below it. Nuro’s requirements are entirely self-imposed and NHTSA-negotiated. The company cannot look up the answer. It has to justify it.
The Traceability Problem at the Frontier of Regulation
When safety requirements are self-defined and subject to revision through operational learning, traceability infrastructure becomes load-bearing in a way it isn’t for standard compliance programs.
In a typical automotive tier-1 supplier context, a requirements engineer might trace a braking performance requirement to FMVSS 135, link it to a set of design specifications, and close the loop with a test report showing compliance. The requirement doesn’t change unless the regulation changes. The trace is relatively stable.
Nuro’s requirements do change — not arbitrarily, but systematically, as the safety case is updated to reflect new operational data, revised threat models, or evolving interpretations of what “safe” means for this vehicle class. When a top-level safety requirement is revised, every design specification, test case, and analysis artifact that traces to it needs to be reviewed for continued validity.
This kind of cascading impact analysis is where requirements management tooling either earns its keep or becomes a liability. Legacy document-based approaches — where requirements live in Word documents or static databases with manually maintained trace links — break down quickly when the requirement hierarchy is in flux. Finding what changed, what it affects, and what needs re-verification requires either heroic manual effort or tooling that models the requirement network as a live graph rather than a frozen document.
Modern graph-based requirements platforms, which represent requirements as nodes with typed relationships to design artifacts, test cases, and verification evidence, handle this significantly better. Tools like Flow Engineering, built specifically for hardware and systems engineering teams, are designed around exactly this pattern: requirements that change, traces that propagate, and verification status that reflects the current state of the requirement network rather than the state it was in at the last document release. For an organization like Nuro, where the top of the requirement hierarchy can shift based on a NHTSA negotiation or an operational incident, that kind of live traceability isn’t a nice-to-have — it’s structural.
What’s Actually Happening vs. the Hype
Nuro’s exemption generated significant coverage in 2020 framed around regulatory breakthrough and the dawn of autonomous delivery. Six years later, the picture is more measured.
Commercial deployment has proceeded but not scaled at the pace early projections suggested. Nuro paused its consumer delivery service in 2023 and restructured, refocusing on partnerships with logistics and last-mile delivery operators rather than direct consumer operations. The third-generation vehicle program continued development. The company remains funded and technically active, but the path from regulatory exemption to broad commercial deployment has proven harder than the 2020 narrative implied.
This is worth naming plainly because it affects how the engineering organization functions. A company in scale-up mode can invest in requirements tooling, process maturity, and safety case depth because those investments pay back through volume. A company in a more constrained operational posture has to make harder choices about where engineering discipline is enforced rigorously and where it is managed pragmatically.
What hasn’t changed is the fundamental engineering challenge. Whether Nuro’s vehicles are making ten deliveries a day or ten thousand, the question of what the safety requirements are for a driverless external-protection vehicle, and how compliance with those requirements is demonstrated, remains unanswered by any existing regulatory framework. Nuro continues to operate on a frontier that NHTSA is watching, taking notes from, and will eventually use to write the rules that come after.
Honest Assessment
Nuro occupies a position in autonomous vehicle engineering that has no real precedent: a production vehicle, on public roads, with federal regulatory approval, designed to protect everyone except its nonexistent occupants. The engineering discipline required to operate in that position — writing requirements without regulatory templates, verifying safety without standardized test procedures, and maintaining coherent traceability through multiple vehicle generations — is genuinely difficult and genuinely instructive.
The limits are real. Operating without regulatory standards means the safety case is perpetually provisional. Every deployment incident is potentially a requirements event. Commercial scale has proven elusive. The organizational restructuring of 2023 introduced uncertainty into a program that depends on long-term engineering continuity.
But the engineering record matters independent of commercial outcome. Nuro’s exemption petition and the multi-generation development program constitute the most detailed public record of how to structure safety requirements for a vehicle class that doesn’t fit existing frameworks. When NHTSA eventually writes standards for autonomous delivery vehicles — and it will — that record will be the primary empirical input.
That’s a form of industry contribution that doesn’t show up in delivery volume metrics. For engineering organizations working on adjacent problems — low-speed autonomous platforms, last-mile robotics, mixed-traffic systems — Nuro’s requirement engineering approach is the most complete case study available.
The rulebook for this vehicle class is still being written. Nuro is writing significant portions of it.