Roadworthiness records for a self-driving vehicle pilot
A vehicle cannot be cleared by a fleet dashboard alone
A pilot operator sees a green status for a driverless shuttle at 06:30. It was inspected the previous evening. Overnight, a software package was updated, a sensor housing was replaced and the road crew reported a pothole on the first route. The dashboard may be correct that the battery is charged and the vehicle is online. It does not establish that the vehicle is roadworthy, that the repair was verified, that the current software matches approved evidence or that it may operate under the conditions of its Vehicle Special Order.
The DfT self-driving pilot applicant guidance says operators should keep records of safety inspections and maintenance undertaken to keep pilot vehicles roadworthy for at least 15 months, following principles of the DVSA guide to maintaining roadworthiness. It also says operators should keep records of daily activities to ensure vehicles are safe and roadworthy for passenger or freight carriage where relevant. The guidance is an applicant and operating expectation. The actual Vehicle Special Order, any passenger permit and ordinary vehicle law may add or alter the obligations for a particular deployment.
This page owns the evidence trail from vehicle check to dispatch and back to service after a defect. It does not determine Vehicle Special Order eligibility, grant an exemption, approve a software release or replace a qualified technician's judgment. A separate pilot overview owns the overall scheme. A Vehicle Special Order guide owns permission and condition control. Here the reader needs a practical way to prove that each physical vehicle was checked, maintained, restricted when necessary and released by an accountable person.
The DVSA roadworthiness guide gives detailed principles for commercial goods and passenger-carrying fleets. Its legal and licensing parts depend on the vehicle type and operating model. Do not lift an HGV inspection interval into a small AV shuttle without a vehicle-class review. Use the guide's control logic, then have the fleet and legal specialists set the actual schedule and records for this pilot.
Establish one record per physical vehicle
Start with a stable vehicle identity. Link the registration mark, vehicle identification number, fleet number, approval status, self-driving listing position, relevant Vehicle Special Order, permit association and current hardware baseline. A digital label that says shuttle 4 is insufficient if vehicle shells, sensors or computers can be swapped between projects. The record must allow an inspector or incident investigator to trace which configuration was on the road at a particular time.
Keep a controlled document list for each vehicle: registration evidence, applicable approval or exemption, MOT where required, inspection plan, maintenance history, defect reports, repair authorisations, software releases and return-to-service decisions. Note which documents are originals, which are copies and where the legal source of a condition sits. A task card should not silently replace the signed Vehicle Special Order. The operator's internal system should point to that order and its current version.
An automated vehicle has more than conventional roadworthiness components. Tyres, brakes, lighting, steering, body, restraint equipment and visibility remain important. Sensors, compute hardware, power distribution, positioning equipment, interfaces to the automated driving system and human or remote support interfaces can also affect safe operation. The exact check belongs to the approved vehicle design and maintenance plan. A clean conventional inspection does not show that a repaired sensor has been calibrated against the correct software.
Record which organisation owns each system. A manufacturer may set calibration tolerances, a local operator may perform daily checks and a contractor may repair a braking component. If ownership is split, the record should show the handoff and final release authority. A supplier's work order may prove that work was attempted. It does not by itself prove the operator accepted the vehicle for a particular route.
Make pre-deployment checks observable
Design the daily or pre-deployment check around failures staff can detect before use. The pilot guidance expects documented pre-deployment procedures and evidence that they are implemented. It also expects vehicle maintenance and software-management processes. A good check identifies the vehicle and shift, person or automated test that performed each item, result, exception, time and decision. An automatic self-test can be evidence, but a human must know what the test covers and what remains outside it.
A pilot check may include visible damage, tyres, lights, doors, restraints, emergency equipment, sensor cleanliness and obstruction, diagnostic faults, battery or fuel system, communications, positioning confidence, software version and the planned route file. The operator should determine which checks apply to its vehicle. A check called sensors OK without identifying each critical device or diagnostic result may hide an occluded camera. A map version labelled latest may be wrong for a restricted route.
Identify the start condition. The vehicle may be fit to move in a depot but not fit to carry passengers. It may be fit for supervised testing but not a no-driver pilot. It may be fit for one operating domain but not another. The release screen should state the permission and use being authorised. A vehicle should not become available to booking or dispatch solely because a technician closed a work order.
Defect reporting must be easy. A support worker, remote operator or passenger may notice a failure that the automated diagnostic system did not flag. Give each a route to report it. Preserve the original description and time. A defect may concern a physical part, software behavior, user interface or service equipment. Do not require the reporter to diagnose the cause before the vehicle is placed on hold. A vague item can be triaged, but it should not disappear from the queue because its category is uncertain.
Set a maintenance plan for the actual vehicle and duty cycle
Inspection frequency is a technical and legal decision. Use vehicle type, manufacturer instructions, statutory testing, mileage, hours, duty cycle, operating environment, history and safety case. A low-speed shuttle running short trips all day may accumulate repeated brake and door cycles despite modest mileage. A vehicle exposed to salt, heavy rain or frequent kerb contact may need checks that differ from an indoor test vehicle.
The DVSA guide stresses planned safety inspections, defect systems and records that can be reviewed before return to service. For an AV pilot, add checks for safety-critical software, sensors and integration changes. The calendar should cover statutory tests where applicable, periodic safety inspections, preventive maintenance, software review and condition-based checks. It should show overdue work and prevent dispatch when a hold applies. A reminder is not the same as evidence that the work was completed.
Avoid an arbitrary 15-month inspection cycle. The pilot guidance's 15-month figure concerns how long certain inspection and maintenance records should be kept, not how often vehicles are inspected. The actual inspection interval must be set separately. A law or licence condition may require more specific records or retention for a particular vehicle class. A specialist should reconcile those sources.
Document third-party work. If a supplier calibrates a lidar unit, require a report identifying the device, method, tolerances, result and software or calibration file. If an operator replaces a conventional part, record part identity, work, test and responsible person. If a repair affects the automated driving system, an engineering review should decide whether safety evidence, Vehicle Special Order conditions or operating-domain limits need reassessment. The mechanic's sign-off and AV safety approval may be different gates.
Use a defect-to-release chain
A defensible chain has six stages: report, hold, diagnose, repair or restrict, verify and release. Each stage needs a timestamp and owner. A vehicle with a steering fault may be held from all road use. A vehicle with a failed passenger information display might be held from passenger trips even if it can be moved in a depot. The category depends on actual safety and permit conditions. Make the restriction visible to dispatch and maintenance at the same time.
At diagnosis, retain both the original symptom and findings. A sensor alarm may be caused by a dirty lens, damaged wiring, a software regression or weather outside the operating domain. If staff simply clear the alarm and the vehicle passes a static self-test, that may not address the fault observed on the road. Record what alternative causes were tested and why the team accepted the result. An intermittent defect deserves a defined observation or test plan, not an unexplained close button.
Repairs should be traceable to parts, people and configuration. If a software rollback is used, record its effect on other safety claims and whether the rolled-back version is permitted under the current order and release plan. A repair to one vehicle should prompt a fleet check if the defect may be systemic. Conversely, a fleetwide software update should not be treated as a single vehicle maintenance entry. It needs a distribution and verification record for every affected unit.
Before release, compare the vehicle with its operating permission and current risk assessment. Confirm that the defect was addressed, the verifying test matched the failure mode, all temporary restrictions are removed or explicitly retained, and the person authorised to release has reviewed the evidence. The DVSA guide says the responsible person should access and review the completed safety inspection record before return to service in the commercial fleet context. For a no-driver pilot, build an equally clear review control and ask specialists whether a specific operator-licensing rule also applies.
Keep a record of a refused release. It shows a functioning safety system and prevents a shift change from reviving a vehicle without the missing evidence. If a vehicle is allowed only on a restricted route or with another operating condition, record that condition in dispatch and recheck it at the next shift. A conditional release must be technically enforceable, not hidden in a free-text note.
Join software and physical maintenance records
AV maintenance includes software configuration. The pilot guidance asks for suitable maintenance and software-management procedures and evidence that they work. A software version can change perception, planning, fallback or remote assistance without any physical repair. The vehicle record should show which release was installed, who approved it, test evidence, rollout time, rollback plan and post-release monitoring.
Distinguish three changes. A security patch may affect a support service but not the vehicle's automated behavior. A map update may change route or speed assumptions. A perception-model update may change responses to road users. The same ticket workflow may track all three, but the safety review and authority-notification questions differ. Do not assume a minor version number means minor risk. Ask the engineering team what behavior changed and whether the current evidence covers it.
Tie software to physical sensors and calibration. If a camera is replaced, the software may need a calibration file or test sequence. If a sensor mount is moved, past validation may no longer describe that vehicle. If one computer is swapped, confirm identity, security keys, data and approved image. The release record should identify the exact combination. An operator should be able to reconstruct it after an incident without relying on a supplier's current configuration database, which may have changed.
Logs and health monitoring can support maintenance, but they do not prove every component is sound. Define which faults are automatically detected, how alerts are triaged and which inspections remain manual. A dashboard may show green because a diagnostic service itself is offline. Test that failure mode. Where remote connectivity is lost, define whether a vehicle can complete a trip, stop safely or must not dispatch. The answer belongs to the safety case and operating rules, with maintenance records showing compliance.
Keep the pilot's permissions beside the maintenance evidence
The Vehicle Special Order may exempt a vehicle from a particular rule while imposing conditions. Those conditions can affect equipment, software, markings or operation. A repair that returns the vehicle to a conventional manufacturer's specification may still move it away from the configuration evaluated for the order. Read the signed instrument, not only the workshop manual. If the change may affect an issued condition, seek appropriate authority and legal advice before road use.
Vehicle listing under the Automated and Electric Vehicles Act 2018 and registration details form another part of the record. The pilot guidance says registration details can be updated after listing and that the registered keeper is responsible for notifying DVLA of relevant changes. Do not confuse listing, approval, registration and roadworthiness. A listed vehicle still needs to be maintained. A recent MOT, where required, does not approve an automated-driving system or waive a special-order condition.
An APS permit adds passenger-service conditions. The permit may identify vehicle types, area, service obligations or safety markings. If a substitute vehicle is brought in while another is repaired, check whether the permit and Vehicle Special Order cover it. A fleet number assigned in dispatch does not extend a permit or an order. The operator should have a change-control hold so that the vehicle cannot silently join the passenger service.
Other regimes may apply to a commercial goods vehicle, bus or coach. The DVSA guide has detailed expectations for licensed fleets. The vehicle and service legal specialists should decide which requirements bind the named operator, which are useful guidance principles and which are inapplicable. Do not present every commercial-fleet rule as a universal automated-vehicle statute.
Retain records so a later reviewer can reconstruct the vehicle
The DfT pilot guidance says operators should keep safety inspection and maintenance records for at least 15 months, following DVSA principles. It also expects records of daily activities relevant to roadworthiness and safe carriage. An issued permission, operator licence, insurance matter, investigation or litigation may create longer or different preservation needs. Set a retention schedule by record class after legal and data review. The 15-month figure is a minimum expectation in this guidance, not an automatic deletion date.
Keep inspection results, defects, repairs, software changes and releases linked by vehicle and date. A reviewer should be able to answer: What was installed at 09:00 on a given day? Which checks had passed? Was an unresolved defect open? Who authorised the trip? What changed after the event? The record can live across systems, but the links and access rights need testing. A PDF exported only at the end of a month may arrive too late for an incident investigation.
Preserve failed results as well as passes. A failed brake test followed by a pass tells a different story from a record containing only the pass. Maintain the correction, repeat test and release decision. If a system automatically overwrites the first result, change the process. Correct an error visibly rather than altering history silently. Secure records against unauthorised edits and limit access to personal or security-sensitive data.
The operator should periodically audit a sample from dispatch back to source records. Pick a vehicle and trip, then find the pre-deployment check, open-defect state, current software, latest inspection, order and permit. A second audit can start with a repair and ask whether dispatch respected the hold. These tests expose integration failures between a maintenance system and the actual operation. An elegant dashboard with no reliable handoff is weak evidence.
A usable evidence table
The exact fields depend on the vehicle and permissions. The following table is a design prompt for competent reviewers, not a statutory template.
| Record | What it should establish | Common gap |
|---|---|---|
| Vehicle identity and permission | Which physical unit and current order or permit were used | Fleet nickname without VIN |
| Pre-deployment check | Who or what checked critical items and when | Green status without test scope |
| Defect report | Original symptom, time and source | Fault cleared without investigation |
| Inspection | Items checked, result and competent inspector | Interval copied from another vehicle class |
| Repair and calibration | Work, part, configuration and verification | Supplier invoice treated as proof of safe release |
| Software change | Version, effect, test and rollout | Latest version with no vehicle-level record |
| Hold and release | Restriction, reviewer and evidence | Dispatch enabled before sign-off |
| Retention and retrieval | Record class, location, duration and access | Files inaccessible after supplier change |
Write the operating rule that goes with the table. A red status must block use in the relevant service. An amber status should have a defined restriction, reviewer and expiry. A green status should mean specified controls passed for the specified vehicle and use, not that the entire AV system has been certified. Test those meanings with operations staff, engineers and external maintenance providers.
Where Complys could fit
An operator may need to hold vehicle documents, assign inspections, record defects, track corrective actions and retrieve evidence for audit. Complys can be assessed for those administrative functions in a product demonstration. This page does not claim that Complys diagnoses a sensor, validates a software build, issues an MOT, confirms a Vehicle Special Order condition or automatically blocks a physical vehicle from dispatch. The product owner must verify exact features before publication.
For a demonstration, supply a sample vehicle with an open sensor defect and a pending software update. Ask whether the product can show the two holds, assign reviewers, keep the original report, link verification and export a history for one trip. Ask how it connects to the system that actually controls dispatch and where vehicle telemetry is stored. The AV compliance software overview covers broader buying decisions. The AV checker is a nonbinding regime pointer, not a roadworthiness certificate.
The next useful action is to pick one pilot vehicle and follow its last trip backwards through every check, repair, software change and permission. If a key decision cannot be reconstructed, fix the process before expanding the fleet. Qualified fleet and AV specialists should decide the technical plan and release thresholds for each vehicle.
Complys keeps the records, actions and evidence behind automated-vehicle trials and pilots in one place.
Autonomous vehicle compliance software →Primary sources
- DfT self-driving vehicle pilot scheme applicant guidance, published 31 March 2026: roadworthiness, maintenance and software-management evidence, pre-deployment checks, daily activity records and at least 15 months of inspection and maintenance records.
- DVSA guide to maintaining roadworthiness: inspection, defect, record and return-to-service principles for commercial goods and passenger fleets. Applicability to the actual AV class needs specialist review.
- DfT automated vehicle trialling code of practice, updated 24 June 2026: roadworthiness for supervised public-road trials and vehicle requirements, used only for route comparison.
- Automated and Electric Vehicles Act 2018: self-driving listing context. Verify the actual vehicle and current legal position.