Automated Driving Human-Machine Interaction Design Guidelines

For designers, human factors engineers, and systems engineers: let the driver know at all times who is currently driving, how far this system can drive, and when it will be their turn; let every transfer of control have a budget, a basis, and an end state; let there be an already-defined safe destination when the system fails, rather than handing the wheel back to a person who has not had time to prepare.

Automated driving products do not merely present an interface. Driving assistance and automated driving functions execute part or all of the dynamic driving task according to a defined division of labor between human and vehicle, changing the vehicle's physical state and affecting occupants inside the vehicle and road users outside it. Therefore the object of design is not only the instrument cluster and center-console screens, but also how humans and the system divide responsibilities, how control is transferred, what the driver uses to judge the system's state and intent, and where the system takes the vehicle when it can no longer continue.

These guidelines consist of seven principles and 36 rules: principles state the design direction; rules specify applicable situations, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (A4-2 is the second rule under the fourth principle). Each rule must answer three questions: what the design decides, what facts the system provides, and how the user knows the outcome. Filling in parameters, issuing prompts, and actual control taking effect are verified separately.

The same thing is written in only one place. Take "takeover" as an example: how the takeover request escalates in stages, what the system does once the time budget is exhausted, and what evidence the system uses to determine that the person has taken over — these three things belong to the same obligation and are written in the same group of rules (A2-2, A2-3, A2-5); whereas whether the driver is in a state capable of taking over when the takeover request is issued is an obligation on a different object of regulation, and belongs to A3.

These guidelines constrain the nature of the experiential commitments a product makes to the driver and occupants and the mechanisms that fulfill them; they do not presuppose a single technical architecture, and do not specify a concrete sensor scheme or algorithm form.

These guidelines are not a safety case, nor do they constitute type approval. They do not replace ISO 26262 (functional safety), ISO 21448 (safety of the intended functionality), UN R155/R157, or the admission requirements of each jurisdiction, nor do they replace dedicated assessments of accessibility, privacy, data compliance, and product liability. The main text of these guidelines does not restate the specific values of regulations — quantities such as time windows, speed ranges, and deceleration upper bounds vary by jurisdiction and regulatory version; the main text requires clear applicable scenarios, timing, and verification basis. Concrete values are carried in Design Token.md, separately constrained by the applicable regulations, the chosen evaluation, and product verification. A longer takeover time is not necessarily safer — the budget is also limited by the system's remaining controllable time. For sources and verification status see reference.md.

The full text has four chapters: Chapter 1 principles, Chapter 2 how to read and quick-reference the rules, Chapter 3 rules in detail, Chapter 4 terminology; applicability, items pending verification, the verification checklist, and application examples are in Appendices A–D.

---

First determine the applicable level and operating role¶

These guidelines discuss the human-machine interaction of both driving assistance and automated driving; "automated driving" in the title does not mean every function belongs to an ADS. Before applying the rules, the applicable scope MUST be determined by function, mode, operational design domain, and sales jurisdiction; a single level label must not be attached to the whole vehicle and then have every rule applied to it.

Terminology basis: SAE J3016 official scope statement, NHTSA levels explanation; China projects additionally check GB/T 40429-2021. These materials do not directly determine legal liability for traffic accidents. UN R157 applies only to the ALKS it covers and cannot serve as a common admission basis for all L2–L5 functions; the relevant basis for L2 DCAS is listed separately as UN R171; for fully automated vehicles see also the applicable EU ADS regulation.

In A2, "takeover request" by default refers to the system requesting the person to take over the complete driving task. L2 reminders and active-safety interventions use their own response definitions; A4's system minimal-risk requirement applies to the modes that carry that capability, and does not thereby require every low-level assistance function to independently stop the vehicle.

1. The seven principles¶

The seven principles divide design responsibility by object of regulation: each principle governs obligations on one category of object, and each rule belongs to the single principle matching the direct object of regulation of its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the division and the way the division is tested.

A single scenario can touch multiple principles — a single takeover timeout simultaneously involves the transfer's time budget (A2-2), the determination of driver state (A3-2), and the execution of the minimal-risk strategy (A4-1) — this is not a classification error: the three rules constrain obligations on three different objects of regulation. Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts established merely by asserting them: when a rule's addition, removal, or attribution is in doubt, the test is to have different reviewers independently judge the attribution of a specific requirement and see whether they reach similar results; if the test fails, what is revised is the principle's division, not an added layer of explanation.

Principles are used to understand the rules and adjudicate attribution; they are not themselves a separate item for judgment. When interpretation of a principle conflicts with a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

A rule having a single attribution does not mean a mechanism cannot be reused. Driver-state monitoring is both A3's direct object and an input to A2-6's judgment of "whether a transfer can be made" and a condition triggering A4-1's minimal-risk strategy; the same multimodal alert channel carries both A2-3's takeover escalation and A5-2's intent expression — mechanisms are naturally multi-purpose; obligations each stay in their own place.

2. How to read the rules¶

2.1 The structure of each rule¶

Summarized in one sentence, the force of each part: the rule text specifies the requirement; Applies to and Boundary conditions together bound the requirement's scope; Basis and force states where the requirement comes from; Design application, Verification examples, and Counterexamples add no separate obligation.

Rules write the nature of the behavior, not the implementation: that a takeover request must escalate in stages and enter a defined end state when the budget is exhausted is product behavior; which sensor determines whether hands are on the wheel, and which CAN message triggers the degradation, is an engineering solution — the two must correspond, but they are not the same deliverable.

2.2 Normative terms¶

The rule text uses three levels of normative terms:

• MUST: not satisfying it means non-conformance with these guidelines. Without it, some commitment made to the driver or occupants would fail under a foreseeable situation.
• MUST NOT / forbidden: the inverse expression at the same strength as "MUST," identifying behavior that must not occur; in the main text, the wordings "must not" and "forbidden" are used interchangeably and carry equal force.
• SHOULD: followed by default; when there is genuine reason to deviate, record the rationale and the alternative, and accept the same verification. Deviation needs no approval, but it needs a record. "SHOULD NOT" is the inverse expression of "SHOULD."

Conformance judgment takes the independent obligation clauses in the main text as its unit: a declarative sentence without a normative term carries the strength of the rule heading it sits under; a clause with an explicitly marked normative term is judged at its own strength — a "forbidden / must not" clause inside a SHOULD rule remains a hard constraint. The wording "cannot" in the main text is used only for statements of capability or fact (e.g., "cannot guarantee that the driver has regained situational awareness"), never to express an obligation.

Strength indicates binding force, not importance: "MUST" determines whether the product can be delivered under these guidelines at all; "SHOULD" often determines whether the system is actually good to use, or gets turned off.

2.3 Basis and force¶

Automated driving design requirements need their sources distinguished: the same requirement might be a hard regulatory figure, might be a scoring item in an evaluation protocol, might be a research conclusion, or might be a commitment the product makes on its own — these four carry different force, and the cost of changing them is completely different. Writing them together causes two typical accidents: treating a regulatory floor as a parameter the product is free to calibrate; or treating a self-made commitment as a regulatory obligation, locking down the design space where there was no need to.

Every rule therefore is annotated with a basis and force, taking one of four values:

The normative term and the basis annotation are two orthogonal attributes; they do not form a hierarchy. The normative term answers "does failing to satisfy it count as non-conformance with these guidelines"; the basis annotation answers "does this requirement carry force outside these guidelines." A rule sourced as [Commitment] can perfectly well be marked "MUST" — meaning: as soon as you claim to follow these guidelines, this one is hard, even though no regulation forces you to.

A rule may carry multiple annotations (e.g., [Regulation][Commitment]); it MUST state which part has an external basis and which part is an extension by these guidelines — a single regulatory citation must not vouch for an entire self-made requirement. Having read a historical version does not mean current-validity and jurisdictional-applicability verification has been completed. When a source offers only a table of contents or an abstract, it supports only scope judgment, not a specific obligation. The sources, versions, and verification status of every annotation are in reference.md; for a source not annotated with verification status "original text read," the original text MUST be checked against before implementation.

2.4 The two sides of counterexamples¶

Counterexamples have two sides: "under-delivery" is missing this requirement; "over-delivery" is piling on alerts, confirmations, and degradations in order to satisfy it. Both sides count as getting it wrong. In this domain, the consequences of "over-delivery" are no lighter than those of "under-delivery": excess alerts create alarm fatigue, causing the one takeover request that truly matters to be ignored; overly conservative degradation teaches the driver to route around the system or simply turn it off — a safety function that has been turned off has zero safety benefit.

2.5 Rule quick reference: 36 rules¶

The table below is the one-sentence memorable version of every rule. The quick reference does not replace each rule's applicability conditions and complete requirements; judgment is based on the main text.

A1 Mode is mutually understood

A2 Control authority has an owner

A3 Driver state is an input

A4 Degradation has an end state

A5 Evidence calibrates trust

A6 External impact is accounted for

A7 Governable over the long term

---

3. Rules in detail¶

3.1 A1 Mode is mutually understood¶

Keep the driver aligned with the system on "what mode is it right now, how far can this system drive, when will it be handed back to me." The core failure this principle targets is not a misunderstood intent, but mode confusion — the person thinks the vehicle is driving, the vehicle thinks the person is driving.

A1-1Mode is unique and continuously discernibleMUST¶

In one sentence: At any moment there is only one mode in effect; the state is persistent, not a fleeting prompt.

Applies toproducts offering more than one driving-automation mode, or where the same function has multiple states such as enabled, standby, and degraded.

RuleAt any moment there MUST be one and only one driving-automation mode in effect, and that mode's current state MUST be continuously discernible; it MUST NOT be indicated only once, at the instant of switching. The mode indicator MUST appear where it is reachable within the driver's normal driving field of view; when a product uses multiple displays, the mode representation across all displays MUST be consistent, and conflicting state displays are forbidden. Mode name, function availability, and current control ownership MUST be judged separately: available does not equal activated; requesting activation does not equal the system having taken over. When facts are stale or the display link is interrupted, the system MUST indicate that state cannot be confirmed and execute the defined display degradation; it MUST NOT hold the last frame to sustain an impression of "working normally." The activation and deactivation of sub-functions (e.g., the combination of adaptive cruise and lane centering) MUST be consolidated into expression through a defined set of modes; the driver MUST NOT be left to infer the current mode by logically combining the states of several independent switches.

Boundary conditionsThis clause does not require the mode indicator to occupy a fixed, large area, nor does it require a distinct color scheme per mode; what it requires is "confirmable with a glance at any time," with the concrete form left to the product. A brief transitional state (e.g., activating, exiting) may exist, but it MUST be explicitly expressed as a transitional state, and MUST NOT appear as if two modes are in effect simultaneously.

Basis and force: [Regulation] UN R171 §5.5.4.1 imposes requirements on state and information expression for applicable DCAS; the ALKS requirements of UN R157 still await verification against the original text. [Commitment] Cross-display consistency and unified mode consolidation are explicitly proposed by these guidelines. S04, S05.

Design applicationPlace the mode indicator in a persistent location on par with the speed display; express state through a combination of shape, position, and text, not relying on color alone; give a combined function a name the user can say out loud, rather than making the person read three icons and perform a logical AND.

Verification examples

• User side: interrupt at random during driving and ask the driver to say in one sentence who is currently responsible for steering and who for speed; failing to answer or answering incorrectly counts as a fail.
• Implementation side: verify that mode state is driven by a unified state source, with multi-screen rendering drawn from the same ground truth; inject display-link latency or a single-screen fault, and verify that no inconsistency between two screens' states occurs without any indication.

CounterexamplesUnder-delivery — lane centering is silently degraded to lane-keeping only, with no persistent difference anywhere on the instrument cluster; over-delivery — every mode change triggers a full-screen takeover graphic that is forced to stay for several seconds, distracting the driver who is trying to see the road clearly.

A1-2The operational design domain is knowable in advanceMUST¶

