Define and control an automated-vehicle trial's operating domain

A route on a map is only one boundary

A trial team approves a four-kilometre route in dry daylight. The vehicle has been tested at up to 25 miles per hour and a safety driver is trained on its current interface. The next week brings heavy rain, temporary traffic lights and an updated perception model. The start and end points have not moved, but the operating conditions have. The original evidence may no longer support the same public-road run. Someone has to detect the change, decide whether the vehicle remains inside the tested boundary and record any new approval before the trial continues.

The Department for Transport's June 2026 trialling code expects a safety case proportionate to the actual trial, including the vehicle and operational domain. It says organisations should record software versions, progress testing from controlled environments, manage the trial and make sure supervision and fallback arrangements suit the domain. The code defines an automated driving system as potentially working only in specific driving situations, sometimes called an operational design domain. It does not give every project one universal weather threshold, speed or route width.

This page owns the boundary-setting and change decision. The broader trial readiness guide owns the overall launch review. The safety-case guide owns the full claim-to-evidence argument. A separate safety-driver page owns practical intervention competence. The no-safety-driver pilot is a different permission route and may have a domain agreed in its particular vehicle special order. Do not use a supervised trial domain document as proof that a no-driver pilot may operate there.

Write the domain as conditions that can be checked

An operating domain should describe where, when and under which conditions the automated function will be used. Record the named vehicle configuration, roads, lanes, junctions, speed range, weather, lighting, traffic patterns, temporary controls, connectivity and any passenger or freight activity. State whether the function may be engaged during a turn, at a crossing or through roadworks. Define conditions that require a safety-driver takeover or a pause. A statement such as “urban roads in normal conditions” is too vague to guide a driver faced with temporary lane markings and poor visibility.

Use the same language in the safety case, route plan, driver briefing and trial log. If the engineering document says “light rain only” while operations says “rain permitted”, a reviewer cannot tell which boundary governs. When a numeric threshold is useful, explain how it is measured and who monitors it. A wind, visibility or precipitation number copied from another vehicle is not an official requirement for this trial. It needs an engineering rationale and a practical detection method.

Some conditions are difficult to state as a single value. A road may be suitable when visibility is good but unsafe during school arrival because the density and behaviour of road users change. A narrow street may be within the route but obstructed by parked vehicles. A mobile network may work on a survey day and fail during an event. The domain description should include these conditional situations and a conservative response when uncertainty cannot be resolved in time.

Match the map to what the vehicle encounters

Route mapping should mark more than a line between two points. Identify crossings, cycle tracks, bus stops, emergency access, complex junctions, restricted turns, steep gradients, known flooding points and places where the vehicle could stop without creating a new hazard. Record road ownership and any area where a local authority or traffic body has specific interests. A route survey should be dated and linked to the vehicle and software version used for the assessment. If temporary works appear, the team should know which segment and safety claim are affected.

Map accuracy also needs an owner. A change in road layout, signs or speed limits can make a digital map stale even if the trial vehicle is unchanged. The organisation should set a pre-run inspection or intelligence process that identifies material changes, alerts the driver and creates a review item. A map vendor's update notification is useful but may arrive after a roadworks crew has already changed the street. The trial should have a way to stop or return to manual control when the real road differs from its approved description.

Relate every domain limit to evidence

The domain is a statement about where the safety argument is believed to hold. For each material limit, ask what evidence supports it. A dry-road braking test may support one surface condition. Sensor tests in heavy rain may support another, or show that rain must be excluded. A driver's closed-track takeover exercise may support the handover claim at a given speed, but not necessarily at twice that speed in dense traffic. The evidence needs configuration, date and method so the team can judge its relevance.

Do not treat a test kilometre as identical to another. A large mileage total on an easy route cannot replace evaluation of a junction with cyclists, unusual road markings or a school entrance. Conversely, a small but well-designed scenario set may reveal an important limit. The safety team should explain the combination of simulation, bench, private-track and public-road learning that supports each planned expansion. The trialling code recommends staged testing, but it does not prescribe one mileage threshold that makes every route safe.

Record known unknowns as well as tested cases. If the vehicle has not been evaluated around horse riders, identify whether they are likely on the proposed route and what the safety driver must do if one appears. If a traffic-light layout is outside the test set, avoid that junction or add appropriate testing and review. A domain document that only lists successful conditions can hide the reason for a restriction. A well-explained exclusion is part of a credible safety argument.

Decide how the boundary is monitored during a run

An approved domain is useful only if the team can recognise when it is about to be crossed. Specify what the vehicle detects, what the safety driver observes and what an operations team or external service reports. A forecast can guide a start decision, but the driver must respond to actual rain, glare or fog. A geofence can help identify a planned area, but it does not detect a new lane closure. A remote support centre may see vehicle telemetry but not a person stepping into the road. Assign each boundary to a credible observer and a clear action.

The code expects the safety driver to monitor the road and system and be ready to resume control. The organisation should not create a domain monitoring procedure that requires the driver to read a detailed weather display while simultaneously watching traffic. Put non-driving checks with an appropriate support person where possible, and make alerts simple enough for the driver to act on. Test the handover when the system detects a boundary itself and when the driver identifies a condition the system misses.

Define an uncertainty state. If the weather sensor disagrees with what the driver sees or the current roadworks map is stale, a run should not continue under a confident “within domain” status. The procedure might require manual control, a safe stop or a return to base, depending on the vehicle and road. The exact response needs engineering and legal review. The general principle is that an unverified boundary is not an automatic permission to expand the trial.

Change control begins before someone edits a document

