For a team evaluating an autonomous-vehicle project in Southeast Asia, a factory plan is an incomplete starting point. We recommend running two distinct reviews: whether the vehicle programme can be delivered, and whether the proposed service can be operated within an agreed boundary. Combining them into one regional readiness score hides the questions that a pilot must answer.
Read the evidence at its actual date
The ASEAN Autonomous Vehicle Landscape Report carries a 2023 cover date. Its scope includes cross-border data flows, network connectivity and handovers between people and systems. Use it to identify topics for investigation, not as a current inventory of authorised deployments. ASEAN report, cover and section 2.5
In a written reply dated 7 May 2026, Singapore's Ministry of Transport described deployment assessment using technical performance and public-acceptance metrics before progression to passenger and driverless operations. It identified operation on the actual route without safety-operator intervention and handling traffic scenarios within the authorised geofenced area among the considerations. Singapore Ministry of Transport
That is a dated account of Singapore's approach, not evidence that the same process applies across ASEAN. The following pilot brief is our proposed planning tool, not an authorisation or a vehicle safety standard.
Write the service boundary before the demonstration script
Specify the route, stopping points, intended passengers, operating hours and conditions in which the proposed service will not run. State the role of an onboard safety operator, remote support and any other responsible person without treating those roles as interchangeable.
Then list the situations that would pause the trial. Who makes that decision? How is the vehicle recovered? What does a passenger see while waiting? The engineering and operations teams should agree on these answers before the communications team promises a particular experience.
Separate the cockpit questions by user
A safety operator may need information for supervision or a defined transfer of control. A passenger may need to understand where to board, why the vehicle has stopped and how to ask for help. A service team may need a reliable description of the vehicle's state. Write a separate task and expected response for each role.
Do not assume every AV service has a driver available for takeover. Where a transfer of control is part of the actual design, its interface and timing need to be evaluated against that design. Where it is not, the passenger interface should not imply that an untrained rider must take over driving.
Keep a scenario-to-evidence record
For each proposed scenario, record the starting conditions, expected system state, message or control shown to the user, responsible operator, result and unresolved issue. Candidate scenarios include a blocked boarding point, a service interruption and loss of a passenger-information connection. These examples are planning prompts, not an exhaustive safety test suite.
Evaluate what happened using the exact vehicle and software version tested. A successful run on one route does not, by itself, answer questions about another route or an altered operating model.
Decide what the next trial should prove
The useful output is a bounded pilot brief with named owners and open questions. The factory review can inform vehicle availability and programme timing. The operating review should identify the evidence and local permissions still needed for the proposed service. Keep both visible so that an achievable manufacturing milestone is not mistaken for a completed deployment decision.