In one sentence: Let the driver know, before using it, under what conditions this system can and cannot be used.

Applies toproducts whose functions have operational-design-domain limits, i.e., unavailable or degraded on certain roads, weather, lighting, speeds, or geographic ranges.

RuleThe product MUST state each mode's operational-design-domain boundary in a way the driver can understand, and MUST make that statement re-checkable in the vehicle (see A5-1 for the re-check entry requirement). The system MUST be able to tell, before activation, whether the current situation meets the conditions; when it does not, it MUST state which category of condition is missing, and it is forbidden to display only "currently unavailable" without a category. When the operational-design-domain determination depends on external data (maps, weather, construction information), the freshness requirement for that data MUST be defined, and it is forbidden to use data beyond its freshness window to judge availability. Dependent conditions MUST be continuously re-checked during operation; an unknown condition MUST NOT default to "met" — the defined re-check or degradation MUST be executed. Short-term fluctuation may use a substantiated persistence judgment or recovery hysteresis, but debouncing MUST NOT be used as a reason to delay a risk-reducing action that has already become necessary.

Boundary conditionsThis clause does not require complete disclosure of internal determination logic or sensor thresholds to the driver, nor does it require every boundary case to be enumerated; what it requires is that the driver form a roughly correct expectation of availability. The product may disclose only the categories that affect the usage decision.

Basis and force: [Regulation] China projects reference the system-boundary, safety-response, and disclosure requirements of MIIT Liantongzhuang [2025] No. 45, Part 2 (1). [Practice] The L3Pilot CoP-ADF framework lists ODD and user-understanding themes; the specific question cards still await close reading. [Commitment] Gating on external-data freshness is a concretization requirement of these guidelines. S07, S12.

Design applicationReduce "why can't it be used right now" to a small number of clearly statable categories — road type, weather and visibility, lane-marking quality, speed range, geographic range; replace repeated failed attempts throughout the trip with a pre-trip availability preview.

Verification examples

• User side: have drivers who have never read the manual state the reason category in three typical unavailable scenarios, and check whether it matches the system's determination.
• Implementation side: set map or weather data to stale, and verify the system refuses to judge availability from it rather than continuing to permit use with old data.

CounterexamplesUnder-delivery — the function silently becomes unavailable in rain, and the driver repeatedly presses the activation button without getting any reason; over-delivery — a long list pops up before activation requiring item-by-item confirmation, and the driver dismisses it every time before setting off.

A1-3A foreseeable exit is announced in advanceMUST¶

In one sentence: Before exiting, announce it first; the announcement says "about to," not "already."

Applies tosituations where the system can determine in advance that it is about to leave the operational design domain, such as approaching a ramp, entering a construction zone, a change in road classification, or a geofence boundary.

RuleFor a foreseeable exit from the operational design domain, the system MUST issue advance notice before the exit occurs, and MUST define the minimum lead time for that notice. The wording of the notice MUST point to "about to exit" and the driver preparation needed, and it is forbidden to substitute a post-exit notification for a pre-exit notice. Between when the notice is issued and the actual exit, the system MUST maintain the declared available control; if capability further declines during that interval, it MUST transition into the defined degradation path and disclose it — capability that can no longer be supported MUST NOT be maintained merely to honor the notice. A sudden failure that cannot be predicted in advance is not covered by this clause; handle it per A4.

Boundary conditionsThis clause does not require the same lead time for every exit — the predictable duration naturally differs by trigger condition; what it requires is that every category of foreseeable exit has a defined, published minimum lead time. The concrete value of the lead time MUST NOT be lower than the floor set by the applicable regulation (the value is carried in ad.mode.exit.advance_notice).

Basis and force: [Commitment] Lead time for the notice is defined per foreseeable event category. [Regulation] The applicable UN R157 transition timing for ALKS must be separately verified; this source has not yet had a readable original text obtained, and seconds values are not filled in from secondhand paraphrase. S05.

Design applicationDistinguish the notice from the takeover request — the notice is "the road ahead is about to change, get ready," the takeover request is "please take over now"; their channel, wording, and urgency should differ, so the driver does not treat every notice as an emergency.

Verification examples

• User side: interrupt between when the notice is issued and the actual exit, and ask the driver to say how much time remains and what needs to be done.
• Implementation side: iterate through the trigger conditions for every category of predictable exit, and verify the actual lead time is not less than the declared value; verify that the function is not silently weakened during the notice period.

CounterexamplesUnder-delivery — the vehicle only prompts "function has exited" once it reaches the ramp; over-delivery — every minor confidence fluctuation is turned into a notice, and the driver learns to ignore it amid a stream of notices.

A1-4Activation and exit require an unambiguous action and an acknowledgmentMUST¶

In one sentence: Don't let an ambiguous action turn on automated driving, and don't leave the person not knowing when it turned off.

Applies toall driving-automation functions that the driver can start and stop.

RuleActivation MUST be triggered by an unambiguous, dedicated driver action that is not easily triggered by mistake; it is forbidden for a single action that could stem from another intent to directly activate it. Every activation and exit MUST produce an acknowledgment, and the acknowledgment MUST include what happened and who triggered it (driver action, system determination, or an external condition). When the system exits on its own initiative, the acknowledgment MUST state the reason category. Mode switching MUST have a perceptible acknowledgment; the division of labor MUST NOT be changed only in the background. An acknowledgment having been issued does not equal proof that the driver understood it.

Boundary conditionsThis clause does not require activation to be multi-step confirmation; a dedicated control plus one clear state acknowledgment is sufficient.

On recovery-type operations: Only when this mode and this input type inherently permit recovery, and the recovery does not add unaccepted responsibility onto the driver, may repeated information be simplified, but the recovery itself MUST remain discernible. "Can the acknowledgment be simplified" and "can it auto-recover" are two different questions, and the former does not presuppose the latter: a brake override that, under the applicable rule, needs an independent driver action to recover, MUST NOT auto-recover. Input override, assistance deactivation, and reactivation MUST be defined separately — different pedals and different modes do not share a single recovery logic.

Basis and force: [Regulation] The applicable DCAS brake-override and recovery conditions are in UN R171 §5.5.3.4.1.1, and are not extrapolated to every mode or pedal input. S04. [Commitment] Unambiguous action, acknowledgment, and discernible recovery are proposed by these guidelines; the concrete conditions for ALKS are verified separately.

Design applicationSeparate the physical control for activation from adjustment-type controls; let the acknowledgment carry part of its meaning through a non-visual channel first (a tone or steering-wheel haptics), so the driver can confirm without looking away.

Verification examples

• User side: after the system exits on its own initiative, ask nothing, and observe how long it takes the driver to realize they are now driving fully manually.
• Implementation side: enumerate every input path that could possibly trigger activation, and verify there is no path that could be accidentally activated by an action stemming from another intent.

CounterexamplesUnder-delivery — one direction of a stalk simultaneously handles cruise resume and automated-driving activation, and the driver does not know after mis-triggering it; over-delivery — every activation requires a second confirmation popup, forcing the driver to look down while pulling away.

A1-5Naming and claims do not exceed actual capabilityMUST¶

In one sentence: Names and marketing are also interface; the mental model they shape gets cashed out on the road.

Applies tofunction naming, interface copy, marketing materials, sales talk, and the owner's manual.

RuleFunction naming and external claims are forbidden from implying capability beyond the actual automation level. For an L2 function that requires continuous monitoring, it must not be implied that road monitoring can be left off; for an L3 function that requires fallback-user intervention, it must not be implied that taking over is never needed. The function names and capability descriptions in the interface, marketing, sales talk, and manual MUST be mutually cross-checkable; names across different channels MUST resolve to the same function, ODD, and division-of-labor version.

Boundary conditionsThis clause does not forbid the use of a branded name, nor does it require the automation level to be included in the name; what it requires is that the name and accompanying description do not create expectations beyond actual capability.

Basis and force: [Regulation] China projects reference the marketing and promotion standard requirements of MIIT Liantongzhuang [2025] No. 45, Part 4 (9). [Commitment] Cross-channel and cross-capability-version consistency is proposed by these guidelines; other jurisdictions need a separate, specific basis listed. S07.

Design applicationMaintain one "capability one-liner" per function, used simultaneously for the interface subtitle, the manual's opening paragraph, and sales materials; hold the name review and the operational-design-domain review in the same meeting, avoiding naming first and backfilling capability later.

Verification examples

• User side: show someone who has never encountered the product only the name and marketing copy, ask them to describe what the system can do and what they themselves need to do, and compare the gap with actual capability.
• Implementation side: check whether the capability statements in the interface name, manual, official website, and sales materials resolve to the same capability description and version.

CounterexamplesUnder-delivery — an assistance function that requires full-time monitoring is named in a way that implies monitoring is not needed; over-delivery — the name is so long it takes three lines to figure out what the function is, and the driver cannot find it in the menu.

3.2 A2 Control authority has an owner¶

Let "who is driving" have a definite answer at any moment, and let every change of that answer be a transfer with a budget, a basis, and an end state. A transfer has a hard time budget; waiting is not free.

A2-1Division of labor and responsibility is explicitMUST¶

In one sentence: Under each mode, who is responsible for lateral control, longitudinal control, road response, and failure fallback is written out separately and clearly.

Applies toall driving-automation modes.

RuleThe product MUST clearly define, for each mode, the ownership of four items — lateral control, longitudinal control, object and event detection and response (OEDR), and dynamic-driving-task fallback — and MUST list emergency safety intervention during imminent collision separately. It is forbidden to merge general road monitoring, post-failure fallback, and momentary AEB intervention into a vague "emergency response." The division of labor MUST be consistent with the function's automation level and MUST be presented in a way the user can understand (see A5-1). L4/L5 occupants are not the default fallback user; the role of remote personnel is defined separately per A2-7.

Boundary conditionsThis clause does not require the interface to continuously display a complete table of the four items of division of labor; what it requires is that this definition exists, is consistent, and is findable by the driver. Everyday presentation may be condensed to one sentence.

Basis and force: [Practice] SAE J3016 is a Recommended Practice for levels and terminology and cannot be marked as Regulation; the current evidence is its official scope statement, cross-checked against NHTSA's official levels explanation. L3Pilot provides a development-check framework. [Commitment] Turning the division of labor into a unified, re-checkable product definition. S01, S02, S12.

Design applicationTurn the four items of division of labor into one product-definition table, jointly referenced by naming, the manual, interface copy, and test cases, avoiding each place writing its own version.

Verification examples

• User side: ask the driver to judge "in this mode, can I take my eyes off the road," and check whether the answer matches the declared level.
• Implementation side: check that each mode's definition of the four items of division of labor, the actual control-authority allocation, and the externally declared level are mutually consistent.

CounterexamplesUnder-delivery — the product claims driver monitoring is required, but the interface permits and encourages prolonged in-cabin entertainment operation; over-delivery — the division of labor is turned into a matrix diagram on the home screen that must be read cell by cell.

A2-2A transfer has a direction, an initiator, and a time budgetMUST¶

In one sentence: Every transfer must define who initiates it, how much time is given, and what happens when time is up.

Applies tocontrol-authority transfer between any two modes, including human→vehicle, vehicle→human, and switching between automation modes.

