March 18, 2018. 9:58 p.m. Tempe, Arizona.
Picture the street empty enough that a woman felt safe walking her bicycle across it, mid-block, in the dark. An Uber self-driving test vehicle, a modified Volvo XC90 running Uber’s own automated-driving software, struck Elaine Herzberg as she crossed N. Mill Avenue, outside a crosswalk. She died at the scene. It is widely reported as the first pedestrian fatality involving a fully autonomous test vehicle in the United States, and here is the detail I can’t get past: the only person who ever stood trial for it was the safety driver behind the wheel, not the company that built the system.
One human charged. The corporation cleared. Stay with me, because that split is the whole story: it wasn’t decided by anyone’s account of what happened. It was decided by logs.
What the vehicle’s own record showed
Behind the wheel sat Rafaela Vasquez, employed by Uber to monitor the automated system and take over if it failed. Here’s what the machine itself remembered: according to the National Transportation Safety Board’s investigation, the vehicle’s radar and lidar detected Herzberg roughly six seconds before impact. In that window, the system’s software reclassified her three times: first as an unknown object, then a vehicle, then a bicycle. Each reclassification reset its prediction of where she was headed. About 1.3 seconds before impact, the system finally determined that emergency braking was required.
It could not act on that determination. Read that twice, because it’s the hinge the whole case turns on: Uber had configured the vehicle so that automatic emergency braking, standard equipment on the Volvo XC90, was disabled whenever the car was under computer control, specifically to avoid erratic braking behavior. The system was built to flag the danger and hand the decision to the human. So what was the human doing? NTSB investigators found Vasquez had been looking down at her phone, streaming a television program, for extended stretches of the drive, including in the moments before the crash.
Two failures, side by side: that’s how the Board framed its probable cause. Vasquez’s failure to monitor the driving environment because she was visually distracted, and Uber’s inadequate safety culture: its risk-assessment process, its oversight of operators, and its lack of any safeguard against exactly the kind of automation complacency that occurred.
In 2020, a Maricopa County grand jury indicted Vasquez for negligent homicide. In July 2023, she pleaded guilty to the lesser charge of endangerment and was sentenced to three years of supervised probation. Uber itself was never criminally charged; prosecutors had already concluded, back in 2019, that there was no basis for corporate criminal liability.
The question the courtroom actually needed answered
A crash-reconstruction expert can tell you where the vehicle was, how fast it was moving, when it braked. Useful, but not the question this case actually turned on. That question was narrower, and far more technical: at each of those three reclassification events, what did the system know, what did it do with that knowledge, and at what point did responsibility for the outcome pass from software design to human judgment?
You will not find that answer in a police report. It lives in the software’s own perception log (timestamped object-detection and classification events, the vehicle’s speed and steering trace, the automatic-braking configuration setting), read against the in-cabin driver-monitoring footage on the same timeline. Line those two records up, second by second, and you can watch “the system should have known” turn into “the system did know and chose not to act,” and then into “a human was supposed to catch it and did not.” Nudge that timeline by even a single second in either direction, and the story (and the liability) changes underneath you.
A generalist engineer can explain, in the abstract, how object classification works. A lawyer can read the NTSB’s summary. Neither can independently reconstruct the classification log against the driver-monitoring footage, verify the timestamps line up, and state, within the honest limits of what the data can and cannot show, exactly when the window for human intervention opened and closed. That reconstruction is a court-appointed software expert’s job: define the narrow technical question, list the specific artifacts needed (perception logs, braking configuration, monitoring footage, vehicle bus data), apply a repeatable method for correlating them, and say plainly what the record does not resolve. That is also what survives cross-examination: not “the AI failed,” but a timestamped account of what the machine knew, what it did, and what was left for a human to do.
Why autonomous-system cases need a software expert witness
Israel has a serious autonomous-vehicle and ADAS sector, and the same design choice Uber made, where the system hands off to a human and what it logs about that handoff, sits inside every one of those products today. So ask yourself the question this case really asks: if your system detects a hazard and defers the final decision to a person, can you show, second by second, what the system knew and when the handoff happened? If you cannot reconstruct that from your own logs, you are relying on the same kind of account NTSB pieced together for Uber after the fact: designed by the company, tested against the company.
For litigators, the real work happens before you take the case: find out whether the vehicle’s perception, classification, and handoff data exist in a form that can be reconstructed. If they don’t, the case gets argued on marketing claims and driver testimony alone, and that’s a much weaker record to build on.
In a case like this what decides it is a software expert witness written to hold up under cross-examination.
The above is general information only and does not constitute legal advice. Case facts are drawn from the sources cited.