A safety case is not a claim that an autonomous vehicle can never crash. It is a documented argument, backed by evidence, explaining why the system’s risks are understood, controlled and acceptable for the intended use.
What is normally inside a safety case?
The exact regulatory format varies, but a safety case can include the intended use and operational design domain, system architecture, hazards and risk controls, validation results, fallback strategies, monitoring processes, cybersecurity and software-change controls, and evidence that safety will be maintained through the system’s lifetime.
Why is it important for automated driving?
An automated driving system has to operate in an open, changing environment. Regulators therefore need more than a demonstration video or a total number of test miles. They need evidence explaining what the system is designed to do, how its risks were assessed and how developers know its performance is sufficient.
Safety case vs safety standard
A standard may specify engineering requirements or processes. A safety case brings together the reasoning and evidence for a particular system and use case. It can reference standards such as ISO 26262 or SOTIF, but the safety case itself is the system-specific argument.
UK example
In its 2026 automated-vehicle safety consultation, the UK government describes a safety case as documentation setting out the reasoning for how an automated driving system meets regulatory requirements and is free from unreasonable risk. It can include intended use, validation testing and lifetime safety processes.
How validation fits
Validation produces the test evidence. The safety case explains how that evidence supports the claim that the system is safe enough for the proposed operational domain and deployment.