RuleThe product MUST define, for every reachable transfer path, the direction, initiator, preconditions, the start point of timing, the time budget, the completion criterion, and the behavior when not completed, and MUST give every path a stable identifier, with its timing and completion strategy bound to that identifier — the same source mode and the same trigger reason may have multiple targets, and the budget MUST NOT be matched by mode name alone. The time budget is typed by direction and MUST NOT be mixed: human→vehicle activation and switching between automation modes use a "processing deadline"; a system-requested vehicle→human transfer uses a "takeover budget"; a driver-initiated input uses an "effective-in deadline"; the minimum preparation duration for the human→vehicle direction is a floor, and MUST NOT be treated as the longest response budget. A path that takes effect immediately must state the verification boundary and source of its "takes effect promptly," and waiting MUST NOT be artificially added just to fill in the table; it is forbidden to leave the budget unfilled. When human→vehicle activation fails, the original division of labor MUST be preserved and the failure MUST be stated; it is forbidden to display that activation has succeeded. When switching between automation modes fails, the system MUST remain in the still-valid original mode or enter a validated degradation path. When the system requests a vehicle→human transfer, the budget, the control that can be maintained during the interval, and the disposition for no response MUST be defined by trigger reason; a path requiring system fallback MUST point to a strategy and target already defined by A4, and it is forbidden to infer that the person has taken over merely from a timeout, or to release control with no strategy. Preparation time, remaining controllable time, escalation, and fallback execution MUST be verified on the same trustworthy timeline. The budget MUST simultaneously satisfy the applicable timing constraint, human-factors verification, and the system's remaining controllable time; when no feasible window exists, the operating conditions or the fallback design MUST be adjusted — it is forbidden merely to extend the countdown, since a longer countdown by itself does not constitute greater safety.

Boundary conditionsL2's grip, gaze, and direct-control alerts are modeled separately, and do not reuse L3's mental model of "only needing to take over after a request"; L2 supervision, L3 fallback, and L4/L5 occupant requests are each based on their own division of responsibility, and do not share a single default transfer assumption. Emergency collision avoidance, serious faults, and routine ODD exit cannot share undifferentiated timing parameters; emergency handling MUST NOT be delayed to wait for the complete transfer process.

Basis and force: [Regulation] The applicable UN R157 timing for ALKS still requires verification against the original text; L2 DCAS alert types are in UN R171 §5.5.4.2. [Commitment] Failure outcomes and budget-feasibility checks are defined separately by direction. S05, S04.

Design applicationBind every edge of the transfer matrix to a trigger reason, a budget, and an outcome. Unreachable edges are explicitly disabled; a failed activation returns to the original division of labor; planned exit and emergency failure use their own timing configurations.

Verification examples

• User side: compare takeover time and control quality across expected versus unexpected requests, different secondary tasks, and long-term users, not just measuring the average reaction time.
• Implementation side: iterate through the allowed and forbidden edges, injecting activation failure, budget exhaustion, and mid-switch faults respectively, and check that the outcome, the record, and the interface's division of labor are consistent.

CounterexamplesUnder-delivery — after timeout the system directly releases control and honks, handing a vehicle still traveling at its original speed to a person who is still looking down; over-delivery — the budget is set extremely long in pursuit of "greater safety," and the system continues driving longer while already knowing it cannot handle the situation.

A2-3The takeover request escalates in stages and uses more than one channelMUST¶

In one sentence: The takeover request intensifies over time, and cannot rely on looking at a screen alone.

Applies tovehicle→human takeover requests.

RuleWhen the system requests a vehicle→human takeover, it MUST define the trigger timing, channels, and semantics of staged escalation, using at least two sensory channels including a non-visual one. The escalation strategy MUST be determined by the applicable regulation and the risk situation, and MUST NOT obstruct an urgent alert by playing through a fixed sequence of stages. Media, incoming calls, and do-not-disturb MUST NOT block a takeover request; when multiple safety alerts occur concurrently, arbitrate per A5-6, and it is forbidden to suppress a more urgent collision warning on the grounds of "takeover takes priority." A takeover request MUST NOT be turned off by an ordinary preference setting.

Boundary conditionsThis clause does not specify which concrete channels to use; the combination of haptic, auditory, and restraint-system channels is a product decision. This clause does not require every stage to add a new channel, but does require that the urgency of an effective escalation be distinguishable; a concurrent, more urgent warning is still handled per A5-6.

Basis and force: [Regulation] The applicable modality and escalation requirements for ALKS need verification against the UN R157 original text. [Practice] NHTSA DOT HS 812 555's Multimodal Messages discusses multi-channel alerts. [Commitment] This clause's two-channel floor and A5-6's conflict handling are product requirements, and are not generalized into a regulatory requirement for every L2 grip reminder. S05, S11.

Design applicationReserve dedicated haptic and auditory patterns for the takeover request, not reused by any other notification (see ad.notify.haptic.reserved for the reservation relationship); the escalation's physical intensity increases, so the driver knows it is more urgent without needing to interpret the content.

Verification examples

• User side: have participants engage in typical secondary tasks (phone, eating, talking with rear-seat passengers) with media volume set to their usual maximum, and measure the distribution of time from the first-stage request to an effective response, not just the mean.
• Implementation side: verify that the takeover request is still issued through the defined channels and timing when do-not-disturb is active, during a call, or when rear-seat entertainment occupies the audio channel.

CounterexamplesUnder-delivery — the takeover request is only a red icon on the instrument cluster while the driver is looking down at their phone; over-delivery — every minor drop in confidence triggers seat vibration and a beep, and the driver eventually turns the system off.

A2-4Human input is always recognizedMUST¶

In one sentence: Steering and braking can be recognized under any mode; the way to exit needs no learning.

Applies toautomation modes equipped with driving controls that allow in-vehicle driver control. Driverless products with no driving controls use A4-5's occupant stop-request and help-seeking flow.

RuleThe driver's steering, braking, and acceleration inputs MUST be recognized by the system under any mode, and MUST be handled per their declared semantics; the semantics corresponding to each input type (override control, temporary intervention, adjustment, or permitted non-execution) MUST be defined in advance and be queryable; a brake or steering override that must take effect MUST NOT be configured as ineffective. At least one exit method MUST be one the driver can complete without consulting any instructions. It is forbidden to require the driver to go through a combined operation, a menu hierarchy, or a long-press sequence to exit automated driving. When the system suppresses driver input due to a safety mechanism such as stability control, the scope and conditions of the suppression MUST be defined in advance, and it is forbidden to silently weaken driver input under an undefined circumstance.

Boundary conditionsThis clause does not require every slight steering-wheel torque to be judged as a takeover — a false-positive takeover is equally dangerous; what it requires is that the determination threshold and semantics be defined and published, and that a no-learning-required exit path exist.

Basis and force: [Regulation] UN R171 §5.5.3.4 specifies the applicable DCAS driver-override semantics; ALKS is separately checked against UN R157. [Commitment] These guidelines require every provided input path to have clear semantics, and do not infer that the entire transfer is complete merely from "the input was recognized." S04, S05.

Design applicationUse a path that matches existing driving habits, such as "pressing the brake exits," as the no-learning-required one; physically separate adjustment-type operations from takeover-type operations to reduce semantic confusion.

Verification examples

• User side: have untrained drivers exit automated driving while underway, and record the success rate and time taken on the first attempt.
• Implementation side: iterate through input types and magnitude ranges, and verify that every one falls within a defined semantic, with no undefined range.

CounterexamplesUnder-delivery — exiting requires finding a second-level menu on the center screen; over-delivery — any tiny disturbance on the steering wheel is judged a takeover, and the system repeatedly exits on bumpy roads.

A2-5Transfer completion is judged by evidenceMUST¶

In one sentence: A countdown reaching zero does not mean the person has taken over.

Applies tovehicle→human transfers.

RuleWhen the system requests a vehicle→human transfer, it MUST define and record verifiable takeover evidence, and it is forbidden to judge completion solely from a countdown, a button confirmation, or hands on the wheel. The criterion MUST cover effective control and available attention-recovery evidence, and MUST state what conclusion the sensors can actually support; eyes returning to the road does not equal proof of complete situational awareness. When evidence is insufficient and the budget is exhausted, execute A2-2's defined disposition, and it MUST NOT be recorded as a successful transfer. Driver-initiated override inputs such as steering and braking MUST still be handled promptly per A2-4, and MUST NOT be blocked while waiting for a monitoring conclusion when the operation should lawfully take effect. Control override, assistance exit, transfer success, and post-event control quality MUST be recorded separately.

Boundary conditionsThe two-class evidence is used for the product's completion criterion for a system-requested transfer; it does not replace a jurisdiction's specific provisions on braking, steering, and deactivation, nor does it prove that legal liability for an accident has transferred. When risk remains after the driver's active override, respond per the applicable safety strategy.

Basis and force: [Practice] The ISO/TR 21959 series covers topics related to takeover state and experimental design; the current evidence includes only the official table of contents, and it is not used as a source for a specific criterion. [Commitment] The two-class evidence, event distinction, and non-blockable effective override are proposed by these guidelines and require project-level verification. S16.

Design applicationExpress "your action has been responded to," "assistance has exited," and "the takeover process has ended" separately, giving the corresponding acknowledgment only when it has actually occurred; stop a takeover announcement that is no longer needed, while retaining still-relevant risk prompts.

Verification examples

• User side: compare the time gaps among hands-on, gaze recovery, understanding of the traffic situation, and stable control, to test whether the completion criterion misjudges.
• Implementation side: a single class of evidence MUST NOT be recorded as a complete successful transfer; also verify that active braking and steering overrides are not blocked while waiting for the second class of evidence.

CounterexamplesUnder-delivery — detecting steering-wheel torque alone is judged a successful takeover, clearing all alerts; over-delivery — the alert continues even after the driver has clearly taken over and controlled the vehicle for several seconds, interfering with their handling.

A2-6Do not transfer to a person who is not in a condition to take itSHOULD¶

In one sentence: Don't throw the wheel at someone who isn't in a fit state — that isn't a transfer, it's abandonment.

Applies tomodes that have system-fallback or driver-no-response handling capability, where the driver has been confirmed unable to intervene effectively.

RuleOnce the driver has been confirmed unable to intervene effectively, the system SHOULD choose the fallback path permitted by its capability and the applicable rules, and not treat a formalized takeover confirmation as a safety measure. Releasing control merely because the request has finished playing is forbidden. Whether to enter failure handling early MUST satisfy the applicable regulation's trigger and timing conditions; a single microsleep, a drowsiness prompt, or an unknown monitoring state MUST NOT directly substitute for a no-response confirmation. The alert SHOULD state the current action; the human's recovery and active override are still handled per A2-4 and A2-5.

Boundary conditionsDetection and handling of drowsiness, microsleep, sleep, and no-response may differ; "non-transient" does not automatically equal an immediate stop. When monitoring is uncertain, restrict the capability that depends on that conclusion per A3-3; driver readiness MUST NOT be fabricated.

Basis and force: [Evaluation] Euro NCAP Driver Engagement §1.4 and Assisted Driving §4.2.3 distinguish driver state from no-response handling. [Commitment] Avoiding an ineffective transfer of responsibility is a requirement of these guidelines; the evaluation response is not written into a universal obligation to immediately initiate an MRM. S08, S09.

Design applicationWire "driver state" into the transfer matrix as an explicit input to the transfer decision, rather than letting it only drive an alert.

Verification examples

• User side: in a simulated no-response handling scenario, verify that occupants understand the vehicle's action and how to seek help.
• Implementation side: inject brief distraction, drowsiness, microsleep, unknown monitoring state, and confirmed no-response respectively, and confirm that the trigger and timing match their respective definitions.

CounterexamplesUnder-delivery — a takeover request is issued to a driver already determined to be asleep, and control is released after timeout; over-delivery — a single brief glance down triggers the minimal-risk strategy, and the vehicle needlessly slows and pulls over under normal road conditions.

A2-7Remote assistance does not impersonate driving takeoverMUST¶

In one sentence: Someone helping remotely does not mean someone is driving remotely.

Applies toproducts offering remote advisory, occupant support, remote parking, or remote-driving capability.

RuleThe product MUST distinguish remote advice, service communication, and direct vehicle control, clearly stating what each role can observe, propose, and execute, and the behavior on authorization and loss of connection. Remote advice MUST be re-checked by the vehicle against its current state and operating constraints; a stale piece of advice MUST NOT be executed directly. If direct remote driving is provided, the operator's qualifications, connection conditions, ownership of control, takeover acknowledgment, and disconnection handling MUST be separately defined. An occupant's customer-service call, stop request, or a single confirmation MUST NOT be interpreted as granting remote-driving authorization; waiting for a remote response MUST NOT delay a necessary vehicle-side risk-reducing action. A remote request and its acknowledgment MUST be tied to the vehicle, the current control session, and the specific request; a repeated request MUST NOT re-trigger the action, the current state MUST be re-checked after reconnection, and it is forbidden to replay a driving instruction that has already expired. When multiple parties request control at the same time, the single valid source of control MUST be determined by already-defined authorization and arbitration rules; customer-service authority MUST NOT be extended into control authority.

