Safety management evidence for a no-driver pilot

A document is not the management system

A pilot applicant may have a substantial technical safety report and still lack a workable way to keep its vehicles safe after launch. The team that built the automated driving system may release software. Another company may maintain the vehicle. A third may dispatch it, respond to stranded passengers and receive incident reports. If those organisations cannot show who controls risk across the handoffs, the safety case is a static argument with no dependable operational owner.

The Department for Transport's current pilot applicant guidance expects a documented safety management system for the automated driving system throughout the pilot. It also describes assessment of the operator's management systems, initially through policies and other records, followed by on-site validation before deployment. The source separates the vehicle and automated-system safety case, the safety management system, and operator requirements. An applicant should preserve those distinctions even where one organisation performs several roles.

This page owns the evidence that the pilot's safety management processes exist, work and remain active. The pilot overview owns the application sequence. A Vehicle Special Order addresses specific exemptions. A supervised trial with a safety driver follows a different route. This guide is for the present no-driver pilot, where ordinary assumptions about immediate human takeover cannot underpin the operating plan.

The DfT guidance uses a draft United Nations automated-driving-system regulation to inform several assessments. The guidance expressly says that draft regulation had not been adopted internationally or by the UK at publication and was not in force. A safety manager may use it to structure evidence because the DfT says assessments will be informed by it. The manager must not present that draft as directly binding law. The particular Vehicle Special Order and any passenger permit, once issued, can impose actual conditions. A legal reviewer should check those instruments alongside current legislation and guidance.

Name the accountable organisations and decisions

Start with an organisation map. Identify the pilot applicant, automated-driving-system developer, vehicle manufacturer or modifier, operator, registered keeper, maintainer, remote-assistance provider and passenger service holder where applicable. Some names may repeat. That does not make the responsibilities interchangeable. The developer may be able to disable a faulty software version while only the operator can suspend a route. The registered keeper may control a DVLA update while the applicant holds the Vehicle Special Order. The safety management system should identify who makes and records each decision.

For each critical function, write a simple handoff: trigger, decision owner, evidence source, response deadline based on the actual risk or instrument, escalation path, and authority to stop deployment. Include who can release a vehicle into service after maintenance, who approves an operating-domain change, who receives system alerts, who decides that an incident is reportable and who signs off restart. Do not invent a universal statutory deadline for every incident. The actual reporting category and time may depend on the issued order and any passenger permit.

The DfT guidance says operator requirements may apply to third parties contracted to undertake operator functions. A contract therefore needs more than a general promise to comply with law. It should give the operator access to safety-relevant logs, support during an investigation, notice of software changes, competence records and a way to pause unsafe work. A supplier may have its own internal safety process, but the pilot applicant must be able to demonstrate how that process fits the deployed vehicle and journey. Check whether the contract allows evidence to be supplied to the authorities when properly requested.

Set a governance rhythm that matches the pilot's risk. A launch board may review open safety issues before the first public journey. A daily operations meeting may examine route closures, vehicle faults and pending updates. A periodic safety review may analyse trends in unusual stops or remote-assistance requests. These are practical examples, not prescribed meeting frequencies. The actual system should have named participants, written decisions, action owners and proof that issues were closed or deployment restricted.

Connect the ADS safety case to live controls

The pilot guidance expects a documented safety case that makes a structured, comprehensible and valid argument about the automated system and its development. The safety management system must maintain that case as the vehicle and service change. Each important claim should point to evidence and to an operational control. If the case says the vehicle can safely stop when it loses connectivity, the operator should be able to show tested fallback behaviour, a monitoring procedure, staff instructions and records from actual events. A diagram of the intended process is weaker than evidence that it has worked.

Keep a claim and evidence index with the vehicle configuration, software version, scenario, route and date. Include a status for evidence that is provisional, accepted for a limited purpose or superseded. A test completed on a closed track may support a claim about braking logic, but it may not support an unrestricted claim about pedestrian interactions in a busy town centre. The technical reviewer should document the gap and the next test. A new software model can invalidate an earlier test even when the user-facing service appears unchanged.

The guidance says assessment of automated-system capability can include an audit of development and deployment processes, a safety-case assessment, and confirmatory testing across real-world, track and simulation environments. It also mentions modelling and simulation credibility and scenario-based testing. The applicant should be able to show how scenarios were chosen, how test quality was checked and how failures changed the system or operating boundary. A dashboard with a high number of simulated miles does not explain which hazards were tested. The audit trail should let a reviewer reconstruct a consequential claim back to the underlying test and its limitations.

Do not confuse the safety case with the safety management system. The case argues why a defined automated operation is acceptably safe. The management system governs how people create, check, approve, change and monitor that argument over the duration of the pilot. A strong test report cannot compensate for an operator that cannot detect an unsafe software release. A neat policy library cannot compensate for an unsubstantiated claim that the automated system handles a difficult junction.

Demonstrate the four operator management pillars

