Building a safety case for a supervised automated-vehicle trial

A safety case is an argument about this trial

A team has proved that its vehicle can complete a closed-track circuit. It has a file of simulation results, an insurance certificate and a trained safety driver. It plans to run on a public route with cyclists, roadworks and unpredictable parking. What connects those files to a decision that this particular trial can be conducted safely? The answer should be a safety case: an explicit account of the trial's boundaries, hazards, controls, evidence and remaining uncertainty, reviewed by people who can stop or change the activity.

The Department for Transport's automated-vehicle trialling code, updated in June 2026, says trial organisations are expected to develop a detailed safety case before public trials. It should be proportionate to the activity and representative of its risks. The code identifies the vehicle and operating domain, safe operation with a safety driver, driver training, organisational responsibilities, legal alignment, engagement and progress reporting as issues to cover. It also says the case should be maintained as the trial evolves and recommends a public-facing version.

This guide explains how to connect a claim to evidence and keep that connection valid. The UK regulations guide helps identify the current legal route. Safety-driver training needs its own assessment within that route. The no-safety-driver pilot guide follows different applicant guidance and should not be treated as the same safety case with the driver's name removed.

Begin with a claim that can be tested

“Our automated vehicle is safe” is too broad to review. A useful top-level claim might be: “This named vehicle configuration can be trialled on the defined route during the stated conditions with a trained safety driver and the specified operating controls, without exposing road users to unreasonable risk.” The wording must be adapted by a competent safety team. It is not a statutory formula or a declaration that risk has disappeared.

Break the claim into smaller questions. Is the vehicle roadworthy and legally usable? Has the automated function been tested for the hazards expected on this route? Can the safety driver see, understand and take control in time? What happens after a sensor fault, uncertain road marking or lost connection? Are communications, incident response and data preservation arrangements workable? Has the trial organisation engaged with authorities and other affected people? Each question needs evidence, an owner and a stated limit. If a branch of the argument is supported only by an assumption, label it as an assumption and decide how it will be tested.

Avoid a common shortcut: placing a long hazard register after a short executive statement without showing how entries support the claim. A register can identify hazards and controls, but it may not show that a control was installed, tested and available in the vehicle on launch day. The case should point to the versioned test report, configuration record, driver assessment and operating instruction that support each material claim. A reviewer should be able to move from an assertion to the underlying result without guessing which file was intended.

Define the unit of assessment

State the vehicle identifier, hardware build, sensors, control interfaces, automated-driving software and map or localisation version. State the planned route or area, speed range, weather, lighting, traffic and time limits. State whether passengers or goods are carried. State how the safety driver supervises the system and which people outside the vehicle can issue instructions. A test in a different vehicle, software release or road setting may still be informative, but its relevance must be argued rather than assumed.

Record exclusions as carefully as inclusions. If the vehicle cannot safely handle temporary traffic lights, the case must say how the team detects that condition before or during a run and what the driver does. If the trial stops at dusk, define who checks the time and what happens when weather reduces visibility earlier. An operating-domain table can be helpful, but it is not self-enforcing. The driver briefing, route monitoring and stop rules must implement the boundary in the real activity.

Separate legal permission from the safety argument

The code describes public-road supervised trialling under existing UK law with a driver ready, able and willing to take control, a roadworthy vehicle and appropriate insurance. It says an ordinary trial does not require a general AV trial permit or surety bond. That does not resolve every prototype, service or local issue. A particular vehicle may require a special order or exemption. A passenger or freight service may need conventional licensing. A safety case cannot create any of these permissions.

Create a legal-basis section with the actual vehicle category, location, driver entitlement, insurance scope and any order, exemption or service licence. Record the advice and source date. Do not write “compliant with all law” as an unsupported conclusion. Where a vehicle has an exemption, describe what it exempts and which roadworthiness duties remain. The code expressly notes that a vehicle operating under a special order can still have to remain roadworthy. The safety argument should explain how any exempted design feature is managed, not merely attach the order.

The code is guidance. It says failure to follow it may be relevant in legal proceedings and following it does not guarantee immunity. Identify which provisions are existing legal requirements, which are the code's expectations or recommendations, and which are additional internal controls. This makes later review more reliable. A project should not call a recommended public safety summary a statutory authorisation condition, nor should it downgrade insurance to a voluntary suggestion because it appears in a guidance document.