Boundary conditionsThis clause does not require the product to provide remote driving. A product that only offers remote advice must not state on the interface that "the remote driver has taken over"; where this capability does not exist, record it as not applicable.

Basis and force: [Practice] Waymo's public operational description distinguishes remote assistance from control; the current evidence covers only the visible page summary, and the full technical mechanism is not inferred from it. [Commitment] Authorization, advice freshness, disconnection handling, and acknowledgment requirements are proposed by these guidelines. S14.

Design applicationDisplay "contacting support," "connected to support," and "the vehicle is executing the stop request" separately, each corresponding only to a fact that has actually occurred.

Verification examples

• User side: have the occupant state who is currently controlling the vehicle, confirming that a customer-service connection is not misunderstood as a driving takeover.
• Implementation side: inject remote-response timeout, resending of stale advice, location change, and connection interruption, and verify the vehicle side does not wait on guidance that has lost its validity.

CounterexamplesUnder-delivery — connecting to customer service alone displays "human driving in progress"; over-delivery — every routine path choice waits for remote confirmation.

3.3 A3 Driver state is an input¶

Design human availability as an input quantity to the system, not as an assumption that holds by default. This principle's object of regulation is the driver's attention, impairment, and response capability itself — it is both monitored and used as a basis for judgment in A2 and A4.

A3-1Monitoring capability is proportionate to the automation levelMUST¶

In one sentence: If the human is to serve as fallback, the system must actually know whether they are in a fit state.

Applies toany mode that requires the driver to bear monitoring or emergency-fallback responsibility.

RuleWhen a mode requires the driver to carry fallback responsibility, the product MUST have driver-state monitoring capability proportionate to that responsibility, and MUST clearly define the monitoring channels used. Relying solely on steering-wheel torque or periodic interaction confirmation is insufficient to support the conclusion "the driver is monitoring the driving environment" — such indirect means may serve as a supplement, but MUST NOT be the sole basis. Without proportionate monitoring capability, the product MUST narrow the modes it offers accordingly, and it is forbidden to offer a function that depends on an unverifiable assumption about driver state.

Boundary conditions"Proportionate" means the monitoring can verify the state that mode actually depends on; not every mode must identify every cause of impairment. L3 does not require continuous road monitoring, but still needs availability detection proportionate to the fallback role; L4/L5 does not trigger a driver-takeover flow merely because an occupant's attention lapses.

Basis and force: [Regulation] UN R171 §5.5.4.2 requires driver-engagement monitoring for applicable DCAS. [Evaluation] Euro NCAP Driver Engagement specifies detection coverage and scoring conditions. [Commitment] The cross-mode requirement that "capability must support the responsibility assumption" is proposed by these guidelines. S04, S08.

Design applicationFirst determine which driver states need to be distinguished, then work backward to the monitoring capability required; don't pick the sensor first and then declare what it can measure.

Verification examples

• User side: have participants drive with "hands on the wheel but eyes off the road ahead," and verify whether the system can distinguish this state from normal monitoring.
• Implementation side: check the driver-state assumption each mode depends on, confirming one by one that a monitoring channel exists that can verify that assumption.

CounterexamplesUnder-delivery — relying on periodic steering-wheel torque confirmation to support the claim that "the driver is monitoring"; over-delivery — mandating full eye tracking for a low-level function that only provides longitudinal assistance.

A3-2State grading and response ladderMUST¶

In one sentence: Distraction, drowsiness, and incapacitation are different things, and the response should differ too.

Applies toproducts that have driver-state monitoring capability and use that monitoring to support driving safety or automation division of labor.

RuleThe product MUST distinguish transient attention lapse, drowsiness or impairment, microsleep or sleep, no-response, and unknown/indeterminate states. Each category MUST have its detection basis, persistence or re-check conditions, recovery conditions, and corresponding response defined.

Each determination is expressed as one of four states, and different categories' determinations may coexist: confirmed present / confirmed absent within this detection scope / unknown / not applicable. Directly judging "no anomaly detected" as "confirmed normal" is forbidden — the only thing the system can output is "no such anomaly was observed within the currently declared detection scope," and it MUST NOT be expressed as an overall guarantee about attention or health status. "Unknown" arises from missing evidence, channel conflict, insufficient coverage, or stale data; it is a description of judgment capability, not a human state — when one channel switches to unknown, still-valid anomaly conclusions from other channels are not thereby cleared. A null value or a missing field MUST NOT be implicitly interpreted as normal. Response MUST match risk; different states may share a prompt or handling mechanism, but the differences in trigger, urgency, and escalation conditions MUST NOT be ignored. For a no-response state that genuinely requires automatic handling, define a path leading to A4; it is forbidden to map every non-transient state uniformly to an immediate stop. Clearing a state MUST be based on validated recovery or false-positive-exclusion evidence, and MUST NOT auto-reset merely on a fixed duration.

Boundary conditionsThis clause does not specify the determination threshold for each state — thresholds vary with the sensing scheme and population, and are defined and verified by the product. This clause does not require covering every possible cause of impairment; what it requires is that grading exists, the nature of each state is distinguished, and the response can be traced back to the level. Every clearing path MUST arrive at a defined state, and must not stop at an unnamed state.

Basis and force: [Evaluation] Euro NCAP Driver Engagement v1.2's definitions, §1.2–1.4, distinguish detection categories from responses; it does not require every state to have its own exclusive response. [Commitment] Explicit modeling of the unknown state and false-positive exclusion is proposed by these guidelines. S08.

Design applicationWrite the response ladder as a state × response table, sharing the same set of state definitions with A2's transfer matrix, avoiding two places each defining their own set.

Verification examples

• User side: verify that the driver can distinguish an attention reminder, a rest suggestion, and no-response handling.
• Implementation side: verify trigger, escalation, and recovery category by category; an ordinary mirror check, sensor-unknown, and drowsiness must not be misclassified as the same impairment.

CounterexamplesUnder-delivery — different risks receive only the same prompt, and there is no difference in escalation condition, re-check method, or handling path either (an implementation that shares a prompt form but has correct state determination and response logic does not fail on this account); over-delivery — every normal mirror check is counted toward accumulated distraction, and the driver is continuously interrupted.

A3-3Monitoring cannot be silently disabled; degradation must be disclosedMUST¶

In one sentence: When monitoring drops offline, the functions that depend on it must narrow accordingly.

Applies toproducts that have driver-state monitoring capability and use that monitoring to support driving safety or automation division of labor.

RuleDriver-state monitoring MUST be enabled by default in the modes it supports, and turning it off through a single ordinary setting operation is forbidden. When the monitoring subsystem degrades (some channels unavailable) or becomes wholly unavailable, the system MUST disclose it to the driver, and MUST handle the functions that depend on it per defined rules — degraded availability, prohibited activation, or early exit; one of the three MUST be defined, and it is forbidden to maintain the original degree of automation without disclosure after monitoring fails. It is forbidden to continue claiming the driver is being monitored while monitoring is unavailable.

Boundary conditionsThis clause does not forbid providing a shutoff path for specific legitimate circumstances (such as a service mode, or a jurisdiction where regulation does not permit monitoring); such a path MUST be bound to that circumstance, accompanied by a corresponding narrowing of the available modes.

Basis and force: [Evaluation] Euro NCAP Driver Engagement v1.2 §1.1's scoring premise includes default enablement on every trip, and it cannot be deactivated by a single momentary button press. [Commitment] Linking functions that depend on monitoring to the degraded state, without impersonating this evaluation threshold as an admission regulation for every market. S08.

Design applicationTreat "monitoring capability" as one input condition of the mode-availability determination, placed at the same decision entry point as the operational-design-domain condition, avoiding two independent availability logics.

Verification examples

• User side: cover the monitoring camera, and verify whether the driver can learn what happened and which functions are restricted as a result.
• Implementation side: inject single-channel failure and total failure respectively, and verify that the function-narrowing behavior matches the definition.

CounterexamplesUnder-delivery — after the camera is covered with tape, the system continues to offer modes that require human fallback as usual; over-delivery — any brief occlusion (such as the driver raising a hand) immediately exits automated driving.

A3-4Reminders match attention, without creating alarm fatigueSHOULD¶

In one sentence: Let the one reminder the person truly needs still get heard.

Applies toall non-safety-critical reminders and state prompts directed at the driver.

RuleA reminder SHOULD be issued while the driver's response can still change the outcome, and a frequency ceiling and merging rule for non-safety-critical reminders SHOULD be defined. Substituting a raised reminder frequency or intensity for improving the false-positive rate is forbidden. A reminder's intensity SHOULD be proportionate to its urgency, avoiding a low-urgency reminder occupying a channel or pattern reserved for high-urgency scenarios (see A2-3 for the reservation relationship). The product SHOULD measure real-world reminder frequency and driver response rate, and treat a persistently declining response rate as a design problem rather than a user problem (see A7-2 for the feedback requirement).

Boundary conditionsThis clause does not apply to takeover requests and safety-critical alerts — their triggering is constrained by A2-3 and A4, and is not subject to a frequency ceiling. This clause does not require reducing the total number of reminders per se; what it requires is that every reminder be capable of being responded to.

Basis and force: [Practice] NHTSA DOT HS 812 555, printed page 65 (Minimizing Annoyance of Auditory Messages), discusses matching urgency and reducing false positives. [Commitment] Frequency configuration, merging, and response-rate feedback are implementation requirements of these guidelines. S11.

Design applicationSet priority for reminders and arbitrate them, rather than letting each function module decide independently when to sound; merge reminders that can be merged into a single expression.

Verification examples

• User side: over long-duration real-world driving, record the number of reminders and how the driver's response rate changes over time, and observe whether the response rate decays.
• Implementation side: verify that the frequency ceiling and merging rule for non-safety-critical reminders are actually enforced, not merely written in documentation.

CounterexamplesUnder-delivery — non-safety-critical state prompts (such as availability changes, function-ready reminders) repeat at high frequency, and the driver turns it off after a week; over-delivery — in order not to disturb the driver, a limitation they genuinely need to know is muted along with everything else. False positives in safety alerts are handled separately by A5-6 and A7-2, and this clause's frequency ceiling does not apply to them.

A3-5Cabin monitoring data use is restrictedMUST¶

In one sentence: Data collected for safety is used only for safety and disclosed purposes.

Applies toin-cabin imagery, physiological, or behavioral data collected for driver-state monitoring.

RuleThe product MUST define the processing location, use-case allowlist, and retention period for cabin monitoring data, and MUST disclose these to the driver. The use-case allowlist is forbidden from including a purpose unrelated to safety functions and disclosed product improvement. Raw imagery SHOULD be processed on-vehicle and discarded immediately; where transmission off the vehicle is genuinely necessary, it MUST be limited to disclosed uses, MUST have a defined retention period, and MUST come with an understandable explanation. It is forbidden to use monitoring data for an evaluative purpose about the driver personally without explicit disclosure and authorization.

Boundary conditionsThis clause does not forbid using data to improve the monitoring algorithm — that is a disclosable product-improvement use; what it requires is a clear scope, a clear period, and disclosure in advance. Accident-related records have their record subject and retention period determined separately by the applicable regulation; this MUST NOT be used to retain all raw cabin imagery indefinitely. Disclosure does not equal obtaining the full legal basis needed for processing or transmission.

Basis and force: [Commitment] The use-case allowlist, processing location, and retention transparency are proposed by these guidelines. Jurisdictional data protection, accident recording, and transmission conditions must have specific regulations separately listed within the project; compliance basis is not claimed as already verified on the strength of an abstract "each jurisdiction's rules."