The DfT guidance describes operational management assessment through four pillars: safety policy and governance, operational safety risk management, operational assurance, and performance monitoring with ongoing compliance. The applicant can use them as an evidence index. Under governance, show who can set safety objectives and who can suspend service. Under risk management, show how hazards from the actual routes are found, assessed and controlled. Under assurance, show that required processes have been tested in practice. Under monitoring, show what signals prompt correction rather than waiting for a serious collision.

A useful governance example is a route-release decision. The operator proposes an extension into a road with a new bus lane and a school crossing. The automated-system developer assesses perception and planning. The local operations lead assesses roadworks and pickup locations. The safety lead reviews residual risks and test evidence. The legal lead checks whether the Vehicle Special Order or passenger permit needs variation. One named person decides whether the route can be enabled in dispatch. The record should show the version of each input, any restrictions and why the decision was made.

Operational risk management should include vehicle faults, foreseeable misuse, emergency access, vulnerable road users, passenger behaviour, adverse weather, mapping errors, cyber disruption and remote-support delays. The list is illustrative. It should be narrowed and extended for the actual deployment. For each material hazard, identify the preventive control, how it is monitored, the fallback if it fails and the evidence that people can carry out the response. A written control that depends on a remote worker seeing an alert within seconds must be tested against actual staffing, communications and workload.

Operational assurance means challenging whether the documented process works. The pilot guidance expects operator procedures to be reviewed and, where appropriate, demonstrated on site before deployment. Run a vehicle fault exercise, a lost-connectivity exercise and a route closure exercise with the people who will be on duty. Record what they did, where the procedure failed and whether the updated control was retested. Avoid treating a one-off demonstration as permanent proof. Staff turnover, new routes and a different operating schedule can erode the original assurance.

Performance monitoring should examine more than total mileage and collision counts. Consider unexpected stops, assistance requests, interventions by emergency services, repeated sensor degradation, unplanned route exits, maintenance defects, passenger support delays and near misses. Define what is logged, who reviews it and what threshold triggers a hold or investigation. The threshold is a technical and operational decision for the actual pilot. Do not claim the DfT has set a generic public threshold for every metric.

Make changes visible before they reach vehicles

A no-driver pilot can change through software, maps, hardware, remote-support tools, maintenance practice or service geography. Every change should enter one controlled review with a clear description of the existing and proposed configuration. Ask which safety claims, tests, operating limits, legal permissions, insurance terms and training materials are affected. Record the answer even when the conclusion is that no new authority contact is needed. Silence in the change log makes later reconstruction difficult.

A release process should identify the software build installed on each vehicle, the evidence supporting that build and the person who approved deployment. A supplier may use its own release notes, but the operator needs a version that connects those notes to the actual fleet. Before updating vehicles, confirm that the VSO conditions permit the proposed change or seek advice on notification. Check whether a route or passenger permit condition is affected. The applicant should not assume that a small code change is legally or technically immaterial because it has a minor internal label.

Make rollback and containment practical. If the new build causes unusual braking, can the operator take affected vehicles out of service and restore a validated version? Does the support team know which vehicles received the build? Are there logs to distinguish the behaviour before and after release? Who informs the insurer or authority if a condition requires it? A safety management procedure is credible when staff can perform it in the middle of a real shift, not only when every specialist is present in a meeting.

The DfT guidance also expects suitable maintenance and software management procedures, including checks before deployment. Maintenance records should connect a defect, repair, test and release decision to the specific vehicle. If a workshop changes a camera, the technical owner should determine whether calibration and automated-system validation are needed. A conventional roadworthiness inspection does not necessarily test automated-driving performance. Equally, successful automated-system tests do not replace ordinary vehicle maintenance.

Handle incidents as evidence, not only as reports

An incident can reveal a failed assumption in the safety case. The safety management system should move from detection to immediate safety response, evidence preservation, classification, reporting decision, investigation, corrective action and controlled restart. The pilot guidance discusses incident management and reporting expectations, while issued VSO and APS conditions may specify categories and times. Use the actual instrument for the binding condition. Avoid copying a time limit from a passenger permit into every vehicle event.

Preserve vehicle logs, relevant sensor data, operator communications, route state, maintenance history and software version in a controlled manner. Personal data and sensitive security information need proportionate access and retention controls. A team investigating an emergency stop should know whether the automated system triggered it, whether remote assistance was requested, what the operator saw and whether the vehicle stayed within its operating boundary. If a supplier controls the logs, the contract and procedure should support prompt lawful access.

The investigation should feed back into both the technical case and the operating process. A repeated object-classification error may require new scenarios and software changes. A delayed recovery vehicle may require a different route or staffing plan. A passenger unable to reach support may expose a service design problem rather than an automated-driving defect. Assign actions to the organisation able to implement them, then verify completion before reopening the affected operation. Publication of an incident summary is a separate decision governed by the relevant rules and facts.

A near miss deserves attention even if no formal external report is required. Trend analysis can reveal that a system is repeatedly approaching a safety boundary. Record why the event was classified as it was and whether the classification rule needs improvement. A performance chart that excludes awkward events by redefining them will not provide reliable assurance.