Build the evidence chain in stages

The code says extensive software testing would typically progress from bench testing and simulation to closed roads or test tracks before public roads. A good case explains why each stage supports the next. What scenario was tested? Which configuration was used? What result counts as success? What failures occurred, and what changed afterward? The evidence should show why remaining uncertainty can be managed on the public route with a safety driver and other controls.

Consider a junction with parked vehicles blocking a sightline. Simulation may show how the planner behaves across many arrangements. Closed-track work may demonstrate braking and takeover with the actual vehicle. A route survey may identify where the junction's geometry differs. The case should connect these sources and explain a gap if no test covers a pedestrian emerging between parked cars. A vague claim that the model has seen millions of images does not answer the route-specific question.

Treat negative results as evidence. A failed test may reveal a boundary that should narrow the trial, require a stronger fallback or delay launch. The case should preserve the failed result and the corrective action, not remove it from the pack once the vehicle passes a repeat run. It should state whether the repeat test actually exercised the same hazard. A defect closed in a ticketing system is not proof that the associated safety claim is restored until the verification result and configuration are linked.

Evaluate evidence quality, not only quantity

For each important result, record the test environment, date, software build, vehicle, scenario, method and reviewer. Ask whether the measure is relevant to the risk being argued. Mileage accumulated on quiet roads may support reliability in those conditions but say little about operation near a busy school. A safety driver who completed a course on an earlier interface may need a new assessment after the takeover display changes. The case should identify such transfer limits.

Independent challenge is valuable. The person who built a control may be too familiar with it to spot a confusing failure mode. A reviewer should ask for counterexamples, missing populations of road users, unusual weather, maintenance failures and shared causes that defeat several controls at once. Record disagreements and the decision made. This article does not certify an assessment method or replace a qualified AV safety engineer. It gives the trial organisation a way to expose the reasoning for specialist review.

Make the safety driver part of the argument

The code expects the trial to demonstrate that it can be performed safely with a safety driver. The driver must hold the appropriate licence for a public-road vehicle and be able to supervise and take control. Training should cover the tested system's capabilities and limits, intervention, mode transitions and communication failures. The safety case should show how these expectations work for this vehicle and route rather than attach a generic driver certificate.

Describe the driver's view of the road, mode display, warnings and takeover controls. What event requires immediate intervention without waiting for a request? What delay is possible between recognising a problem and obtaining control? Have the required actions been practised in a safe setting at relevant speeds? How will the team limit fatigue and distraction? The competence assessment should identify the person, configuration and date. A general driving licence cannot prove familiarity with this automated system.

The driver also needs a workable operating procedure. If an unplanned disengagement occurs, who decides whether to continue, stop at a safe place or end the run? If remote staff are watching, can they advise without distracting the driver or confusing responsibility? What if their connection fails? The case should not assume that adding a remote observer automatically creates a stronger control. It should examine the communication and human-factors risks that the observer introduces.

Cover organisational and public interfaces

The code expects processes for managing the trial and clear organisational responsibilities. Assign the person who owns the safety case, approves vehicle configuration, authorises a driver, checks route conditions, stops a run and signs restart after an event. Name the organisation responsible when several companies supply software, vehicle maintenance or passenger support. A contractor may perform a test, but the trial organiser remains responsible for the safe conduct of the activity. Contracts and internal instructions should match the responsibility map.

Engagement belongs inside the safety case because other organisations know about risks the test team may miss. The code recommends informing the Centre for Connected and Autonomous Vehicles and engaging relevant highways and local authorities, police and others affected. A road authority may identify planned works. Emergency responders may need a vehicle isolation procedure. Residents may report a difficult crossing or vulnerable road user pattern. Preserve those inputs and show how they changed the route, operating time, warning signs or response plan.

If the trial carries passengers or goods, document the separate service model and applicable licensing review. A vehicle safety argument does not show that a passenger can board safely, obtain help after a stop or receive information in an accessible form. If those activities are outside the project scope, say so. If they are within scope, assign an owner and evidence rather than assuming a later passenger-service permit or contract will automatically solve them.

Plan for events that defeat the first control

A case is weak if every hazard ends with “the safety driver will intervene”. Explore circumstances where the driver receives little warning, becomes confused by a mode transition, is temporarily distracted or cannot act quickly enough. The vehicle design, operating domain and stop rules should reduce dependence on a single perfect intervention. Test communications degradation, sensor obstruction, roadworks and unexpected traffic behaviour. Record which response is automatic, which belongs to the driver and which requires outside support.