Design applicationMake "data stays on the vehicle" the default, and turn any off-vehicle transmission into an exception requiring a separate explanation; present the purpose and period together on the monitoring function's settings page, rather than scattered through the privacy policy.

Verification examples

• User side: have the driver look, from inside the vehicle, for "where does what the camera captures go," and see whether they can get an answer within a reasonable number of steps.
• Implementation side: audit the actual data flow and retention, and check consistency with the disclosed use-case allowlist.

CounterexamplesUnder-delivery — cabin imagery is used for product analysis unrelated to safety without disclosure; over-delivery — to avoid risk, no monitoring event is recorded at all, preventing A7-2's improvement loop from being established.

A3-6Monitoring coverage is verified across groupsMUST¶

In one sentence: "Cannot be measured" and "the person was not paying attention" are two different facts.

Applies toproducts where driver or occupant state detection triggers function limitation, a safety alert, or a control change.

RuleThe product MUST state its detection-coverage conditions, and MUST verify against target users and actual use conditions: including height and seating posture, skin tone, eye characteristics, common eyewear or occlusion, and day/night and backlighting. Verification MUST record false-positive rate, false-negative rate, indeterminate proportion, and detection delay by group, and it is forbidden to use an overall accuracy figure to conceal persistent failure for a specific group or scenario. When coverage is insufficient, use A3-3's understandable degradation; sensor failure MUST NOT be presented as a user violation. Recovery MUST re-verify the necessary channels and conditions.

Boundary conditionsThis clause does not require collecting a long-term, identity-recognizable biometric profile; group verification, operational detection, and personalized recognition are different purposes. Limitations of synthetic or experimental data MUST be recorded.

Basis and force: [Evaluation] Euro NCAP Driver Engagement v1.2 §1.1.1 covers driver variation and occlusion coverage. [Commitment] Grouped error analysis and the requirement of "not attributing detection failure to the person" are proposed by these guidelines. S08.

Design applicationWhen occlusion causes unavailability, prompt the driver to adjust the occlusion or use a restricted mode, avoiding repeatedly asking the driver to "pay attention."

Verification examples

• User side: test whether the prompt is understandable using common eyewear, different seating positions, and nighttime conditions.
• Implementation side: check the results for each declared coverage group; verify that sensor-unknown is not recorded as a distraction penalty.

CounterexamplesUnder-delivery — dark eyewear causes a persistent "distraction" alert; over-delivery — every time someone gets in, a full set of identity information must be collected before basic assistance can be used.

3.4 A4 Degradation has an end state¶

Specify what happens once the system can no longer continue driving. In a moving vehicle, stopping is not a state, and waiting is not safe; when capability is insufficient, the system MUST bring the vehicle to an already-defined end state.

A4-1Every failure has a target minimal-risk stateMUST¶

In one sentence: "Stopping" must specify where it stops and how it stops.

Applies tomodes designed to carry system fallback, minimal-risk maneuvers, or driver-no-response handling. Ordinary assistance exit for L0/L1/L2 has its safety response defined separately according to actual capability, and does not claim unimplemented ADS fallback.

RuleFor every category of identified failure in that mode, the product MUST define the trigger condition, remaining capability, handling path, and target end state, and MUST state the fallback outcome when the preferred target cannot be reached. The MRC MUST be a stable, stopped state after risk has been reduced, including a location category and parking-hold; decelerating to a crawl or a temporary low-speed hold is a process state, and MUST NOT be labeled as having reached the MRC. The minimal-risk maneuver and the emergency maneuver taken for an imminent collision MUST be defined separately, and emergency handling MUST NOT wait for the MRM's announcement to finish. Execution MUST have progress monitoring, a maximum duration, and continued risk-reducing measures for not reaching the target; it is forbidden to release all control upon timeout. Disclosure MUST distinguish an expected stopping point from a confirmed reachable location, and MUST NOT guarantee that it will definitely pull onto the shoulder. After stopping, handling still proceeds per A4-5.

Boundary conditionsThe post-failure target MUST be achievable given the remaining capability and road conditions; listing an ideal parking location does not substitute for a safety case. If the product cannot provide the declared system fallback, the mode or ODD SHOULD be narrowed; this clause does not promise that harm is avoidable under every physical fault.

Basis and force: [Regulation] EU 2022/1426 Article 2(15) specifies the stable-stop definition of MRC, applicable within the fully automated vehicles this regulation covers; UN R157's ALKS minimal-risk-maneuver requirement still awaits verification against the original text. S19. [Practice] The L3Pilot CoP-ADF framework lists MRM themes; the specific question cards still await close reading. [Commitment] Distinguishing process states from end states, fallback targets, and progress monitoring are requirements of these guidelines; an L2 emergency function's crawl response is not named MRC. S05, S12, S09.

Design applicationTurn the failure-mode list and the target-state list into one cross-reference table, used as a shared input for design, testing, and the safety case; a blank cell represents an undesigned path.

Verification examples

• User side: during execution of the minimal-risk strategy, ask occupants "what is the vehicle doing, where will it stop," and verify whether the disclosure is sufficient to keep the person from making a dangerous intervention.
• Implementation side: iterate through the failure-mode list, verifying each item has a defined target state and maximum execution duration, and verify item by item that its output actually takes effect — additionally inject three cases: loss of the preferred stopping point, still not reaching the target state at the deadline, and parking-hold after stopping. "Defined but the output does not take effect" fails.

CounterexamplesUnder-delivery — after a sensor failure the system merely releases control and displays a fault icon; over-delivery — a minor failure that could continue with degraded operation instead directly triggers a stop, creating a new hazard on a highway.

A4-2Waiting is not an end stateMUST¶

In one sentence: When no one responds, once time is up the vehicle must place itself safely on its own.

Applies toa mode carrying system fallback has requested human intervention, and the fallback user has not responded effectively within the budget. L2 alerts and low-level function exit are defined separately per the opening applicability statement.

RuleTreating "waiting for the driver's response" as a state that can continue indefinitely is forbidden. Once the time budget is exhausted, the system MUST enter the minimal-risk strategy defined in A4-1; it is forbidden to continue maintaining the original degree of automation, and it is likewise forbidden to release control without executing any strategy. During the wait, the system MUST continue executing its declared control functions and keep escalating the request (see A2-3 for escalation requirements); it is forbidden to silently weaken control capability during the wait. The driver's non-response MUST NOT be recorded as default consent to continue.

Boundary conditionsThis clause does not forbid still accepting an effective driver takeover after execution of the minimal-risk strategy has begun — active override and any product-added abort window are covered respectively by A2-4, A4-3, and ad.fallback.abort.window. This clause targets the situation of "no defined behavior after the budget is exhausted."

Basis and force: [Regulation] The specific maneuver and initiation timing for ALKS after no response need verification against UN R157. [Commitment] Forbidding indefinite waiting, having a defined disposition on timeout, and not presuming default consent, are cross-scenario requirements of these guidelines. S05.

Design applicationIn the state machine, draw "waiting for takeover" as a state with a mandatory exit, where the exit moment equals the time budget and the exit points to the minimal-risk strategy; a waiting state with no exit is by itself a design defect.

Verification examples

• User side: construct a scenario where the driver is entirely non-responsive, and verify that occupants can understand what will happen next.
• Implementation side: verify that a mandatory exit exists for the waiting state, and its behavior matches the definition; verify that control capability is not silently weakened during the wait.

CounterexamplesUnder-delivery — the request continues to alert while the vehicle keeps traveling at its original speed, right up until it hits whatever is ahead; over-delivery — the system forces entry into the minimal-risk strategy even while the driver has already begun an effective takeover.

A4-3Degradation has a basis, is predictable, and is explainableSHOULD¶

In one sentence: Do not add risk just to complete a hierarchy of levels; let the people in the vehicle understand what happened.

Applies tosituations where system capability declines and a choice must be made among continuing restricted operation, switching modes, or entering minimal-risk handling.

RuleDegradation SHOULD proceed along a validated path, stating the current capability and the person's responsibility. Whether to pass through an intermediate mode MUST consider the remaining capability, the risk, and what the target mode requires of the person together; it is forbidden to enter one in sequence merely because "an intermediate level exists." Silently downgrading L3/L4 to an L2 that requires continuous monitoring is forbidden. A mode transition that increases driver responsibility MUST satisfy A2's conditions; when it cannot be completed, transition into the applicable fallback path. A serious fault may go directly to risk reduction with simultaneous disclosure. Active override during a minimal-risk maneuver is handled per A2-4, and an optional "abort window" MUST NOT cancel a manual override required by the applicable regulation.

Boundary conditionsThe existence of an intermediate mode does not mean that mode is applicable right now, nor does it mean the driver is ready. Recoverability and risk reduction take priority over continuity of the interface flow; the chosen path must still be explainable and recordable.

Basis and force: [Practice] L3Pilot CoP-ADF's HVI and MRM frameworks serve as material selection; the specific control-transition question cards still await close reading. [Commitment] Intermediate-mode applicability and the prohibition on silently increasing the person's responsibility are proposed by these guidelines, without claiming that industry norms require mechanically stepping down through every level. S12.

Design applicationDesign the degradation path together with the disclosure copy, letting every level's explanation answer the same set of questions — who is driving now, how much longer can it drive, what do I need to do.

Verification examples

• User side: at each stage of degradation, test whether the driver can state their own responsibility, especially testing the L3-to-L2 transition.
• Implementation side: entry is forbidden when an intermediate mode is unavailable or the person is not ready; a serious fault is permitted to take the validated direct risk-reduction path.

CounterexamplesUnder-delivery — jumping directly from full automation to no assistance at all, with no explanation in between; over-delivery — every minor capability fluctuation is expressed as a degradation notice, and the driver loses sensitivity to serious degradation amid a stream of notices.

A4-4Physical consequences are not promised to be undoneMUST¶

In one sentence: Undo does not exist in the physical world; what can be given is advance notice, an abort window, and false-trigger suppression.

Applies tomaneuvers the system initiates on its own that change the vehicle's motion state, such as a lane change, a detour, emergency braking, or leaving the main road. The driver-abort clause applies only to modes with the corresponding control capability; driverless occupants use A4-5's stop request.

RuleThe product is forbidden from describing an already-executed physical maneuver with wording such as "undoable" or "reversible." For a predictable autonomous maneuver where the user needs to form an operational expectation, the system MUST give advance notice before execution; when providing a driver-abort capability, the window, input, and safety conditions MUST be defined. Driverless occupants need not approve each driving maneuver individually, nor is their stop request interpreted as an immediate interruption of any arbitrary maneuver. For an unpredictable emergency maneuver (such as emergency braking or emergency avoidance), advance notice is not required, but false-trigger suppression conditions MUST be defined, and the trigger reason MUST be explained to the driver afterward. It is forbidden to present "the vehicle can return to the original lane afterward" as "this lane change can be undone."

Boundary conditionsThis clause does not require manual confirmation for every routine lane change — that would make the system unusable; what it requires is that the notice and abort capability's boundary match the commitment, and that a new maneuver not be treated as undoing an old one. An emergency maneuver's suppression condition MUST NOT be strict enough to delay a necessary intervention.

Basis and force: [Commitment] Proposed by these guidelines. Vehicle motion that has already occurred cannot be recalled: in a domain with external physical consequences, undo is not a capability that can be offered — what can be offered is only a window before execution and an explanation after it.

Design applicationUse "notice → abortable window → execution → after-the-fact explanation" as the unified rhythm for autonomous maneuvers; the after-the-fact explanation is used to calibrate trust, not to disclaim liability.

Verification examples

• User side: during an autonomous lane change's notice period, have the driver attempt to abort it and record the success rate; ask whether they believe the lane change just performed "could be canceled."
• Implementation side: check that the interface and copy contain no promise to undo an already-executed maneuver; verify that the false-trigger suppression condition takes effect as defined.