A change request should state what is changing and why. It should identify the affected vehicle, route, software, driver training, insurance, public information, authority engagement and legal permissions. Give it an owner and a proposed effective date. A route extension into a neighbouring council area is not merely a map update. A higher speed range may invalidate braking and takeover evidence. A new perception release can affect the behaviour of the vehicle even if the planned road is identical. The project should decide what new testing and external contact each change needs before implementation.

Use an impact matrix rather than an automatic low-risk label. For each change, ask whether the original safety claim still holds, which evidence is superseded and what operating restriction applies while review is open. A software release that fixes one known issue may introduce a new failure mode. A new safety driver may know the route but not the latest interface. A contractor may provide better connectivity but change how incidents are detected. The review should follow the effects, not the change request's title.

The decision record should say who reviewed it, which version of the safety case and domain they used, what was tested, whether an authority or insurer needed to be contacted and when the new boundary becomes operative. If no permission change is needed, record the reason rather than leave an empty field. If the operation is under a particular vehicle special order, permit or service licence, a specialist must check whether the change affects that instrument. For a supervised trial under ordinary law, there may be no generic AV permit to vary, but road, vehicle and service obligations still apply.

Three changes with different answers

Unexpected roadworks on the existing route. The route name has not changed. The works may create temporary lane markings, a person controlling traffic and a changed pedestrian path. If those features are outside the assessed domain, the team should hold automated operation on that segment, use a lawful safe alternative if available and review the safety case before resuming. A driver simply steering around the cones during an automated run is not evidence that the automated function remained within its approved use.

A new software release before a planned event. The release claims to improve cyclist detection. Check its test results, known limitations and any effect on driver alerts or braking. Identify which route hazards and intervention exercises must be repeated. If there is insufficient time for review, retain the old approved build or postpone the run. Do not let a supplier's release note replace the trial organisation's change decision.

Rain begins during a run. If the domain allows only dry roads, the driver and control team should follow the pre-agreed transition procedure. The organisation should not decide on the spot that “light rain is probably fine” because one earlier test happened in drizzle. It may later extend the domain after appropriate testing, driver training and approval. The change should be recorded as a new decision rather than silently added to the original boundary.

These are examples, not universal technical prescriptions. The appropriate response depends on the vehicle, road and evidence, which require competent specialist assessment.

Keep driver procedures and external engagement aligned

The driver's briefing should contain the operating boundary in usable form: route and turn points, when automation may engage, conditions requiring immediate intervention, communications loss procedure and safe places to stop. The safety-driver competence assessment should include domain-related scenarios. A driver who is authorised for an earlier route or software version may need further practice. The organisation should not assume that a general training certificate transfers without review.

The DfT trialling code encourages early engagement with highway and local authorities, police and others affected. A significant route or operating-time change may warrant fresh engagement even if the organisation informed those bodies at launch. If a trial begins carrying passengers or goods, the service licensing analysis also needs to be revisited. Public information should reflect the actual trial area and limits, not an outdated demonstration plan.

Document the handoff between engineering and operations. Engineering may approve a new domain after testing, but the driver, dispatcher and maintenance team need the updated instruction before it becomes live. A release meeting should verify that the approved vehicle has the correct software, the driver has the briefing and the route is not subject to an unresolved change. A signed document in a repository does not by itself update the people controlling the vehicle on the road.

Learn from exits and near misses

Every unplanned exit from the operating domain is information about the boundary. Capture what happened, the vehicle and software version, the route segment, environment, driver action and whether the system issued a warning. Preserve relevant vehicle data securely. The code expects trial data sufficient to determine who or what controlled the vehicle and recommends preserving it after an incident. Data access, privacy and retention require specific review. A generic document system cannot substitute for the vehicle's primary recorder.

Review trends, not only major events. Repeated driver takeovers near one junction may indicate a route hazard or a mismatch between the stated domain and real road conditions. Weather-related disengagements may show that the limit is poorly defined or hard to detect. A single near miss may be enough to pause a segment. Assign an action owner, retest if needed and update the safety argument. Do not wait for a collision before narrowing an unsafe boundary.

The review should distinguish system limitations from operational errors. A driver may intervene because they misunderstood an alert, because the map was stale or because the automated system genuinely could not handle a scenario. Each explanation points to a different corrective action. Blaming every intervention on driver behaviour can conceal a design problem; blaming every one on the system can conceal an unusable procedure. Independent challenge is valuable where the team is tempted to continue without enough evidence.

A compact domain and change record

This table is an internal evidence design, not an official DfT form. The safety case and legal permissions control the actual trial. Avoid turning the table into a tick-box exercise that allows a run when a material domain question is unresolved.

Where Complys may fit

Complys could be assessed for storing a controlled domain document, route versions, driver briefings, change requests and review decisions if its current product demonstrates those functions. The public AV workspace preview is noindex and does not prove that a dedicated operating-domain module is released. There is no verified Complys capability here for live geofencing, weather sensing, vehicle telemetry, remote driving or automatic legal approval. Product-owner demonstration and sign-off are required before any specific feature promise appears in published copy.

Bring a realistic change to a product demo: a new software build and temporary traffic lights on a route used yesterday. Ask how the team would link the change to the affected safety claim, stop an unreviewed run, notify the driver and retain the prior approval for incident reconstruction. If some steps happen in an engineering system, identify the handoff and source of truth. The AV software overview offers a broader buying framework. The AV checker can only give a nonbinding regime pointer, not decide whether a vehicle remains inside a safe operating domain.

The practical next step is to define the proposed domain in terms a driver and reviewer can check, connect each important limit to evidence, and set a change rule before the first public run. A domain that is clear on paper but invisible to the people and systems operating the trial is not an effective boundary.