Building the Torc Driverless Safety Case
As autonomous systems become more complex and physical AI more commonplace, the question for engineering teams is no longer just “Can we build it?” It’s “Can we prove it’s safe?”
That’s where the safety case comes in.
A safety case is not just documentation. It’s a structured, evidence-based argument to demonstrate that a system is safe for its intended use and operating environment. At Torc, it serves as both a technical framework and an execution tool, linking what we build, how we build it, and how we prove safe deployment.
Why Safety Can’t Be Added Later
One engineering pitfall to avoid is trying to add safety in at the end of the development cycle. In practice, that approach almost always leads to rework, delays, and difficult trade-offs.
A safety case forces a different mindset. It requires that safety be embedded into the development process from the beginning, shaping architecture decisions, tooling, testing strategies, and operational assumptions.
When safety is integrated early, engineering teams gain clarity. They know what evidence will be required, what standards they are working toward, and what being “done” means.
Structuring the Case: Torc’s Three Pillars
At Torc, we’ve structured our safety case on three foundational pillars: Engineer It to Be Safe, Operate It to Be Safe, and the Safety Culture of the Organization.
Engineer It to Be Safe is where most technical effort is concentrated, including designing systems that can handle faults and failures, ensuring safe behavior under normal operating conditions, and building in cybersecurity protections. It involves rigorous hazard analysis, robust system architecture, and comprehensive verification and validation. For engineers, this is where safety requirements translate into design decisions, code, and test coverage.
Operate It to Be Safe ensures that the system is deployed safely in the real world, including monitoring and maintenance processes, and incident response planning and drills. Engineering must account for these realities during development, because operational constraints often feed directly back into system design.
Safety of the Organization reflects the safety culture of the company. Although it is less technical, it directly affects engineering outcomes. It determines whether teams have clear processes, whether issues are surfaced early, and whether safety concerns are addressed systematically. This pillar is the foundation for the integrity of the other pillars.
Different leaders champion these areas; engineers and operations interact with all three, and our Chief Safety Officer is accountable for the whole. Our safety case only works when these domains are aligned.
“If generating safety evidence feels like extra work or is on the critical path, your development process needs to be improved.”
From Claims to Engineering Work
At its core, a safety case is a structured argument. It starts with high-level claims about system safety and breaks them down into smaller, testable assertions. Each of these assertions must be supported by evidence.
For engineering teams, this structure provides a clear way to translate abstract safety goals into concrete work. Instead of asking “Is the system safe?”, the question becomes “What evidence do we need to demonstrate that this specific function, component, or behavior is safe?”
This shift is powerful. It allows teams to define requirements more precisely, assign ownership for specific claims, and track progress in a way that is directly tied to safety outcomes. In practice, this often leads to better alignment between engineering, safety, and program management. It also reduces ambiguity, which is a common source of delays in complex systems development.
Integrating Safety into the Development Process
The Torc safety culture means we integrate safety into the standard development workflow.
Ideally, the same activities that produce the software – design, implementation, and testing – should also produce the artifacts required for the safety case. This includes test results, verification data, process documentation, and traceability between requirements and implementation. Automated continuous integration pipelines, simulation frameworks, and data collection systems all play a role in ensuring that evidence is generated consistently and at scale. This approach removes the need for separate “safety phases” and reduces the risk of last-minute surprises.
Ensuring Completion
The driverless safety case integrates safety throughout the development and verification/validation process to ensure that all safety case claims are comprehensively satisfied. To provide independent assurance of completeness and rigor, Torc engages a third-party to assess the safety case by evaluating the safety case framework, sufficiency of the supporting argumentation, and review the quality and adequacy of the evidence presented for each claim in the safety case. Feedback is given along the way to help ensure the safety case is satisfactory. Third party endorsement of the safety case is one of the gating criteria for driverless deployment.
Designing for Change
Autonomous systems are not static. Software updates, new features, and expanded Operational Design Domains (ODDs) are inevitable. From an engineering perspective, this changeability means the safety case must be treated as a living system. Any change to the system has the potential to impact safety. Engineers need to understand which parts of the safety case are affected, what evidence needs to be updated, and whether existing assumptions still hold.
This is similar to change management in other areas of engineering, but with a stronger emphasis on traceability and impact analysis. Without this discipline, it becomes difficult to maintain confidence in an evolving system or to scale.
Building Systems That Are Provably Safe
By forcing clarity around claims, evidence, and responsibilities, a safety case provides a structured way to manage complexity. It aligns design, development, and validation activities around a common goal: Demonstrating that the system is safe.
At Torc, safety isn’t a separate concern or a final check. It is an integral part of how our products are being designed, built, and operated. It is the process we use to ensure we honor our obligation to make roadways safer.