CounterexamplesUnder-delivery — the interface provides an "undo the last lane change" button; over-delivery — out of an abundance of caution, every lane change gets a lengthened notice, and the system misses every feasible lane-change opportunity in dense traffic.

A4-5After stopping, occupant and rescue handling continueMUST¶

In one sentence: Once the vehicle is stopped safely, occupants still need to know the next step.

Applies tominimal-risk stops, no-response stops, and a driverless product's trip abort or fault-related stopping.

RuleThe product MUST define parking-hold after stopping, hazard-state indication, conditions for resuming travel, occupant help-seeking, and rescue contact. The interface MUST distinguish "searching for a stopping point," "stopped," and "connected to support," and MUST NOT display cessation of motion as rescue having been completed. Travel MUST NOT resume automatically merely because the network recovers or a fault indicator disappears; restarting MUST satisfy the mode conditions, an on-site risk check, and defined authorization. Driverless occupants MUST have a discoverable stop request and help-seeking entry, without being required to operate a steering wheel; acknowledgment of the request and the actual stop are reported back separately.

For a system-initiated stop involving occupants, the capability and entry point for emergency egress MUST be defined: a discoverable egress entry, a locally understandable explanation for occupants, and a path that remains workable when the primary interaction entry is unavailable (primary screen failure, network loss, abnormal power); unlocking, door, or emergency-exit capability required by the applicable regulation MUST be implemented. Unlocking, opening the door, and "is it safe to exit right now" are three separate things and MUST be judged and expressed separately; "waiting for customer service to connect" or "network recovery" MUST NOT be the sole blocking condition for egress. Whether and when to unlock automatically is determined by on-site risk and the applicable requirement. Vehicle identification, vehicle immobilization, and operator-contact information accessible to local rescue personnel SHOULD be provided.

Boundary conditionsThe stopping location may still carry hazards; it is forbidden to unconditionally auto-open doors, guide occupants toward traffic, or guarantee that exiting is safe. The trigger basis for emergency communication may come from the applicable regulation or valid pre-authorization; when the network is down there MUST be a locally usable explanation and an alternative help-seeking route.

Basis and force: [Regulation] EU 2022/1426 Annex II §5–6 requires conditions for recovery, occupant stop requests, and help-seeking in applicable fully automated vehicles; §6.3 specifies the automatic-unlock condition when safe in an emergency situation and the egress means after stopping. Verification of power loss, network loss, and different occupant conditions is a product requirement of these guidelines. S19. [Practice] Waymo's I-PACE 2026-06 emergency guide shows separate rescue elements such as vehicle identification, contact, and immobilization. [Commitment] Occupant entry, state acknowledgment, and restart gating are requirements of these guidelines, and do not copy the mechanical operation of any one vehicle model. S15.

Design applicationAfter stopping, continuously retain the vehicle location, help-seeking status, and next-step prompt; rescue materials match the vehicle model and software version, and are readable without needing to log in from inside the vehicle.

Verification examples

• User side: have a first-time occupant with no phone network complete a stop request and help-seeking, confirming they understand that stopping does not mean they can exit immediately.
• Implementation side: under closed or static test conditions, verify parking-hold, the emergency egress path, and restart conditions under network loss, primary-screen failure, abnormal power, unanswered support, and link recovery; also verify that near traffic, "the door can open" is not misleadingly presented as "it is safe to exit." Applicability differences for children and occupants with limited mobility are recorded separately, and gaps are not concealed behind an average completion rate.

CounterexamplesUnder-delivery — the screen goes black after stopping, leaving only "trip ended"; over-delivery — in pursuit of rapid evacuation, all doors are automatically opened while still in a highway lane.

3.5 A5 Evidence calibrates trust¶

Let the driver and occupants form well-grounded judgments about the system's capability, intent, and perception. The goal is calibrated trust — preventing both the disengagement loop caused by over-trust and the function being turned off due to insufficient trust. This principle's presentation is bound by a hard constraint unique to this domain: the attention budget.

A5-1Capability and limitations are disclosed before use and re-checkable in the vehicleMUST¶

In one sentence: Saying it in the manual doesn't count; being able to find it while driving does.

Applies toall driving-automation functions.

RuleThe product MUST disclose a function's capability and limitations before the driver's first use of it, and MUST provide an in-vehicle re-check entry, so that the driver can look up, at any later time, what the function is responsible for, what it is not, and under what conditions it is unavailable. The disclosed content MUST resolve to the same capability description as A2-1's division-of-labor definition and A1-2's operational-design-domain statement. It is forbidden to write a critical limitation only in the owner's manual or purchase documents with no way to find it in the vehicle. The re-check entry's presentation while driving is constrained by A5-4.

Boundary conditionsThis clause does not require the pre-first-use disclosure to be a mandatory, complete reading; what it requires is that the critical limitation has been proactively presented, rather than waiting for the driver to go find it themselves.

Basis and force: [Regulation] The boundary and disclosure requirements for applicable China products are in MIIT Liantongzhuang [2025] No. 45, Part 2 (1). [Practice] L3Pilot HVI discusses user understanding. [Commitment] Sharing the same capability version between first disclosure and in-vehicle re-check is proposed by these guidelines. S07, S12.

Design applicationMake the capability description a single source, jointly referenced by first-time onboarding, in-vehicle help, the manual, and the official website; make the in-vehicle re-check entry a two-tier structure — deeper detail available when parked, only a single sentence while driving.

Verification examples

• User side: have an owner who has used the product for a while state three limitations of this function, and check whether they match reality.
• Implementation side: check that the capability descriptions everywhere reference the same source and version.

CounterexamplesUnder-delivery — the critical limitation is only on some page of the manual; over-delivery — before first use, the driver must flip through page by page and check off every item, spending ten minutes tapping in the parking lot.

A5-2System intent and basis are visibleMUST¶

In one sentence: Let the person know what the vehicle is going to do and why, instead of just having it happen to them.

Applies tobehaviors the system decides autonomously that are perceptible to the driver, such as decelerating, changing lanes, detouring, or holding position.

RuleThe system MUST express intent for autonomous behavior in defined categories, and state a reason category when feasible. A predictable behavior is expressed before or simultaneously with the event; emergency collision avoidance may be explained afterward, and the action MUST NOT be delayed for the explanation. The reason MUST come from verifiable events and states, sorted into a finite, understandable set of categories. When the reason is missing or uncertain, this MUST be stated truthfully, and it is forbidden to use a generative explanation to fill in a basis that did not occur. When conservative behavior is taken due to uncertainty, the driver SHOULD be able to distinguish limited perception, planning delay, and a fault; the presentation timing and load are constrained by A5-4 and A5-6.

Boundary conditionsThis clause does not require explaining every minor speed adjustment; the product defines which behavior categories need intent expressed. This clause does not require disclosing internal algorithms or confidence values — confidence presentation is determined by A5-3 and ad.evidence.confidence.exposure.

Basis and force: [Practice] L3Pilot CoP-ADF §4.5 provides HVI and trust-review questions. [Commitment] Grounded reasons, a finite category set, and post-hoc explanation for emergencies are proposed by these guidelines; the explanation is not a commitment to complete algorithmic reasoning. S12.

Design applicationMake the reason categories a closed set, shared by the interface, speech, and the event log; use the same set of categories to write post-event playback, reducing the driver's learning cost.

Verification examples

• User side: after the system decelerates with no obvious external cause, ask the driver for the reason, and compare their judgment with the system's actual basis.
• Implementation side: verify separately for the routine and emergency categories. For routine behavior: the intent expression's timing is before or simultaneous with the behavior. For emergency behavior: verify the control action was not delayed by the explanation, and that the reason given afterward matches the actual basis. In both categories, the reason category falls within the closed set.

CounterexamplesUnder-delivery — the vehicle suddenly decelerates on an open road with no explanation, and the driver assumes a system fault and stops trusting it from then on; over-delivery — every minor adjustment of following distance gets its own reason announced.

A5-3Perception presentation distinguishes detected, low-confidence, and uncoveredMUST¶

In one sentence: Don't draw an unseen area as an empty road.

Applies tovisualizations that present the system's perception results to the driver or occupants.

RuleThe perception visualization MUST distinguish three cases: detected with sufficient confidence, detected but with insufficient confidence, and uncovered or undetectable. Rendering an uncovered area to look empty, safe, or free of targets is forbidden — this is a presentation that directly causes over-trust. The target categories omitted from the visualization MUST be queryable; the driver MUST NOT be left to infer "not present in reality" from "not shown on screen." The visualization's level of detail MUST NOT exceed what the actual perception capability supports. The freshness of dynamic evidence and the presentation of a data-stream interruption MUST be defined; a frozen or stale frame MUST NOT continue to pass itself off as current perception.

Boundary conditionsThis clause does not require the visualization to present every perception result — that would be neither readable nor necessary; what it requires is not creating the impression that "the system sees everything." A product may choose not to provide a perception visualization, in which case this clause does not apply.

Basis and force: [Commitment] Proposed by these guidelines. The basis is the relationship between visualization fidelity and trust calibration: the more complete and certain the presentation looks, the more the driver tends to take it as fact.

Design applicationGive an uncovered area an explicit visual treatment (such as a fade, blank space, or boundary line), rather than sharing the same presentation as an "empty road"; provide a note near the visualization about "what is not shown."

Verification examples

• User side: in a scenario with an undetected target present, ask the driver "what does the system currently see," and compare their understanding with the actual perception range.
• Implementation side: check that the rendering logic uses different treatments for an uncovered area versus an empty area.

CounterexamplesUnder-delivery — a system with only forward perception is rendered as a top-down view that is clear all around; over-delivery — the screen is covered with uncertainty labels and detection boxes, and the driver cannot read anything useful in a glance.

A5-4Information presentation is constrained by the attention budgetMUST¶

In one sentence: Do not present, while driving, something that needs a long stare to complete.

Applies toin-vehicle interaction while a human bears road monitoring, control, or an imminent takeover. L3 secondary tasks are assessed against their own permitted conditions and takeover-readiness requirements; L4/L5 occupant entertainment does not mechanically apply the driver's eyes-off-road budget.

RuleThe product MUST define interaction reachability and attention budget by mode, seat, and task, and MUST record the measurement method, sample, statistical basis, and determination conditions. The eyes-off-road budget MUST describe at minimum the single-glance distribution and the task's cumulative eyes-off-road time, and MUST NOT substitute an arbitrary percentile for the chosen criterion's complete test conditions. A task exceeding the budget MUST be deferred, locked, or offered a validated alternative path; speech does not automatically exempt a task from cognitive-load, misrecognition-recovery, and driving-performance testing. A task SHOULD be interruptible by driving events and resumable when safe, and it is forbidden to block a takeover with a long speech segment or continuous follow-up questions. Core controls have their input requirement and reachable path defined item by item; only a function listed as a direct physical input by the applicable regulation, the chosen evaluation, or a product commitment is judged by that requirement — it is forbidden to judge every direct touch input as non-conforming across the board. Safety-alert preemption and cross-channel timing follow A5-6.

Boundary conditionsThe NHTSA 2013 document is a voluntary guideline for original-equipment in-vehicle visual-manual secondary tasks, and it cannot serve as an L3 takeover deadline, a unified threshold for every driving scene, or proof of speech safety. Euro NCAP's control requirements differ by function; direct physical input and direct touch input are different evaluation definitions.

Basis and force: [Practice] NHTSA's 2013 Final Guideline §VI.E.14 gives eye-glance test criteria; NHTSA human-factors materials distinguish visual, manual, and cognitive load. [Evaluation] Euro NCAP Driver Engagement v1.2 §2.2–2.3 specifies input form by function. [Commitment] An alternative path MUST be empirically tested and the task MUST be interruptible. S10, S18, S08.

Design applicationMake "reachable while driving" an explicit attribute of every function, rather than defaulting everything to reachable; provide a voice or passenger-side path for a locked task, rather than simply disabling it.

Verification examples

