Autonomous Vehicle AI Safety Case Review Template
A safety case is an evidence map, not a permission slip
A safety case is a structured argument about why a system is acceptably safe for a defined use. It is not a certificate, a launch approval, or a promise that an autonomous system cannot fail. For autonomous vehicle and embodied autonomy review, the useful version is an evidence map: what the system is allowed to do, what hazards were considered, what evidence supports the controls, and what assumptions would make the case invalid.
This template is for research and governance review. It is not engineering certification or legal advice. It helps a reader inspect public evidence, caveats, and missing proof before assigning trust to a deployment claim, especially when the system moves from software output into physical action.
Start with the operational design domain
Before reviewing model performance, define the operational design domain. Where does the system operate? What road types, speeds, weather, lighting, construction zones, pedestrians, cyclists, emergency vehicles, and traffic patterns are included or excluded? Does a human supervise continuously, remotely, or only after an alert? Is the system an automated driving system, driver assistance feature, or another embodied autonomy workflow with comparable physical safety consequences?
Vague safety claims usually fail here. A statement like "the system is safe in cities" is not reviewable. A statement that names roads, conditions, fallback behavior, test limits, and excluded scenarios can be checked against evidence.
Review the hazard chain, not only the model
The Uber self-driving fatality shows why a safety review cannot stop at one perception model. The risk chain includes sensing, object classification, prediction, path planning, braking policy, fallback design, safety-driver attention, test governance, and post-incident response. A weakness in one layer can become fatal when the surrounding layers do not compensate.
For autonomous AI, ask what happens when classification is unstable, the system sees an object it was not trained to treat conservatively, or an operator is expected to supervise a mostly automated task for long periods. Human fallback is not a magic control. It needs evidence too.
Evidence checklist for autonomous deployment review
What public disclosures can and cannot prove
NHTSA materials on automated driving systems and Voluntary Safety Self-Assessments are useful because they list safety elements such as operational design domain, object and event detection and response, fallback, validation methods, cybersecurity, data recording, and human-machine interface. But voluntary disclosure is not the same as federal approval, and a public summary may omit technical details needed for a full safety case.
Crash reporting data also has limits. Standing General Order reporting can surface incidents and trends, but public counts should not be treated as normalized cross-company crash rates without exposure, fleet size, operating conditions, and reporting context. A safety case should use those disclosures as evidence, not as a scoreboard.
Red-team questions before deployment expansion
Ask the uncomfortable questions before the system expands its operating domain. What is the worst plausible misclassification? Which road users are hardest to detect? What happens if the system cannot decide whether an object is stationary, moving, or relevant? Is emergency braking always available, or can it be delayed or suppressed? Can a human operator realistically intervene in time after long passive supervision?
Then ask governance questions. Who can stop testing? Who reviews near misses? What evidence is independent of the team trying to ship? What changes after an incident? Which assumptions are monitored after deployment rather than only during launch review?
How MisalignAI connects this to incident memory
This guide supports the safety-failure cluster by turning a fatal incident record into a reusable review method. The point is not to create a generic form. The point is to make sure incident memory changes future deployment questions.
MisalignAI keeps this template free because autonomous safety review should be understandable before any subscription product exists. Future paid tools can add exports, monitoring workflows, or deeper comparison layers. The public page still needs to stand alone: evidence boundaries, source notes, and concrete review questions.
Source notes
Source support: the NTSB Uber Tempe investigation anchors the hazard-chain framing. NHTSA Automated Driving Systems guidance and the VSSA index provide public safety-element vocabulary, including operational design domain, object and event detection and response, fallback, validation, human-machine interface, cybersecurity, and data recording. NHTSA Standing General Order crash reporting is used only as an example of incident evidence with reporting limitations. UL 4600 and ISO 21448 are referenced as safety-case and intended-functionality context, not as proof that this checklist certifies compliance.