Nuro and the Systems Engineering of Last-Mile Autonomy
Why purpose-built delivery robots solve some requirements problems and create entirely new ones
When Nuro received its first NHTSA exemption in 2020 — the first ever granted to a purpose-built autonomous vehicle without a human occupant — it was widely covered as a regulatory milestone. Less discussed was what that exemption actually required Nuro to demonstrate: that a vehicle with no steering wheel, no pedals, no driver’s seat, and no side mirrors could be shown to pose no greater overall risk to public safety than the conventional vehicles it replaced. That is a fundamentally different engineering argument than the one highway AV programs make. And constructing that argument, then maintaining it across software updates, hardware revisions, and expanding operational domains, is the systems engineering challenge that defines Nuro’s engineering organization.
This profile examines how Nuro approaches that challenge across four intersecting domains: operational design domain management, safety architecture, hardware-software co-design, and regulatory engagement. These are not separate workstreams at a company like Nuro. They are tightly coupled, and understanding where they couple — and where coupling creates fragility — is where the interesting engineering work lives.
The ODD Problem at Low Speed
Autonomous vehicle programs are often described by their speed regime, and the assumption baked into that framing is that low speed means low complexity. Nuro operates its R-series vehicles at speeds typically below 25 mph, which places them in the low-speed vehicle (LSV) category under federal motor vehicle safety standards. That speed ceiling is real. The complexity it implies is not.
Highway autonomy programs operate in environments that are, by design, structured. Lane markings are standardized. Signage is consistent. Pedestrian interaction is minimal and physically separated. The variability is high-speed and the consequences of errors are severe, but the state space the autonomy stack must handle is comparatively bounded.
Urban last-mile environments are different. The interaction surface includes cyclists cutting across unmarked intersections, pedestrians who interpret a small, slow-moving robot as an obstacle rather than a vehicle, delivery zones that change by time of day, residential streets with no formal lane geometry, and edge cases generated by the sheer density of human activity at the sidewalk level. The vehicle’s low speed reduces kinetic energy in collision scenarios, which is a genuine safety benefit. It does not reduce the complexity of perception, prediction, and planning. In some respects, it increases it — a vehicle that moves slowly enough for a pedestrian to approach and interact with is a vehicle that must model deliberate human engagement, not just passive avoidance.
Nuro’s ODD management therefore requires something closer to high-resolution urban mapping and continuous domain monitoring than the geofenced highway corridors that characterize many AV programs. An ODD for Nuro is not defined by a city boundary or a zip code. It is defined street by street, with formal representations of road geometry, permitted maneuvers, known infrastructure conditions, and temporal constraints like school hours or permitted delivery windows. Changes to that domain — a construction closure, a new crosswalk installation, a change to a traffic pattern — are not software updates. They are ODD updates, and they carry their own change control, validation, and approval burden.
The requirements architecture must reflect this. Each operational corridor has its own set of applicable requirements, and the traceability chain from vehicle behavior specification to physical domain must be maintained as both the domain and the vehicle evolve. This is not a problem that scales gracefully with spreadsheet-based requirements management.
Safety Architecture Without a Human Fallback
Every conventional vehicle safety standard in existence was written with a human driver in its mental model. The driver monitors, the driver corrects, the driver performs the minimal risk condition maneuver when automation fails. Remove the driver and the entire fallback architecture has to be reconceived from first principles.
Nuro’s safety architecture rests on several pillars that are worth examining individually because each one has its own requirements and validation implications.
Functional safety without occupant protection. FMEA and FTA for Nuro’s platform do not need to address occupant injury as a hazard category. That removes a significant class of safety requirements — airbag deployment, seatbelt pretensioners, occupant crash dynamics. What replaces it is a category of external safety requirements with no established testing framework: how does the vehicle’s external structure behave in a pedestrian strike? What are the acceptable injury metrics for a pedestrian who contacts the vehicle’s front fascia at 15 mph? Nuro worked with NHTSA to develop a testing protocol that borrows from pedestrian protection standards developed for conventional vehicles but adapts them for a vehicle whose front profile, mass, and approach geometry are entirely novel. That protocol did not exist before Nuro needed it. Building it was a systems engineering activity as much as a regulatory one.
Redundant system architecture. Without a human driver to catch and correct single-point failures, Nuro’s vehicle systems require redundancy at the architectural level. Braking, steering, power, sensing — each subsystem must be designed so that a failure in one channel can be detected and the vehicle can execute a safe stop without the failed channel’s contribution. This is not unique to Nuro among AV programs, but the requirements cascade from redundancy is significant. Every redundant subsystem requires its own requirements, its own test coverage, and its own failure mode specification. The interaction between redundant channels — particularly fail-over timing and state synchronization — creates a class of derived requirements that are easy to underspecify and expensive to discover late.
Behavioral safety. Beyond the hardware, Nuro’s stack must be able to detect that something unexpected is happening — a child running toward the vehicle, a bollard that was not in the prior map update, a delivery zone that is currently occupied — and execute a response that is both safe and operationally sensible. The behavioral safety specification defines the envelope within which the autonomy system is permitted to operate, the conditions under which it must stop and request remote assistance, and the conditions under which it must execute a minimal risk condition without waiting for remote input. Maintaining this specification as the stack evolves is a significant requirements management challenge. A change to the perception system’s confidence thresholds has implications for behavioral safety that are not always obvious at the point of change.
Hardware-Software Co-Design as a Requirements Discipline
Nuro’s R-series vehicles were designed from scratch. There is no donor platform, no modified production chassis, no carry-over interior. This creates an unusual engineering situation: the hardware design space and the software design space are open simultaneously, which means requirements flow in both directions between them.
The sensor suite — the specific combination of lidar, radar, and camera units, their placement on the vehicle, their field of view geometry, and their operational performance envelope — is not independent of the autonomy stack’s perception architecture. A decision to use a particular lidar unit with a given vertical resolution and range characteristic constrains what the perception system can detect and at what distances. A requirement on the autonomy stack to detect a pedestrian at 40 meters in rain constrains the sensor hardware selection. These constraints must be formalized, tracked, and reconciled, or the vehicle that gets built will not satisfy the requirements that were written for it.
Co-design at this level requires a requirements architecture that is genuinely bidirectional: hardware performance specifications that are derived from autonomy stack needs, and autonomy stack behavioral specifications that are bounded by hardware capabilities. In practice, this means the systems engineering function must sit at the interface between hardware and software teams, maintaining a shared model of requirements rather than handing documents over a wall.
The external structure of the vehicle is equally co-designed with the safety architecture. The decision to give Nuro’s vehicle a front geometry that reduces pedestrian injury risk in a strike is not a styling choice. It is a safety requirement instantiated in sheet metal. The traceability from the pedestrian protection requirement to the hood profile geometry to the validation test result is a chain that must be maintained over the vehicle’s production life, including across any design changes.
Regulatory Engagement as a Systems Engineering Activity
NHTSA’s framework for purpose-built autonomous vehicles is still being written, in part by Nuro. This is not a metaphor. The AV STEP program and its predecessor exemption process have been shaped by the documentation, testing protocols, and safety case arguments that Nuro has submitted. That puts Nuro’s regulatory engagement team in an unusual position: they are not simply demonstrating compliance with existing standards. They are participating in the construction of the standards that will apply to them and to the industry that follows.
This has a direct systems engineering implication. The safety case that Nuro submits to NHTSA must be structured well enough to be legible to regulators who are encountering the technology for the first time, auditable over time as the vehicle changes, and defensible if a safety incident requires retrospective analysis. That is a high bar for a document that must also be kept current through continuous software development.
The argument structure of an AV safety case — claim, evidence, reasoning — maps reasonably well onto a structured requirements and verification framework. Claims about vehicle behavior in specific scenarios must be supported by evidence from simulation, track testing, and operational data, with explicit reasoning connecting the evidence to the claim. Maintaining that structure as the autonomy stack changes requires discipline that goes beyond what informal documentation supports.
NHTSA’s evolving framework also creates regulatory risk that must be managed as a systems engineering input. A regulatory change that expands or constrains the permitted ODD, modifies the testing requirements for pedestrian protection, or introduces new requirements around remote monitoring can generate a significant derived requirements load. The engineering organization that treats regulatory engagement as a legal function rather than a systems function will be slower to absorb those changes than one that has built regulatory inputs into the requirements architecture from the start.
Remote Monitoring at Fleet Scale
Nuro’s operational model does not include a safety driver. It does include a remote monitoring infrastructure through which operators can observe vehicle state, receive alerts when a vehicle encounters a situation it cannot resolve autonomously, and intervene to issue new instructions or initiate a safe stop. That infrastructure is not a convenience feature. It is a safety-critical system, and it requires its own requirements, failure modes, and validation burden.
At small fleet scale, the human factors of remote monitoring are manageable. An operator monitoring a handful of vehicles can maintain situational awareness and respond to alerts within acceptable time bounds. At the fleet scale that commercial viability requires, the interaction model changes fundamentally. An operator who must simultaneously monitor dozens of vehicles cannot give each one meaningful attention. The monitoring system must therefore be designed to direct attention appropriately — surfacing the vehicles and situations that require human input while filtering the routine — without introducing the new risk that a genuinely urgent alert is buried in noise.
This is an AI-assisted operations challenge with hard safety requirements attached. The requirements for alert priority, response time, operator cognitive load, and system availability are all specified in the context of a safety function. Failures in the monitoring system — missed alerts, false positives that induce alert fatigue, latency that makes remote intervention arrive too late — have direct safety implications. The validation burden for this system is substantial, and it is not satisfied by testing the vehicle in isolation.
Honest Assessment
Nuro’s engineering approach reflects a genuine understanding of where the hard problems in purpose-built autonomous vehicles live. The decision to design the vehicle from scratch was both a product decision and an engineering one: a modified production platform would have carried occupant safety requirements, regulatory classifications, and structural architectures that do not fit the problem. Starting from a clean sheet allowed Nuro to co-design hardware and software in a way that integrated platforms cannot.
The challenges that remain are real. ODD expansion is slow because each new corridor carries a requirements and validation load that does not amortize quickly. The regulatory framework Nuro is helping to build is not yet stable, which creates ongoing requirements uncertainty. Remote monitoring at fleet scale is an unsolved problem for the industry, not just for Nuro. And the pedestrian interaction model — what it means for a small, autonomous robot to operate safely in environments where people will deliberately approach and interact with it — is still being learned from operational data.
What Nuro demonstrates is that the systems engineering of purpose-built AVs is not a simplified version of the systems engineering of highway autonomy programs. It is a different problem with a different requirements profile, a different regulatory environment, and a different set of failure modes. The companies and programs that treat it as simpler will find that the urban environment’s density and variability are unforgiving of underspecification.