• User side: measure the complete task and error-recovery path per the chosen protocol; for a speech task, also test driving performance, load, and recovery after a safety-alert interruption.
• Implementation side: check the control checklist, the version relied on, and the actual entry point item by item; test content gating separately for L2, L3 takeover requests, and L4 occupant scenarios.

CounterexamplesUnder-delivery — defrost and hazard lights are put into a second-level touchscreen menu; over-delivery — nearly every function is locked while driving, and the driver switches to their phone to accomplish the same thing, which is riskier instead.

A5-5Disclaimers do not substitute for designSHOULD¶

In one sentence: "Please stay attentive at all times" cannot offset an interface that induces distraction.

Applies toall prompts, terms, and onboarding copy directed at the driver.

RuleThe product is forbidden from substituting prompt copy, terms confirmation, or a disclaimer for the design handling of a known risk. An interface or function known to induce the driver to disengage from monitoring SHOULD be handled through design, not settled with an added reminder. A term requiring driver confirmation SHOULD be limited to content the driver can understand and act on; designing a function so that a single click on a term serves as the basis for transferring responsibility for the driver's subsequent behavior is forbidden.

Boundary conditionsThis clause does not forbid providing necessary legal notices — they serve an independent compliance purpose; what it forbids is using a notice to substitute for design handling.

Basis and force: [Commitment] Proposed by these guidelines. The basis is a common form on the "over-delivery" side: shifting responsibility forward onto the user, instead of removing the risk.

Design applicationIn design review, ask one follow-up question for every warning copy proposed for addition — if this sentence is ignored, does our design still hold up? When the answer is no, change the design, not the copy.

Verification examples

• User side: observe the driver's reading and response behavior after repeatedly encountering the same warning, measuring how its effectiveness decays.
• Implementation side: inventory the points in the product that rely on "having prompted" as the sole risk treatment.

CounterexamplesUnder-delivery — an interface known to invite prolonged staring ships with just an added "please watch the road" line; over-delivery — out of liability concerns, a signature-style confirmation is required on every activation, and the driver develops a habit of mechanical clicking.

A5-6Safety alerts have arbitration and channel-failure strategyMUST¶

In one sentence: The most urgent action is clearly heard; multiple signals say the same thing.

Applies toproducts where safety alerts — takeover, collision, driver state, and vehicle fault — share visual, auditory, or haptic channels.

RuleThe product MUST define priority, preemption, and recovery rules among safety alerts, handling concurrent events by risk urgency; multiple speech segments MUST NOT be played simultaneously merely because they share a uniform "safety level." Arbitration MUST preserve information that still requires user action, and an expired request MUST NOT be replayed as a new command after the danger has cleared. For multi-channel output of the same event, semantic correspondence, timing tolerance, delivery evidence, and an alternative path for a single-channel failure MUST be defined; writing to a queue does not equal actual delivery; device output likewise does not equal the user having perceived, understood, or acted on it, and these pieces of evidence MUST NOT substitute for one another. When the display freezes, sound is unavailable, or haptics fail, the system MUST NOT continue to assume the original reminder capability holds; when a required alert capability cannot be met, restrict the mode that depends on it and execute the applicable degradation.

Boundary conditionsThis clause does not specify a unified millisecond value or fixed priority table across products; these are determined jointly by safety analysis and human-factors verification. An emergency control action MUST NOT wait for the interface to render successfully, nor may increased volume be used to mask a signal conflict.

Basis and force: [Regulation] UN R171 §5.5.4.1.4 and §5.5.4.2.2.3 specify information priority and emergency system alerts for applicable DCAS. [Practice] NHTSA DOT HS 812 555, printed pages 47–48, discusses multimodal messages. [Commitment] Delivery evidence, discarding of expired items, synchronization tolerance, and channel-failure gating are proposed by these guidelines. S04, S11.

Design applicationWhen a forward-collision alert and a takeover request trigger simultaneously, first clearly express the immediate action, preserving the current mode and the still-valid takeover state; cancel a replay that has already expired.

Verification examples

• User side: under a call, media, and a concurrent safety alert, test whether the driver can correctly identify the first action that needs to be taken.
• Implementation side: inject screen freeze, audio occupation, channel delay, and message expiration, measure the actual output, and check the degradation and log.

CounterexamplesUnder-delivery — the takeover speech and the collision speech overlap; over-delivery — an urgent alert is delayed waiting for three channels to fully synchronize.

3.6 A6 External impact is accounted for¶

The object of regulation is road users outside the vehicle. The system's behavior changes not only the principal's situation, but also the situation of people who have no relationship whatsoever with the product.

A6-1This vehicle's automated-driving state is discernible from outsideSHOULD¶

In one sentence: Per jurisdictional requirements, let people outside know this vehicle is driving itself.

Applies toproducts operating in a jurisdiction that permits or requires indicating automated-driving state.

RuleThe product SHOULD, per the applicable jurisdiction's requirement, make the fact that this vehicle is in automated-driving state discernible from outside; where a jurisdiction has specified an indicator form, that specified form MUST be used, and it is forbidden to invent an expression that could be confused with the legally specified indicator. During execution of the minimal-risk strategy, the hazard-state signal specified by the applicable jurisdiction MUST be used (see A4-1 for the requirement).

Boundary conditionsThis clause does not require proactively adding an external indicator in a jurisdiction with no specification — an early self-invented indicator could conflict with a subsequent legally specified form.

Basis and force: [Commitment] Additional external state expression is offered only within what the jurisdiction permits; the specific requirements for a legally mandated light signal are verified per project. [Practice] The official table of contents and scope statements of ISO/TR 23049 and ISO/PAS 23735:2025 are available as source material; the latter targets single-mode L4/L5 ADS-dedicated vehicles, and its full text has not been read. S13, S16.

Design applicationTreat jurisdictional differences in external signals as a configuration item (see ad.external.applicability), rather than hard-coding a single market's practice into the software.

Verification examples

• Implementation side: check that each sales jurisdiction's indicator requirement matches the actual implementation; verify that the hazard signal during minimal-risk-strategy execution is issued as specified.

CounterexamplesUnder-delivery — no indication whatsoever is given in a jurisdiction with a clear requirement; over-delivery — a conspicuous self-invented external light language is used in a jurisdiction with no specification, causing other road users to misunderstand.

A6-2External signals express only itself, and do not issue instructionsMUST¶

In one sentence: Don't tell a pedestrian "go ahead" — that shifts responsibility.

Applies toany display, projection, light signal, or sound directed at road users outside the vehicle.

RuleThe semantics of an external signal MUST be limited to expressing this vehicle's own state and intent (such as "decelerating," "about to stop," "in automated-driving state"). Issuing an instruction or right-of-way permission directed at another party is forbidden, including but not limited to expressions such as "please proceed," "safe," or "you may cross," and their equivalent graphics or light signals. It is forbidden to use an expression that could be understood as this vehicle having confirmed the other party's safety. The vocabulary set of external signals MUST be defined in advance and be queryable, and it is forbidden to generate a new external expression ad hoc.

Boundary conditionsThis clause does not forbid expressing the self-state "this vehicle is yielding" — its difference from "you may go now" is that the former states this vehicle's own behavior, while the latter makes a guarantee about another party's situation. This distinction MUST be verified in the concrete wording and graphics, not merely assumed by the designer.

Basis and force: [Commitment] "Expressing only this vehicle, and not providing a cross-lane right-of-way guarantee" is a risk-control choice of these guidelines. The full text of ISO/TR 23049 and ISO/PAS 23735:2025 has not been verified, so this clause cannot be written as an explicit ISO prohibition or a research consensus. S13, S16.

Design applicationMake the external vocabulary set a reviewable list, testing every entry with "what happens if this expression is understood as a permission."

Verification examples

• User side: show pedestrians who have never encountered the product every type of external signal, and record their understanding; if the signal leads them to believe another lane is also safe, that they need not observe for themselves, or that they have received right-of-way permission, that fails; correctly understanding "this vehicle is yielding" by itself is not a failure.
• Implementation side: check that the external-signal implementation falls within the defined vocabulary set.

CounterexamplesUnder-delivery — projecting a crosswalk in front of the vehicle or displaying "please cross"; over-delivery — eliminating all external expression, including a deceleration-intent signal that could otherwise reduce misunderstanding.

A6-3Interactive behavior is predictable, and does not train the wrong expectationsSHOULD¶

In one sentence: Yielding must be consistent; don't let passersby learn a habit that would cause an accident with a different vehicle.

Applies tobehaviors that interact with road users outside the vehicle, such as yielding at an intersection, merge negotiation, or decelerating at a pedestrian crossing.

RuleInteractive behavior in the same category of scenario SHOULD be consistent and predictable, and its key parameters (starting distance, deceleration method, recovery condition) SHOULD be defined in advance. The product SHOULD assess the behavioral expectation that its interactive behavior may form after being repeatedly experienced, avoiding training a habit that does not hold on other vehicles and would therefore increase risk. Designing a behavior that induces another party's misjudgment in order to improve this vehicle's own throughput is forbidden.

Boundary conditionsThis clause does not require behavior to be completely identical across all scenarios — different scenarios naturally have different safety margins; what it requires is consistency and predictability within the same category of scenario.

Basis and force: [Commitment] Consistent expression and avoiding induced misjudgment are proposed by these guidelines. Long-term expectation transfer for external HMI still needs direct research evidence; an unlisted "mixed-traffic research" is no longer used to claim a research consensus.

Design applicationBring the yielding-behavior parameters into configuration and review (see ad.external.yield.behavior), rather than leaving them to the policy layer's free discretion.

Verification examples

• User side: repeatedly observe yielding behavior under different traffic conditions at the same intersection, assessing its consistency; interview pedestrians who frequently encounter this vehicle model about their expectations of its behavior.
• Implementation side: check that the behavior parameters for the same category of scenario fall within the defined range.

CounterexamplesUnder-delivery — at the same intersection, the vehicle sometimes stops far in advance and sometimes brakes at the last moment, so pedestrians cannot form an expectation; over-delivery — uniformly extreme-conservative yielding causes congestion at busy intersections and induces other vehicles to force their way past.

3.7 A7 Governable over the long term¶

The object of regulation is effects that persist across trips, across drivers, across versions. A single software update can change an entire fleet's behavior overnight, while the driver's mental model does not update in sync.

A7-1Behavior changes do not take effect silentlyMUST¶

In one sentence: When an update changes how the vehicle drives, the driver must know before using it.

Applies tosoftware updates that change driving-behavior characteristics, transfer conditions, the operational design domain, or driver responsibility.

RuleAn update that affects driving behavior, ODD, or responsibility MUST disclose the change before the affected function is used again; the execution of the update itself MUST also satisfy the applicable pre-install, mid-install, and post-install disclosure and safety conditions. The pre-install disclosure states the estimated duration, the scope of function unavailability, and necessary preparation; the post-install disclosure states clearly whether it succeeded, failed, or reverted to which version, and download completion MUST NOT be displayed as the function having been updated. The behavior description, function version, ODD, and map dependency MUST be consistent with the actually effective configuration; whenever a map or cloud configuration changes these behaviors, it also MUST enter the change-determination process. For a vehicle shared across users, a key change SHOULD be delivered to the person actually using the affected function.

Boundary conditionsAn update that does not change driving behavior or responsibility may simplify the pre-reuse disclosure, but this MUST NOT be used to skip the applicable OTA safe-execution conditions. Whether approval, filing, or recall is needed is verified separately by jurisdiction; the user's consent to update does not substitute for admission approval.

Basis and force: [Regulation] UN R156 §7.2.2 specifies safe execution, failure recovery, and pre/post-update information for applicable OTA; China projects additionally check MIIT Liantongzhuang [2025] No. 45, Part 3. [Commitment] Linking the behavior disclosure before the actual driver's reuse with cloud-side changes is proposed by these guidelines. S06, S07.

