Safety Case
Artifact
Topic overview
Quick facts
A safety case is not a pile of documents; it is an argument. It states explicit claims (this system is acceptably safe for this use in this environment), decomposes them through structured reasoning into sub-claims, and grounds each leaf in identifiable evidence: analyses, test results, process records, field data.
Goal Structuring Notation (GSN) is the most common way to make the argument structure explicit and reviewable, linking goals through strategies and assumptions down to solution nodes. The discipline forces the question every program should answer anyway: why, exactly, do we believe this is safe, and what evidence would change our mind.
It is required explicitly by for rail signaling, which prescribes a specific structure (definition of system, quality management report, safety management report, technical safety report, related safety cases, and conclusion), and by for autonomous products, which is organized entirely around safety case claims and prompt elements.
Even where not mandated, automotive and robotics programs increasingly build one because it integrates 26262, , and cybersecurity arguments into a single reviewable whole.
A safety case must be maintained across the lifecycle: every design change, field incident, and expansion either fits within the existing argument or breaks a claim that must be repaired. Context and assumptions are load-bearing, an assumption recorded as operators will be trained is a real dependency that operations must honor, not decoration.
Why Safety Case matters
The safety case is the artifact on which approval decisions are actually made: rail authorities grant service acceptance on it, assessments audit it, and after an incident it is the document that determines whether the organization looks diligent or negligent.
Building it retrospectively is brutally expensive because missing evidence means re-running analyses and tests on a finished design. Run forward, it doubles as a management tool: the argument skeleton written early exposes exactly which evidence each team owes and when, turning safety from vague obligation into a trackable backlog.
How Safety Case is applied
Safety lifecycle
The safety case skeleton is drafted early, at concept or architecture time, by the safety manager or safety case owner: top claims, argument strategy, and placeholder evidence nodes. As the program executes, evidence from analyses, V&V, and process audits is attached, and assumptions and open items are tracked to closure.
In rail practice the safety case passes through independent safety assessment before submission to the authority; under it is assessed against the standard's prompt elements. After release it lives under configuration management, updated with each change and periodically revalidated against field experience.
Assessors evaluate whether the argument is valid (do the sub-claims actually establish the parent), whether evidence genuinely supports the leaf claims, whether assumptions are explicit and honored, and whether counter-evidence such as incidents and test failures has been confronted rather than omitted.
Safety Case pitfalls to avoid
Standards related to Safety Case
In programs run to EN 50129, Safety Case is one of the things the assessor checks first - safety-related electronic systems for railway signaling, including the structure of the safety case.
In programs run to UL 4600, Safety Case is one of the things the assessor checks first - safety case framework for fully autonomous products operating without human supervision.
Safety case ownership and review
| Aspect | Detail |
|---|---|
| Produced by | Safety manager / safety case author |
| Inputs | Hazard log, analyses, V&V reports, QM evidence |
| Outputs | Argued claims with traced evidence |
| Reviewed by | ISA (rail), assessor, regulator, customer |
| EN 50129 parts | Quality mgmt, safety mgmt, technical safety report |
Safety Case by industry
Rail & Transit programs lean on Safety Case because the sector covers freight and passenger rail signaling, train control, and transit systems.
In autonomous systems, Safety Case comes up in nearly every certification conversation: autonomous mobile equipment, off-highway autonomy, and driverless platforms.
Ask our team about Safety Case
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Jeff Twombly, PEExecutive, Rail SafetyProvides executive and technical leadership for rail-safety programs, assessments, and complex transit-system work. His experience spans safety assurance, transportation-safety leadership, signaling, and independent review.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.Safety Case: related terms
How each connects to Safety Case:
ISA appears in the same lifecycle work as Safety Case and is usually produced or reviewed alongside it.
EN 50129 connects the two: Safety Case and Fault Tree Analysis are assessed against the same lifecycle.
UL 4600 connects the two: Safety Case and ODD are assessed against the same lifecycle.
CENELEC Rail Standards is governed by EN 50129 as well, which is why the two show up together in audits.
Both Safety Case and Safety-Critical System sit under EN 50129, so evidence for one usually references the other.
Like Safety Case, Functional Safety Plan is a artifact you will meet early in a safety program.
Like Safety Case, Functional Safety Requirements is a artifact you will meet early in a safety program.