Keep remote assistance and cyber controls in scope

Remote assistance creates a boundary between the automated system and a human support organisation. The DfT pilot guidance expects the operator to show that any remote assistance is suitable and safely implemented, with response plans, communications performance, fallback arrangements, testing and functional safety assurance. It describes assistance as advice only in its operator assessment table. That detail should be checked against the actual design. A remote person who must continuously watch and immediately control motion may undermine the no-safety-driver pilot route.

The safety management system should record loss of connection, queue length, staff competence, instruction authority and how a vehicle decides whether to accept advice. Test the arrangement during a communications outage and when multiple vehicles request help at once. If the proposed solution relies on a remote worker taking over steering, specialist legal and technical review is needed. The remote-assistance owner in the AV map will cover this design in depth; this page covers how the function is governed and evidenced within the pilot safety system.

Cybersecurity is also a safety concern when remote services or software updates can affect vehicles. The DfT guidance describes a parallel assessment of cyber security and software updating, with attention to interactions from remote services. The pilot should show who patches vulnerable components, how an urgent update is evaluated, what can be isolated, and how the operator knows the fleet's security state. A separate cyber assurance owner will address the detailed case. Here the central question is whether a cyber alert can trigger an operational safety response and a controlled restart.

The guidance refers to standards and a draft United Nations automated-driving-system regulation as assessment aids. They can help structure evidence, but the page should not claim that citing a standard proves compliance. A specialist should determine the applicable edition and whether a particular requirement fits the submitted system. The law, issued order and permit conditions remain distinct from voluntary or draft technical material.

Prepare for the desk audit and the on-site test

An audit pack should be navigable. Start with the organisation and role map, safety policy, risk register, automated-system safety case, vehicle configuration baseline, development and test process, route and operating limits, maintenance and update controls, remote-support plan, incident plan, training and competence records, data handling arrangements, insurance and a permission matrix. For each document, identify its owner, version, approval date, applicability and linked evidence. The pack should show how a reviewer can move from a policy claim to a real example.

Then test the same controls in the field. Can an operator locate the latest approved route? Can it show that a specific vehicle passed pre-deployment checks? Can the support centre handle a stranded vehicle without assuming a safety driver is on board? Can staff suspend dispatch after a safety alert? Can a maintainer show which software was fitted when an event occurred? The DfT guidance says operator management documents are initially assessed and then validated on site before deployment. A procedure that cannot be performed is a finding to correct, not a reason to relabel the document.

Use an exceptions register for unresolved items. Mark whether an issue blocks launch, limits a route or requires more evidence. Assign the person who can resolve it and the review date. The applicant should not erase an open issue when a supplier changes its description. Decision-makers need a truthful view of residual risk and uncertainty. If an alternative means of demonstrating a requirement is proposed, the pilot guidance says VCA acceptance matters. Record that acceptance rather than assuming the alternative is valid because it seems technically persuasive.

A practical readiness review for one vehicle and route

Imagine a shuttle that will operate between a station and a business park. The safety case says the vehicle can navigate a particular junction in daylight. The operator has a route procedure and the remote team has completed training. A week before launch, roadworks narrow the junction and the supplier delivers a new perception build. A generic statement that the organisation has a safety management system does not resolve the new risks.

The review team should identify the old and new route geometry, the vehicle build, test coverage and whether the shuttle can remain within its assessed operating conditions. It should check whether remote assistance is still advice only, whether the support team's training covers the change, and whether maintenance and insurance records remain current. It should examine the VSO and any passenger permit for route or modification conditions. The designated decision-maker then records whether the vehicle is held, the route restricted or further evidence accepted. That chain of decisions is the management system in action.

If the roadworks disappear, do not simply discard the event. It may reveal a weakness in how route changes are detected. Improve the procedure and test it again. If the supplier cannot provide enough data about the new build, the operator may be unable to support its safety argument. Contract and product-release processes should make that gap visible before vehicles receive the update.

Where Complys might help

A pilot needs controlled documents, owners, review dates, evidence links and a retrievable history of safety decisions. Complys may be assessed for those administrative parts through a product demonstration. This article does not claim the platform calculates automated-driving safety, runs simulations, approves a VSO, submits reports, provides remote assistance or monitors live vehicle telemetry. Those are specialist or authority functions, and any proposed feature statement needs product-owner verification.

Use a real workflow in a demonstration. Provide a route change, a software update and an unresolved maintenance finding. Ask how the product would connect each to the correct vehicle, assign review owners, distinguish pending from approved evidence and retrieve the earlier decision after an incident. If the platform lacks a needed control, document the external system that supplies it. The AV software overview frames the procurement question. The AV checker is a nonbinding pointer to possible regimes, not a safety management assessment.

The useful next step is to appoint the pilot's decision owners, assemble an evidence index and run one desk-to-field exercise before assuming that the procedures work. A competent AV safety specialist should review the technical case, an operations specialist should observe the process, and a legal specialist should check the actual permissions. The aim is a live, auditable management system for a defined vehicle and service, not a thicker binder.