How Can ConOps Drive the Evolution of AV Safety Cases?

The way automated vehicles are operated and managed can drive safety case updates as systems change

A safety case is far more than a compliance document: it's a rigorous, structured argument that defines why a system can be trusted in its real operating environment, weaving together claims and evidence — from hazard, fault, and threat analyses to testing, simulation, and control design — into a single, compelling rationale. As systems grow more complex, so do their safety cases, creating new challenges for not only building a unified argument but maintaining it as living, coherent documentation over a system's entire lifecycle.

Automated vehicles (AVs) are among the most demanding examples of systems that require robust safety cases to earn public and stakeholder trust. Their development spans extensive safety, cybersecurity, and operational work that, in principle, should be methodically organized so engineers, decision-makers, regulators, and other stakeholders can clearly see what is included in the safety case, what has been completed, and why it's sufficient.

In practice, however, safety-related work is often scattered across analyses, test results, operational procedures, and other documents. Each element contributes to safety, but the relationships between different activities are not always clear or linear, making it difficult to assess how they collectively amount to a coherent safety argument.

On top of this challenge, AV developers must defend the safety of systems that are continuously evolving. AVs commonly move through distinct operational milestones: from closed-course testing to public roads, from in-vehicle safety drivers to remote supervision, or from limited routes to broader deployment. Each transition introduces new assumptions, risks, and evidence requirements. Without a clear way to link changes in application and operating conditions to corresponding updates in how systems are designed, validated, and deployed, safety cases can become fragmented, making it harder to maintain documentation, identify gaps, and clearly explain the overall safety argument.

How are safety case frameworks different from safety cases? 

To develop and maintain AV safety cases, organizations typically establish a reusable argument structure — often referred to as a safety case "framework" — that defines the claims and evidence types that will be used to demonstrate that the system is safe for a given application in a specific environment. By definition, the application refers to the AV's intended use, whereas the environment describes its intended operating conditions. 

This framework may then be instantiated as stage-specific safety cases, each aligned with the current state of the product and its deployment. In practice, the terms "safety case" and "safety case framework" are often used interchangeably, but this can obscure how safety arguments mature over time. The framework is meant to capture the ultimate set of intended claims and evidence types for the product; designing it effectively demands true end-to-end thinking. In contrast, individual safety cases are built through incremental use of the framework for each stage as product development and deployment progress.

Over time, this creates a sequence of related safety cases, yet the relationships between them can become obscure if the underpinning framework is not well-defined. Without clear links to prior work, assessing a new safety case becomes more difficult, often requiring broader re-evaluation rather than incremental assessment.

The sometimes-missing piece: defining how systems are used

Operational design domains (ODDs) are already widely used in the AV space to define where and under what conditions a system operates. Typical parameters, such as geographic boundaries, road types, weather, and lighting, have been detailed in industry literature or best practices, giving developers a common language for specifying the operating environment of a particular AV and tracking how its safety case evolves over time.

By contrast, AV applications — how the system will actually be used in practice — are sometimes less clearly and consistently defined. Elements such as the AV's service model, end‑to‑end workflow, and expectations for interactions between the vehicle, its users, and supporting systems are central to an AV safety case, but they fall outside what is covered by ODDs, creating the risk of critical gaps in the overall safety argument.

A concept of operations (ConOps) can provide the missing piece. A ConOps is a standard systems engineering document that describes how a product is intended to operate from an end-user's viewpoint and how the broader system will facilitate such operations. Their use isn't as widespread in the automotive industry, but they are frequently used for complex and highly regulated industries and applications ranging from oil and gas to infrastructure to defense to life sciences. When used effectively, ConOps documentation can improve communication, traceability, operational and system requirements, and more.

When implemented in the context of AVs, a ConOps can define what services the vehicle provides, how trips are initiated, how specific circumstances are handled, what roles remote assistance agents play, how service is expected to scale over time, etc. In effect, it functions like an ODD does for "where and under what conditions an AV operates" but instead encompasses "how the system is intended to be used," providing important definition for coherent, evolving safety cases. 

In many AV programs, elements of a ConOps already exist across design documents, requirements, and operational procedures. However, without the same type of well-established paradigm that ODDs benefit from, it can be difficult to determine when and how evolving operational factors should trigger updates to and reassessments of the safety case.

How ConOps and ODDs can work together

As the efforts to develop ConOps for AVs progress, there is growing potential to enhance safety case development:

1. ConOps shape application-related claims by defining how the system is used, including scale of operations, service model, operational workflows and roles, and user interactions.
2. ODDs shape environment-related claims by defining where systems operate and what conditions they are capable of handling.
3. The safety case framework defines the full set of claims and evidence types needed to support the system's intended operation in its final form.
4. Stage-specific safety cases represent the current instantiation of the safety case framework, based on the system's capabilities, deployment model, and available evidence. The framework may be only partially implemented in a stage-specific safety case depending on the intended operations.

Implementing ConOps in Practice

Developing a ConOps typically means organizing existing design and operational information into a structured artifact (for each stage of operations) that defines key operational information, such as:

• how the system is intended to be used 
• workflows and service models 
• operational roles and responsibilities 
• human-machine interfaces (HMI) and support systems 

When connected directly to the ODD and safety case framework, the ConOps can help teams determine which safety claims and evidence apply to a given deployment stage. As systems expand in capability and operational scope, these links make it easier to identify when safety cases need to change, assess updates incrementally, and maintain alignment between safety arguments and real-world operations.