An incident response plan should explain how people are protected, the vehicle is made safe, authorities are contacted, data is preserved and operations are paused. The code recommends contingency planning with appropriate authorities and readily accessible incident data. It says trial vehicles should record enough to determine who or what controlled them. Exact recorder design is an engineering and privacy decision. The safety case should identify the primary data source and how its configuration matches the vehicle, without claiming that ordinary document software captures sensor data.

Keep an explicit hold rule. After a collision, near miss, unexplained intervention, control failure or material route change, the responsible team should assess whether the original claims still hold. A project should not use a previously signed cover sheet as permission to continue while evidence is being investigated. The case should name who can impose the hold and what proof is required to lift it. A minor issue might be closed within an existing control, while a major design change can require revisiting the top-level argument.

Maintain the case as a living record

Assign every claim and evidence item a version, owner and review trigger. When software changes, identify which tests and driver training may be invalidated. When the route changes, reconsider operating-domain and authority engagement evidence. When a supplier changes, review the maintenance and incident handoffs. A simple impact table can connect the change to claims, tests, permissions, people and public information. The table does not decide safety; it prevents a changed activity from being hidden inside an unchanged document title.

Hold periodic reviews during the trial. Compare expected behaviour with actual interventions, faults, complaints and route observations. Record what was learned and whether the safety case should be narrowed, expanded or suspended. The code recommends maintaining and updating the case and sharing milestones. A long-running trial that never revisits its original argument cannot show that it learned from the road environment it entered.

The document control system should preserve the version that supported each public run. If an investigator asks about a journey last month, the team needs the operative safety case, route, vehicle build, driver authorisation and decision to continue on that date. Replacing a file with a newer version while losing the old one damages that reconstruction. Storage, access and retention require privacy and legal review for the specific data. A web page cannot set a universal retention period for every trial.

Prepare a public version without losing the substance

The code recommends that trial organisations make an abridged public-facing safety case available and send it to the Centre for Connected and Autonomous Vehicles. The public version can explain the vehicle, area, operating limits, safety driver, contact route, incident response and how feedback will be handled. It should help road users understand what they may encounter. It should not assert that the future full Automated Vehicles Act authorisation has already been granted if the activity is a current supervised trial.

The public summary is not the entire technical case. Security-sensitive information, personal data and proprietary design details need careful review before release. But redaction should not remove every meaningful limit or make the summary a marketing brochure. The organisation should be able to explain why the trial is being conducted in this area, who remains in control and what stops the activity if conditions change. A public safety case that cannot answer those questions offers little information gain.

Ask a non-engineer to read the proposed summary. Can they tell when a driver is present, what the automated function does, whether passengers are carried and how to report a concern? If not, revise the language. Then compare the summary against the current internal case so they do not contradict each other. A changed internal operating domain should trigger review of the public version too. This is a useful content control rather than a substitute for technical assurance.

A review table for the final safety argument

This table is a review aid. It is not an official form, a safety standard or a declaration of adequacy. A competent safety engineer should assess the argument and underlying evidence for the real vehicle and route. Road-traffic legal, insurer, privacy and service specialists may need to resolve different parts of the case.

Where Complys may fit

Complys can be evaluated for versioned documents, action ownership and evidence retrieval if its current product can demonstrate the relevant controls. Its public AV workspace preview is noindex and does not prove a released safety-case module. Complys does not determine whether a hazard is controlled, validate an automated driving system, record live sensor data or grant public-road permission. Specific feature claims require product-owner confirmation before release.

For a demonstration, give the product team one safety claim, three supporting tests, a driver assessment and a new software release. Ask them to show how the release triggers review, how the old evidence remains recoverable and how an unresolved claim stays visibly open. If those connections must be maintained outside Complys, document the external system and handoff. The AV software pillar offers a broader buying script. The AV checker is a nonbinding route pointer. Confirm its result against current primary sources and the facts of the proposed trial.

The next step for a trial organiser is to assemble a route-specific safety argument, ask an independent specialist to challenge it, and resolve gaps before the public-road launch decision. A system can help preserve the evidence and review history. Accountability for the trial remains with the people and organisations conducting it.