Design applicationPresent the states "pending install — installing — takes effect after verification" separately; provide a brief change note to the driver reusing the function, without mechanically re-reading content already effectively received.

Verification examples

• User side: after an overnight update, switch to a different driver, and test whether they can learn of a change affecting their own operation before first use.
• Implementation side: inject an install interruption, an incompatible version combination, a map change to the ODD, and an out-of-sync disclosure, and verify that a false success is not displayed and an incompatible function is not left open.

CounterexamplesUnder-delivery — an overnight update changes how aggressive lane changes are, and the driver only discovers it on the highway; over-delivery — every unrelated update forces an update notice popup requiring confirmation.

A7-2Real-world use feeds back into improvementMUST¶

In one sentence: Disengagements, false alarms, and functions that get turned off are the first-hand evidence for improvement.

Applies todriving-automation functions already in real-world use. This clause's feedback obligation is not determined by whether the product offers users event lookup: user-facing lookup is an optional capability — not offering it does not exempt this clause's requirement for operational feedback, and offering it does not expand the scope of data collection either.

RuleThe product MUST establish real-world-use feedback within the bounds of purpose and retention, covering mode exits, takeover requests and responses, minimal-risk strategy, function shutoff, alert false positives, and availability anomalies. Metrics MUST state the event definition, exposure (such as function-use hours or number of requests), ODD, software version, and population scope; the system MUST NOT be judged more dangerous merely because it has a higher exit count, nor may a lower count be equated with greater safety. A function being turned off in large numbers or a persistently declining response rate MUST enter problem analysis, and MUST NOT be attributed solely to user habit. Records of driving-state and control changes SHOULD use a correlatable timeline, distinguishing detection, user action, and system execution; a product experience log does not substitute for a legally required event record or accident report.

Boundary conditionsThis clause does not require collecting driving data unrelated to the above events; the scope SHOULD be limited to the minimal set that can support an improvement judgment.

Basis and force: [Practice] L3Pilot CoP-ADF §4.5.4's post-production evaluation covers adverse behavioral adaptation. [Regulation] Event and accident reporting for applicable China products is in MIIT Liantongzhuang [2025] No. 45, Part 2 (4), whose scope differs from the product metric. [Commitment] The requirements for exposure, version, and event definition are proposed by these guidelines. S12, S07.

Design applicationMake "how many people turned this function off, and whether they turned it back on" a standing product metric, alongside the fault rate.

Verification examples

• Implementation side: check that the feedback data covers every event category listed in this clause's main text (mode exit, takeover request and response, minimal-risk strategy, function shutoff, alert false positive, availability anomaly); this item adjusts automatically when the main text adds or removes a category. Check whether a function with a persistently high shutoff rate has failed to enter the improvement process.

CounterexamplesUnder-delivery — only the system fault rate is tallied, never the driver's active-shutoff rate; over-delivery — a function is made hard to turn off just to make the metric look good.

A7-3Personalization is bound to the correct subject and can be resetMUST¶

In one sentence: A vehicle has more than one driver; settings should not just follow the vehicle.

Applies tofunction settings and personalized behavior that change with use or can be adjusted by the driver.

RulePersonalized settings MUST be bound to an identified driver subject, and it is forbidden to continue applying the previous driver's personalized settings to driving behavior when the driver is unidentified. When the driver cannot be identified, the system MUST revert to the product-defined default. The product MUST provide a reset entry, and MUST state the scope in which the reset takes effect. Every adjustable field MUST have a stated permitted value range; no legal value within it may invalidate an applicable hard constraint of these guidelines. When the system learns preferences from driving behavior, this MUST be able to be turned off, and after being turned off, deactivated personalization MUST NOT be reconstructed from historical data.

Boundary conditionsThis clause does not require biometric-grade driver identification; existing means such as a key, an account, or seat memory are all acceptable, but the default behavior on identification failure MUST be defined.

Basis and force: [Commitment] Proposed by these guidelines. The basis is a real failure mode in a shared-vehicle scenario: a subsequent driver unknowingly inherits the previous driver's aggressive settings.

Design applicationManage "settings that affect driving behavior" separately from "settings that affect comfort experience"; the former reverts to default on identification failure, the latter can be handled more loosely.

Verification examples

• User side: get in as an unidentified person, and verify that driving-behavior-affecting settings revert to default and the driver can learn of it.
• Implementation side: check the permitted domain of every adjustable field item by item, verifying that boundary and combined values do not violate the main text's hard constraint; verify that no reconstruction occurs after learning is turned off.

CounterexamplesUnder-delivery — the previous driver's high-aggressiveness following strategy continues to take effect after a driver change; over-delivery — every time someone gets in, full identity verification is required before basic functions can be used.

A7-4Skill degradation and over-reliance are confronted honestlySHOULD¶

In one sentence: Someone who hasn't driven in a long time is not the same person they were a year ago when they take over.

Applies todriving-automation functions used long-term and at high frequency.

RuleThe product SHOULD assess the effect of long-term use on the driver's manual driving skill and situational awareness, and treat that effect as a design input rather than the user's personal problem. Design parameters for transfer and takeover (A2-2's time budget, A2-5's evidence requirement) SHOULD be calibrated against long-term users' actual performance, not only against new users' or trained testers' performance. For a mode that still requires human monitoring, the product is forbidden from raising usage rate through wording or a function design that encourages disengagement from monitoring.

Boundary conditionsThis clause does not require the product to bear responsibility for maintaining the driver's skill, nor does it require setting a mandatory manual-driving period; what it requires is that this effect be included in the basis for calibrating design parameters.

Basis and force: [Practice] NHTSA DOT HS 812 555, printed page 34, discusses the out-of-the-loop problem, vigilance, and skill issues; L3Pilot CoP-ADF, printed page 148, proposes post-production evaluation of adverse behavioral adaptation. [Commitment] Including long-term users and calibrating against actual performance is a requirement of these guidelines; these materials do not prove that every long-term user degrades. S11, S12.

Design applicationInclude long-term users in the participant sample for parameter calibration, not only first-time users; treat how takeover performance changes with duration of use as a long-term observation metric.

Verification examples

• User side: compare the distribution of response time and control quality between long-term and new users in the same takeover scenario, calibrating by risk-relevant grouping and failure distribution, without letting an overall average conceal a gap for a particular group of users.
• Implementation side: check that the participant composition underlying the parameter calibration includes long-term users.

CounterexamplesUnder-delivery — the time budget is determined using trained testers' takeover performance, and it is generally insufficient for actual users; over-delivery — the driver is forced to manually drive a stretch of mileage periodically to keep using the function, and users respond by routing around the system.

---

4. Terminology and definitions¶

This chapter defines only the terms used in the main text of these guidelines that could be ambiguous. The authoritative definitions of terms such as level and operational design domain follow SAE J3016 and the applicable jurisdictional regulation; this chapter's wording is for consistent understanding within these guidelines, and does not substitute for the source definitions.

---

Appendix A: Applicability and non-substitution statement¶

These guidelines apply to: automated-driving human-machine interaction design directed at the driver and occupants, covering the experiential commitments and their fulfillment mechanisms across seven categories of object — mode cognition, control-authority transfer, driver state, degradation and end state, information presentation, external communication, and long-term governance.

These guidelines do not replace:

• Functional safety and safety-of-the-intended-functionality cases — the hazard analysis, safety-goal decomposition, and verification activities of ISO 26262 and ISO 21448; conforming to these guidelines does not constitute any safety case.
• Type approval and admission — the requirements of UN R155/R156/R157 and each jurisdiction's regulations; the main text of these guidelines does not restate regulatory values, and a product's actual values MUST follow the jurisdiction's currently effective version.
• Data protection and privacy compliance — A3-5 specifies only a use-restriction design requirement, and does not constitute a compliance assessment.
• Accessibility assessment — A3-6 and A4-5 cover some population differences and occupant entry points, but do not exhaust the dedicated requirements for people with hearing, vision, or motor-function limitations. A2-3's multi-channel requirement serves a redundancy purpose, and is not equivalent to accessible design.
• Safety case toward external road users — A6 specifies only design requirements for communication and behavioral predictability, and does not assess collision-avoidance performance.

---

Appendix B: Items pending verification¶

1. Regulatory applicability still requires project-level verification. Access to the UN R157 original text was blocked, and this remains an open item; UN R171 and R156 were read in specific versions this time, and this is not a claim of coverage for every subsequent revision, sales market, or vehicle model. The China notice's annexes and other jurisdictional requirements have also not been mapped clause by clause. See the source list for status.
2. Restricted standards have not had their full text read. SAE J3016, ISO/TR 21959, ISO/TR 23049, ISO/PAS 23735, and others have only been verified to the public scope or table of contents; their specific thresholds and prohibitions cannot be claimed as verified on this basis.
3. Principle division and granularity. The 36 rules still need cross-reviewer classification and real-project trial use, especially the remote-support boundary of A2-7 and A4-5, and the detection and delivery-capability boundary of A3-6 and A5-6.
4. Numeric values require project-level verification. No universal takeover-seconds figure or cross-modal synchronization millisecond value is given. The product MUST give a basis specific to its mode, ODD, software/hardware version, and target population.
5. Long-term and external-behavior evidence. Specific material has been added for alert fatigue and long-term use, but A6's cross-vehicle-model expectation transfer, driverless-occupant accessibility, and the commitments newly added by these guidelines still need dedicated verification.

Appendix C: Verification checklist¶

Every product review records the function, mode, ODD, jurisdiction, software/hardware version, rule applicability, and evidence location. The conclusion takes one of pass / fail / pending verification / not applicable; unverified must not be written as pass. Not applicable MUST state the role or capability reason.

Hazardous conditions are constructed using simulation, a bench rig, or a controlled closed site; ordinary users are not made to deliberately become incapacitated or create collision risk on open roads. User understanding, actual control, software events, and vehicle motion are verified separately; passing any one layer does not substitute for the others.

C.1 Acceptance conditions and evidence layers¶

Before testing, the function, role, population, road, and environmental scope MUST be made clear, along with the agreed measurement method, sample composition, number of repeated trials, and the definition and criterion of failure. Performance and user-understanding reports state the distribution, the tail, and group differences, not just the mean; an interrupted, failed, or indeterminate trial MUST NOT be silently removed from the denominator. The verification examples in the rules are used to construct test cases, and are not a unified sample size or pass rate across products.

A hard-constraint violation MUST NOT be offset by a high score on other items — for example, releasing control directly on timeout, treating unknown as ready, or displaying "stopped" before the vehicle has actually stopped. Missing evidence is recorded as pending verification; after narrowing the applicable scope, the complete dependency of that scope MUST be re-checked, and a failed item MUST NOT simply be changed to not applicable.

C.2 Correlated facts and fault injection¶

When verifying around A1-1, A2-2, A2-5, A2-7, A4-5, A5-6, and A7-2, the same process records the function and mode identifier, trip identifier, transfer-path identifier, and this request's identifier; occurrence time, receipt time, source, validity, and control acknowledgment are stored separately. The policy dictionary defines "what should be done," while the operational-fact record states "what was actually done this time"; the two MUST NOT be written together. Facts at minimum distinguish request receipt, control taking effect, alert output, user response, and target achievement; successful takeover carries additional completion evidence, and successful stopping carries additional motion and parking-hold evidence.

Inject late, out-of-order, duplicate, interrupted, recovered, and mutually contradictory messages, confirming that a stale acknowledgment cannot end a new transfer, a repeated instruction cannot cause a repeated maneuver, and a frozen frame cannot be displayed as real-time. When clock-synchronization error or missing evidence exceeds the acceptable range, mark the affected conclusion as unconfirmable and execute the corresponding degradation; do not infer vehicle state through the interface.

Appendix D: From design decision to a verifiable journey¶

The examples below help combine the requirements already in the main text; they do not provide timing calibration ready to install directly in a vehicle.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into re-checkable acceptance inputs, and do not set an additional universal performance threshold. Select according to the product's applicable capability, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as passed.

Each scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as success or failure.