In-Vehicle HMI Design Guidelines

For designers, human-factors engineers, and vehicle HMI engineers: make every interaction in the car completable without taking the eyes off the road for long, interruptible at any moment and resumable from where it was interrupted; make safety-related functions like defrosting, hazard warning, wipers, and lighting reachable without hunting through menus first; make driving-critical information appear where the driver is already looking.

The normative object of in-vehicle HMI is the screens and controls inside the car: the instrument cluster, center display, head-up display, steering-wheel buttons, knobs and stalks, in-car voice, seat and climate panels, and the interactions they together make up. These interactions have one decisive difference from interactions on a phone — the user's primary task is not on the screen. However important the on-screen task is, it still ranks behind "watching the road, controlling the vehicle"; every requirement a product places on the interface borrows resources from an ongoing physical task whose cost of failure is high.

There are three design mistakes most common in this domain, and the split of these guidelines is aimed directly at them: first, moving a phone's interaction density into the car wholesale — multi-level menus, lists that must be read in full before a choice can be made, state expressed through visual motion — so that finishing one thing takes several glances at the screen; second, treating physical controls as a cost item to be eliminated altogether, burying defrosting, wipers, lighting, and hazard warning on the second or third level of a touchscreen menu, so they become hardest to reach at exactly the moment they are needed most; third, treating "the information was displayed" as "the driver knows it," putting driving-critical prompts only on the center display while the driver's gaze actually falls on the instrument cluster and the road.

These guidelines consist of six principles and 35 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 (VH3-2 is the second rule under the third principle).

Scope statementThese guidelines constrain the nature of the experience commitments the in-vehicle human-machine interface makes to the driver and occupants, and the mechanisms that fulfill them; they do not presuppose a single technical architecture, and do not specify components, cockpit domain-controller schemes, or display technology. Adopting these guidelines cannot replace the following dedicated assessments and compliance determinations: vehicle functional safety (ISO 26262) and safety-of-the-intended-functionality determinations, regulatory conformance certification in each jurisdiction (UN ECE regulations, GB mandatory standards, and local admission requirements), statutory markings and lighting regulations for the instrument cluster, ergonomic dimension and field-of-view verification for cockpit physical layout, dedicated accessibility and age-friendly requirements, and privacy and data compliance. These areas appear in these guidelines only as cited sources and scope exclusions: these guidelines do not restate their values, nor do they endorse their own clauses by citing those provisions.

On numeric values: public guidelines in this domain do have time-based criteria (for example, limits on single-glance duration and total task occupancy), but each is bound to a specific test method, task category, applicable population, and voluntariness statement, and citing them apart from these conditions amounts to fabricating a basis. The main text therefore never carries over numeric thresholds; it only requires that the relevant upper bound be explicitly defined, have a measurement method, have a cited basis, and be re-checkable. The values a product actually adopts are carried in Design Token, separately constrained by the applicable regulations, the chosen evaluation method, and the product's own verification. For sources and verification status see reference.md.

Reading entry points: Chapter 1 turns tasks into design decisions, Chapter 2 looks up rules, Chapter 3 looks up the full requirements, Chapter 4 looks up terminology, Chapter 5 looks up states and components, Chapter 6 covers delivery and acceptance. For parameters see Design Token.

---

First determine vehicle state and the operating subject¶

Most obligations in these guidelines take full effect only when the vehicle is in a driving-related state and the operator is the driver. Both of these must be determined before applying a rule, or two kinds of errors follow: treating full-screen video while parked and charging as a violation, or treating a map the front passenger is using as something the driver is using.

The concrete criteria for "in motion" (speed, gear, parking brake, motion state, or a combination) are defined by the product and recorded in veh.lockout.trigger; these guidelines do not mandate a single criterion, but require that the criterion be explicitly defined, explainable, and not oscillate back and forth near its boundary value (see VH1-4).

1. Six principles¶

The six principles divide design responsibility by normative object: each principle governs the obligations on one class of object, and each rule belongs to the one principle whose object is the direct normative object of that rule's obligation. Different objects mean the principles never substitute for one another — this is both the basis for the split and the way to test it.

Why split this way: the first four principles narrow progressively along the line of "what resources does one interaction consume" — VH1 governs how much glance and operation this interaction itself needs, VH2 governs whether this function can be reached at all, VH3 governs where the information appears, and VH4 governs when it appears, and how it queues against everything else. In real projects these four things are decided by different roles (interaction design, hardware and vehicle layout, display allocation, alert strategy), so the assignment is clear. VH5 stands alone because non-visual channels are systematically overrated inside the vehicle: they are often treated as the answer that "solves the distraction problem," when in fact they introduce a different kind of occupancy and a different set of failure modes that need their own conditions of standing. VH6 stands alone because of a fundamental difference between a cabin and a personal device — over its lifecycle a vehicle is driven by multiple people, sat in by multiple people, and changes hands, and treating personalization and accounts as a single-user problem is a persistent mistake in this domain.

The two boundaries that most need ongoing scrutiny are stated explicitly here: VH1 and VH2 — "this function should not be operated while driving" (VH1-4, lockout criteria) and "this function must be reachable while driving" (VH2-1, reachability) look like opposites, but they actually govern two different objects: VH1 governs whether one interaction's consumption of glance resources is acceptable, VH2 governs whether a function's necessity to vehicle control requires it to bypass screen navigation. Defrosting is touched by both at once — it must not be locked out (because it is safety-related vehicle control), and it should not require continuous glancing (because it is used while driving); the basis for assignment is the direct normative object of the obligation: "there MUST be an entry point that does not depend on menu navigation" belongs to VH2, and "operating this entry point MUST NOT require continuous glancing" belongs to VH1. VH4 and VH3 — for the same piece of prompt information, "should it appear on the instrument cluster or the center display" belongs to VH3 (division of carrying), while "should it appear right now, and which of it and three other prompts goes first" belongs to VH4 (timing and arbitration). If disputes over assignment keep recurring at these two boundaries in practice, the split of the principles should be adjusted, rather than adding an intermediate layer or supplementary notes.

Mutual exclusivity and exhaustiveness are a claim this split accepts being tested against, not a fact established by declaration: when a rule is added, removed, or its assignment is in doubt, verify it using the classification test in Appendix A.7. If it fails the test, what gets changed is the split of the principles. Principles are for understanding rules and adjudicating assignment; they are not, by themselves, a separate item to judge conformance against. Where 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 assignment does not mean a mechanism cannot be reused. A single estimate of "current driving load" serves both as the suppression condition for non-essential information (VH4-2) and as an input to interaction-depth convergence (VH1-6); a single determination of "who the current operator is" decides both whether the passenger exemption stands (VH1-5) and which subject personalization is written to (VH6-3); a single set of driving-state criteria both triggers function lockout (VH1-4) and affects display allocation (VH3-2). It is normal for the same mechanism to serve more than one purpose; which rule it is written under depends on the direct normative object of the obligation.

1.1 Start designing from one task¶

First pick a real outcome, for example "turn on defrost when the windshield fogs up," and only then decide the entry point, acknowledgment, and verification. Do not start from a screen layout or a Token checklist.

1.2 Choosing a solution for common problems¶

2. How to read a rule¶

2.1 The structure of each rule¶

Summarized in one sentence, the force of each part is this: the rule text specifies the requirement; "Applies to" and "Boundary conditions" together bound the requirement's scope; Design application, Verification examples, Counterexamples, and Basis and references add no obligation of their own.

A rule states the nature of the behavior, not the means of implementation: that a function MUST be completable while driving without continuous glancing at the screen is product behavior; whether it is done with a knob, a steering-wheel button, a fixed always-present touch zone, or voice is an engineering and vehicle-platform decision — the two must line up, but they are not the same deliverable. Nor do these guidelines specify physical dimensions, placement angles, or operating force; those fall under the ergonomics and regulatory categories excluded in the scope statement.

2.2 Normative terms¶

The rule text uses three tiers 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 — this is the sole basis for marking something "MUST."
• MUST NOT / forbidden: the inverse expression at the same strength as "MUST," identifying behavior that must not occur; in the main text, "must not" and "forbidden" are used interchangeably.
• 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 (VH1-6, VH4-6, VH5-3, VH5-5, and VH6-6 contain such clauses); the strength annotation on the rule heading and in the quick-reference table does not replace a clause's own binding force. "Cannot" in the main text is used only for statements of capability or fact, and does not express an obligation.

Strength indicates binding force, not importance.

2.3 The two sides of counterexamples¶

Counterexamples come in two sides: "under-delivery" is missing this requirement; "over-delivery" is turning the vehicle HMI into an unusable slab in order to satisfy it. In-vehicle HMI gets built badly at both ends, and both ends are dense with examples: at one end, phone interaction is carried over unmodified, and the driver has to dig through three menu levels while driving just to find defrost; at the other end, out of fear of being judged distracting, everything that can be done while driving is cut down to just volume — the navigation destination cannot be changed, the climate temperature needs three rounds of spoken commands, and the front passenger holding the screen cannot tap anything. The latter is equally wrong: locking a function out does not equal reducing risk — it often just chases the interaction onto the driver's phone, where the interaction has no lockout at all. Restraint is not the same as amputation; safety is not the same as unusable.

2.4 Rule quick reference: 35 rules¶

The table below is a one-sentence memorable version of every rule; click a rule name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and full requirements; a few [SHOULD] rules contain forbidden-level clauses (VH1-6, VH4-6, VH5-3, VH5-5, VH6-6), and the main text governs judgment (see 2.2).

VH1 The driving task comes first

VH2 Critical functions are not buried deep in the screen

VH3 Information lands in the right place

VH4 Interruptions are ranked by consequence

VH5 In-cabin multi-channel use has conditions of standing

VH6 The cabin is shared by multiple people

3. Rule details¶

This chapter lays out all 35 rules under the six principles. For the structure of each entry and the binding force of each part, see 2.1; the Design application, Verification examples, and Counterexamples within them are only notes to help implementation — they do not specify a single component, do not specify a vehicle-model platform, and do not require an additional standalone deliverable document. For the veh.* fields mentioned in the clauses, see Design Token.

3.1 VH1 The driving task comes first¶

The driver's gaze, hands, and attention inside the car are all limited resources that are already spoken for. This principle governs how much of these resources one interaction reaches for, under what conditions it must let go, and whether it can be picked back up after letting go. It does not govern whether this function should exist, nor which screen it sits on — those belong to VH2 and VH3 respectively.

VH1-1Interaction does not require continuous glancingMUST¶

In one sentence: Anything must be doable through a series of brief glances, not by staring at it until it's done.

Applies toall in-vehicle interface functions the driver can operate or may be required to read while the vehicle is in a driving-related state.

Ruleevery function available to the driver while driving MUST be completable in a series of discrete, brief glances; it is forbidden for a step to exist that can only be completed through continuous staring at the screen. The product MUST declare the test protocol it uses (recorded in veh.glance.method); the protocol must state the metric used, its unit, the statistic, the sample-judgment rule, the task's start and end points, the tested population, and the protocol's provenance — the determination is made using the protocol's complete judgment rule, not substituted by one or two scalars. The product MUST record the chosen protocol's cumulative visual-occupancy upper bound (veh.glance.total_max), explicitly distinguishing cumulative eyes-off-road duration from actual eye tracking from cumulative occlusion-open duration under the occlusion method. Beyond the protocol, a project may additionally set a hard single-glance upper bound (veh.glance.single_max); every adopted criterion must be accompanied by its measurement method, metric, statistic, and cited basis — these guidelines do not prescribe the values. Count does not equate to cumulative duration: glance count may serve as an independent design constraint, but it MUST NOT substitute for the cumulative-duration upper bound; single-glance maximum, mean, and long-glance proportion are different statistics and MUST NOT be converted into one another; task cumulative duration and these three are recorded separately. Results from substitute paradigms such as the occlusion method MUST NOT be entered as actual eye-tracking measurement results; their scope of applicability is declared per the chosen protocol. The source of an upper bound's value MUST state the test method, task category, and applicable population it is bound to — the time-based criteria in public guidelines each come with these conditions, and carrying a value over apart from its conditions does not constitute a basis (see reference.md). A function that does not satisfy the upper bound is handled per VH1-4: reshape it into a form that satisfies the bound, or restrict it while driving. "The driver will pay attention to the road on their own" is not accepted as grounds for passing.

Boundary conditionsthis clause does not require the passenger-side interface to satisfy the same upper bound (for the conditions under which the exemption stands, see VH1-5), does not apply to the parked state, and does not require every function to be available while driving. This clause constrains the visual occupancy required to complete the task, not the driver's voluntary extra glancing. A design-level upper bound can only constrain interface form up front; it cannot substitute for full-task driving-workload verification.

Design applicationturn "must be read in full before a choice can be made" into "a glance is enough to choose." List length, on-screen text volume, hierarchy depth, and the number of items to compare are all inputs to visual occupancy; reducing any of them lowers occupancy, whereas enlarging control size usually does not. When content that must be read is instead carried by audio, its occupancy is counted separately per VH5-4, not zeroed out automatically.

Verification examples

• User side: under the product's chosen measurement method (e.g., the occlusion method or a car-following task), have a participant not involved in the design complete the function, and record each glance and the total occupancy for completing the whole thing.
• Implementation side: check whether every function available while driving has a corresponding measurement record and measurement date; check whether new functions and revisions go through the same measurement before release, covering the tasks affected by the change.

Counterexamplesunder-delivery — changing the navigation destination while driving requires reading through more than a dozen candidates and comparing their road names; over-delivery — every list is cut down to three items and made non-scrollable, and the one the user wants is always the fourth item, so they pull out a phone instead, on which there is no upper bound at all.

Basis and referencespublic guidelines do have acceptance criteria for single-glance and total-task occupancy, but they belong to different measurement protocols, each with its own sample-judgment rule and voluntariness statement (R01, R03, R07, R16; for method standards see R04, R06). For risk-direction evidence see R19, where "a non-specific eyes-off-road glance is not by itself significant, and checking a mirror can even reduce risk" is the direct reason this clause constrains only the occupancy required to complete the task and does not constrain glancing as such.

VH1-2A task can be interrupted in segments and resumed from where it left offMUST¶

In one sentence: The moment conditions change it can be stopped, and once conditions are good it can be picked back up from where it stopped.

Applies tomulti-step tasks available while driving, including destination setting, communication, media search, vehicle settings, and account operations.

Rulea multi-step task available while driving MUST be interruptible by the driver at will between any two steps, and MUST also be able to yield when the system arbitrates per VH4. Completed portions and unsubmitted input at the time of interruption MUST be preserved. Before resuming, the vehicle state, the objects involved, and the validity of the following steps MUST be re-checked: if still valid, resume from the interruption point; when the interruption point has become invalid (the intersection has been passed, the candidate has expired, the selected object no longer exists), resume to an explainable logical node and state the reason, avoiding unnecessary re-entry. A completed portion that is still valid MUST NOT require redoing, and an invalidated interruption point MUST NOT be forcibly resumed. The interruption point MUST fall on a semantically complete boundary: it is forbidden to discard already-entered content partway through a step, and it is forbidden to treat a half-finished state at the interruption point as submitted and let it produce a real consequence. The validity period for resumption, the resume entry point, and what happens after expiry MUST be explicitly defined (recorded in veh.lockout.resume.ttl).

Boundary conditionsthis clause does not require indefinitely preserving an interrupted state, nor does it require that an action that has already produced a physical consequence be undoable; a physical consequence that has already occurred must be stated truthfully, and the obligation to preserve input is not thereby waived. For steps with external consequences, such as payment or outgoing communication, resumption requires re-confirmation rather than automatically continuing. Preserving data and continuing to display the interface are two different things: collapsing the keyboard or input panel when the vehicle enters a driving-related state is compliant convergence (see VH1-6), as long as the data is not lost or submitted because of it.

Design applicationcut a long task into segments that can each end cleanly, with the state clean at the end of each segment; do not treat "the user stepped away partway through" as an exceptional branch — it is the normal path in this domain. The resume entry point should appear where the user would naturally look next, rather than requiring them to remember where to find it.

Verification examples

• User side: trigger an incoming call at the second step of entering a destination, and after the call ends, observe whether it returns to the second step with the first step's input still there.
• Implementation side: for each multi-step task, list its interruption points and the persistence scope at each point; check whether behavior after resumption has expired matches what is declared.

Counterexamplesunder-delivery — the destination is half-entered, a call comes in, and returning requires re-entering it; over-delivery — a half-finished task from three months ago pops up every time the car is started, asking whether to continue, and the resume prompt itself becomes a source of interruption.

Basis and referencesR02's 4.3.4.2 and 4.3.4.3, and R03's Chapter 5, both require that an interaction sequence be interruptible and resumable from the interruption point or another logical point. Neither specifies a validity period for resumption; this clause's validity-period requirement is derived by working backward from the commitment.

VH1-3The system does not manufacture unrequested glances on its ownMUST¶

In one sentence: Do not use animation, auto-jumps, or countdowns to pull the driver's eyes over.

Applies toall display positions within the driver's field of view while driving, including the center display, instrument cluster, head-up display, and ambient lighting and other elements capable of conveying information.

Ruleabsent a driving-related necessity, the system is forbidden from drawing the driver's gaze to the screen through animation, auto-jumps, autoplay, content carousels, countdowns, flashing, or a conspicuous visual change. An interface change while driving MUST be triggered by user action or by an event already graded per VH4-1. "The system did not require the user to look" does not mean "the user will not look": a change's visual salience itself constitutes glance inducement, and the permissible range of salience is defined by the product (recorded in veh.surface.motion.policy) and included in VH1-1's verification. Countdowns and auto-advance are especially restricted: they shift the cost of not looking onto the user, and are forbidden for content that is not safety-related.

Boundary conditionsthis clause does not forbid necessary driving-related changes — the updating of a turn prompt, the appearance of an alert, and the presentation of a mode change are all outside this clause's restriction; their timing and grading are determined per VH4. This clause also does not require the interface to be completely static.

Design applicationdistinguish "the state changed" from "you need to look now." The former can land through a low-salience means and be discovered on the driver's next glance; only the latter needs a conspicuous change, and it must first pass VH4-1's grading.

Verification examples

• User side: while driving, perform no operation and record, over a period of time, how many conspicuous changes the interface produces on its own and their trigger source.
• Implementation side: check whether every animation and auto-jump can name its triggering event and the level it belongs to; inability to name one is exactly the situation this clause is meant to prevent.

Counterexamplesunder-delivery — the center display cycles through promotional cards while driving, or an app-store update notice slides out with animation; over-delivery — to avoid any change at all, even the turn prompt is made static, updating only after the intersection has been passed.

Basis and referencesR02's 4.3.1.3 requires that the system not visually entertain the driver; R03's Annex 2 forbids displaying moving video and scrolling text while driving; R13 uses animation frame rate as a criterion, and R15 forbids animated elements and auto-scrolling text, showing that this kind of constraint has already been mechanized at the platform level. This clause's requirement that a trigger event and its level "must be nameable" is a design derivation of these guidelines.

VH1-4Restrictions while driving have a criterion and are explainableMUST¶

In one sentence: Locking out a function requires being able to state the basis, and also when it becomes usable again.

Applies toany function that is locked, grayed out, narrowed, or changed in form while driving.

Ruleany function restricted while driving MUST have an explicit trigger criterion (recorded in veh.lockout.trigger), an explicit exception list, and an explanation visible to the user — stating why it is currently unavailable and under what condition it becomes available.

Every vehicle operating fact used for the restriction determination MUST carry a source, a sampling moment, and a validity. When valid evidence sufficient to prove relaxation is warranted has not been obtained, a park-exclusive function is not opened up — no vehicle-speed signal received, a stale park value read after waking from sleep, gear and brake signal timestamps that conflict with each other, or zero speed without being in park, all count as insufficient evidence, and unlocking long-term on the basis of the last known "in park" state is forbidden; at such times the vehicle's critical controls must still be reachable. A continuous-quantity criterion MUST define hysteresis, and a discrete signal MUST define debouncing or a stability determination; toggling on and off repeatedly near the threshold is forbidden; but no form of stabilization processing may improperly delay a restriction that should already be in effect. Relaxation under an automated mode likewise requires checking the driver's actual responsibility under that mode. Lockout is one optional risk-control means among others, not the default strategy: before a function is locked out, it MUST first be assessed for whether it can be reshaped into a form that satisfies VH1-1, and the user's actual alternative path after lockout must be assessed as well — including the path of "the user will switch to operating it on a phone", a path with no restriction whatsoever; treating it as zero-cost is exactly the judgment error this clause is meant to prevent. But the assessment of alternative paths MUST NOT be used to exempt an already-applicable forbidden-class requirement, nor may "the user will switch to a phone" be treated as an already-proven inevitable outcome that offsets an applicable requirement. Content that falls within the prohibited scope of an applicable jurisdiction, scoring protocol, or company standard is locked out per that requirement, and this clause provides no relief. Safety-related functions within the VH2-1 list are forbidden from being locked out by an infotainment distraction strategy; the vehicle's own action interlocks remain in effect, for example refusing a disallowed shift request while in motion. A reachable entry point does not mean it is executable in every state.

Boundary conditionsthis clause does not prescribe the sole criterion for "while driving" — speed, gear, parking brake, motion state, or a combination may all serve; what is required is that the criterion be explicitly defined and explainable. For a vehicle with driving-automation capability, the product MUST make clear the human's monitoring and takeover responsibility under each mode; automation being active does not automatically lift this clause's restriction requirement — the driver may be asked to take over at any time, and the relaxation of a restriction must be commensurate with the driver's actual responsibility under that mode, not with the system's marketing name.

Design applicationfirst ask "can this be made completable with a glance," then ask "does it need to be locked." When a restriction is genuinely needed, put the explanation and the recovery condition somewhere the user will see, rather than leaving only a grayed-out control.

Verification examples

• User side: repeatedly cross the threshold speed and observe whether the function toggles on and off repeatedly; tap the restricted function and observe whether it gives a reason and a recovery condition.
• Implementation side: list every restricted function together with its criterion and exceptions; check whether each has an assessment record for "can it be reshaped."

Counterexamplesunder-delivery — a batch of settings goes gray while driving, stating neither why nor when it will be usable again; over-delivery — nearly every function gets locked as soon as speed is above zero, including the media search the front passenger is currently using, so the user ends up using a phone the whole time.

Basis and referencesR02's 4.3.5.3 requires that a function not intended for use while driving be made non-interactive; R12 and R14 note that the mapping between the restriction set and driving state is configured by the vehicle manufacturer rather than being a platform constant, supporting this clause's treatment of the criterion and scope as product input. No direct supporting public source was found this time for the assessment requirement that "the alternative path includes the user switching to a phone"; it is a design judgment derived from the failure mode.

VH1-5The passenger exemption must have grounds for standingMUST¶

In one sentence: "I'm a passenger" by itself is not grounds for an exemption.

Applies toany mechanism that relaxes driving restrictions on the grounds that "the current operator is not the driver."

Rulerelaxing a driving restriction on the grounds of "the operator is a passenger" MUST have a statable determination basis, and the basis MUST be stronger than a single declarative tap. The determination basis, the direction of possible misjudgment, and the consequence of misjudgment MUST be explicitly recorded (veh.occupant.role.evidence). The exemption's default direction MUST lean conservative: when the determination does not hold or evidence is insufficient, treat it as the driver. The exemption's scope of effect is limited to the display area and input devices that passenger can reach; the passenger-side exemption is forbidden from changing what is presented at the driver's seat (see VH6-2). The operator-identity basis and the content-exposure condition MUST hold at the same time: reliably determining that the operator is a passenger does not automatically permit presenting content restricted while driving in an area visible to the driver — a shared center display, an area the driver's gaze can sweep across, and a presentation that could produce a reflection are all part of the exposure condition and must be assessed and recorded together. When the passenger side has an independently and effectively isolated display and input, that path is not blanket-disabled purely out of conservatism. The exemption mechanism itself is forbidden from requiring the driver's participation to confirm it — that would turn an exemption into a driver operation.

Boundary conditionsthis clause does not forbid using a declarative confirmation as one piece of evidence among several; what is forbidden is using it as the sole basis. This clause does not require equipping a specific occupant-sensing capability; when it is not present, treat the exemption as not holding and retain the driver-side restriction — this is a conformant outcome.

Design applicationusable evidence includes the physical location and viewing angle at which the operation occurs, seat-occupancy state, the ownership of the input device, and the temporal mutual-exclusivity with driver input. The determination rule for combining evidence should be written down and re-checkable, rather than scattered across a number of conditional checks.

Verification examples

• User side: have the driver attempt to trigger the passenger-exemption path from the driver's seat, and observe whether it holds.
• Implementation side: check whether the evidence items and thresholds for the exemption determination can be listed; check whether the default branch when evidence is missing is "treat as the driver."

Counterexamplesunder-delivery — an "I'm a passenger" checkbox unlocks every function with one tap from the driver; over-delivery — the front-passenger-side screen is blanket-unavailable while driving, with even the volume requiring the driver to handle it, so the risk is shifted onto the driver instead.

VH1-6Convergence and recovery on driving-state change are definedSHOULD¶

In one sentence: When the car starts moving, how the interface pulls back; when it stops, how things are put back.

Applies tointerface behavior as the vehicle switches between stationary and driving-related states.

Rulethe interface's convergence and recovery behavior on a state switch SHOULD be explicitly defined: what content collapses, what is retained, and which step it returns to on recovery (recorded in veh.lockout.transition). Convergence is forbidden from losing unsubmitted user input, and is also forbidden from treating unsubmitted content as submitted (see VH1-2); collapsing the input interface itself is a compliant means of convergence — this clause constrains the persistence of data, not a requirement that interface elements remain on screen. Recovery is forbidden from automatically bringing the user back to an interface that requires prolonged staring, and MUST NOT auto-expand a large amount of content the instant the vehicle has just come to a stop — the driver may be completing the act of parking at that moment. When the state switches back and forth repeatedly within a short time (congestion, stop-and-go), there SHOULD be suppression to avoid the interface repeatedly changing shape; the suppression window is defined by the product with its basis recorded.

Design applicationthe goal of convergence is to reduce occupancy, not to clear everything. Collapsed content should come back in the same place in a predictable way, rather than requiring the user to navigate back to it.

Verification examples

• User side: drive for a period on a low-speed congested stretch and record how many times the interface changes shape due to state switching.
• Implementation side: for every convergence behavior, check whether its recovery path is defined and whether unsubmitted content is preserved.

Counterexamplesunder-delivery — the interface switches wholesale the instant the vehicle starts moving, and content the user just entered disappears; over-delivery — after parking, getting back to what was just collapsed requires manually expanding it layer by layer, turning convergence into a one-way operation.

3.2 VH2 Critical functions are not buried deep in the screen¶

Some functions are directly related to vehicle control: defrost is needed when the windshield can't be seen through, hazard warning is needed when stopped roadside with a fault, wipers are needed when it rains. The moment these functions are needed is exactly the moment the driver has the least spare capacity to go looking for them. This principle governs whether this class of function can be reached, felt out, whether it moves, and whether it is still there when the system has a problem — not how much glancing its operation costs (that is VH1), and not where the related information is displayed (that is VH3).

VH2-1Safety-related functions do not live only deep in a touchscreen menuMUST¶

In one sentence: Defrosting, hazard warning, wipers, and lighting should not require digging through menus first.

Applies toall vehicles with an in-vehicle human-machine interface, regardless of automation capability.

Rulethe product MUST explicitly define a critical function list (recorded in veh.control.critical.set). The list is itemized as function + action; each entry MUST record: whether this vehicle is equipped with it, the basis for inclusion or a not-applicable determination, the menu-free-entry requirement, the blind-operation requirement, and whether the entry is driver-exclusive or allows passenger collaboration (e.g., helping to turn on hazard warning, excluding gear shifting and vehicle motion control; corresponding to VH6-2).

The following entries MUST be checked off individually with a conclusion given for each: turn signal (left/right on), gear shift (drive/neutral/reverse selection), hazard-warning flasher (on/off), horn (sound), front and rear windshield defrost/defog (on/off), front and rear wipers and washer (on/speed adjust/off/spray washer fluid, manual mode), manual control of headlights and position lights (on/off, including high beam on/off), an equipped emergency call (initiate), and any items separately required by an applicable jurisdiction or a participating third-party scoring protocol. When this vehicle genuinely is not equipped with an entry, record it as not applicable and state the basis (e.g., no rear wiper, no rear-windshield heating); not applicable is a conformant conclusion, and this clause does not require fabricating hardware to pad out the list, but "not on the list" MUST NOT be used to substitute for this check.

Every item on the list is forbidden from being reachable only through touchscreen menu navigation: there MUST exist an entry point that does not depend on menu hierarchy, does not depend on the current foreground app, and does not depend on screen unlock or wake. The form of the entry point is chosen by the product — a physical control, a fixed steering-wheel button, or a fixed, always-present direct on-screen control are all acceptable; these guidelines do not specify the form, only that the entry point not depend on the four things above.

Ordinary high-frequency functions such as volume, temperature, and seat heating are recorded separately in veh.control.frequent.set, and do not enter the critical function list: they are subject to VH2-2's blind-operation requirement, but they do not carry VH2-6's failure-reachability obligation, nor are they subject to VH6-2's ban on passengers affecting critical-function state — mixing them into the critical list would both dilute the reachability of critical items and wrongly forbid a passenger from adjusting shared state on their own side.

Boundary conditionsthis clause does not determine a local jurisdiction's mandatory requirements for physical controls, nor does it substitute for any third-party scoring protocol's scoring determination (for related public policy see reference.md); the product must still confirm applicable requirements on its own and may expand the list. This clause does not require every function to have a menu-free entry point — functions outside the list are not constrained by this clause; the boundary of the list is the unit of determination for this clause and for VH2-2, VH2-5, and VH2-6. VH2-3 and VH2-4 do not take this list as their unit of determination: the former applies to all near-hand controls, the latter applies to all in-vehicle input triggerable while driving, and both hold equally for controls outside the list.

Design applicationturn the must-check entry table into a checklist filled in row by row — function, action, whether equipped, basis, form of the menu-free entry point, blind-operation characteristics, passenger collaboration scope — a blank cell is a gap. Once the list is settled, it becomes the shared object acted on by VH2-2, VH2-5, and VH2-6, and also becomes VH1-4's lockout exclusion zone.

Verification examples

• User side: while a full-screen third-party app is running, and right after the head unit powers on, separately time the number of operating steps needed to reach each item on the list and whether looking at the screen is required.
• Implementation side: pull the list and its basis table, and check off each must-check entry has a conclusion; for entries recorded as not applicable, check that the hardware genuinely does not exist. Check whether each entry point is reachable in any foreground state; take a separate vehicle model without a rear wiper and verify that "not applicable" is not judged as a missing item, and verify that a passenger adjusting the temperature on their own side is not wrongly judged as violating VH6-2 because it is a high-frequency function.

Counterexamplesunder-delivery — defrost sits on the third level of "climate — more — windows," and hazard warning is in the pull-down bar at the top of the screen; over-delivery — turning twenty-some functions into physical buttons packed together, forming a sea of buttons that can't be told apart by feel, so that no one can actually operate it blind (see VH2-2).

Basis and referencesR08 (Driver Engagement) §2.2.1–2.2.4 specifies, item by item on a function + action basis, implementations that can be judged a pass, and distinguishes direct physical input, direct touch input, and menu-style touch input of no more than two steps — for example, turn signal, gear shift, hazard warning, e-Call, horn, high beam, and wipers (manual mode) and the vehicle-assist set speed require direct physical input, while external light switches, headlight-height adjustment, and rear-windshield defrost can accept menu-style touch of no more than two steps. This clause's must-check entries reference that table and R23's scope of applicability. R27 (SD-203) §1 specifies that a nonexistent function/action is always recorded N/A; this clause's handling of "not applicable" follows the same approach.

Two places where these guidelines are stronger than the source, and must be recorded as claims of these guidelines' own: first, R08 allows menu-style touch for some entries, while this clause requires a menu-free entry point for every entry on the list; second, VH2-2 requires every item on the list to be blind-operable, while R08 only requires "direct physical input" entries to have a position discoverable by feel. The necessity of these two strengthenings and verification against the target population is the product's responsibility, and this scoring protocol MUST NOT be used to vouch for them. R08 is a consumer rating protocol, not a regulation; its consequence is a score, not a sales ban; a product that has not committed to participating in that rating is not judged "non-compliant with certification" for failing to meet its criteria. R23 governs only control position, identification, color, and lighting, and does not equate to a regulatory requirement for physical buttons.

VH2-2Critical controls can be operated blindMUST¶

In one sentence: Reach over and it can be found and confirmed, without looking down.

Applies toentry controls for functions on the VH2-1 list, and controls such as volume and temperature that are used frequently while driving.

Rulea control on the list MUST allow all three of locating, identifying, and confirming to be completed without looking at it: locating relies on a stable physical position or a boundary distinguishable by touch, identifying relies on position, shape, or texture rather than printed or on-screen labeling alone, and confirming relies on a non-visual acknowledgment (see VH5-3). A flat touch zone distinguished only by visual labeling does not satisfy this clause — an area whose boundary a finger cannot feel does not constitute a blind-operation entry point. Where controls need to be distinguished from one another, their tactile difference MUST be deliberately designed rather than incidental, and MUST be verified under conditions the product declares support for, such as wearing gloves.

Boundary conditionsthis clause does not specify a control's size, spacing, or operating force, which fall under the ergonomics and layout categories excluded in the scope statement; what this clause specifies is the behavioral nature of being "locatable and identifiable non-visually." This clause does not forbid overlaying a visual label on a physical control.

Design applicationmeans of tactile distinction include a positional reference (along an edge, against a fixed object), shape difference, surface-texture difference, and difference in operating motion (turn, flick, press). There is a cognitive limit to how many differences can be held; making every key a different shape turns identification itself into a burden.

Verification examples

• User side: with participants not looking, have them trigger each item on the list from a normal driving posture, and record the success rate and any mis-touches before first reaching the target.
• Implementation side: list the tactile distinguishing feature of each control; check whether any adjacent controls are distinguished only by printed or on-screen labeling.

Counterexamplesunder-delivery — defrost is made into a flat touch zone with four icons side by side, and a finger cannot tell which one it has touched; over-delivery — every button is made a different odd shape, and the burden of remembering shapes exceeds the burden of finding the button in the first place.

Basis and referencesR08 §2.2.2 requires that the relevant interaction area be tactilely identifiable or large and separated enough; R01's V.I and R02's 4.3.4.1 both require that the driver be able to keep at least one hand on the steering control. This clause does not adopt R08's size-threshold values, because they are coupled to that protocol's spacing clauses and belong to a different system (see R25's boundary notes).

VH2-3The function binding of near-hand controls is stable and knowableMUST¶

In one sentence: What the same button does this time and what it does next time must be statable clearly.

Applies tocontrols the driver can reach without moving the body, such as steering-wheel buttons, stalks, and center-console knobs.

Rulefor a near-hand control that carries an entry on the VH2-1 list, its binding to that entry MUST remain stable, not changing with context, foreground app, or a temporary mode; other (non-listed) bindings on the same control may vary with context according to a rule made explicit in advance, but MUST NOT cancel, obscure, or relocate the entry for a listed entry. The bindings of other near-hand controls may vary with context, but may change only according to a rule the product has made explicit and recorded in advance (recorded in veh.control.nearhand.binding): the trigger condition for a change, the function set after the change, and the reset path MUST all be determined in advance, and arbitrary change following the foreground app is forbidden. For any binding that varies with context, its current function MUST be knowable without prolonged staring (which display position the indication lands on is defined by VH3-2's division of labor). A temporary mode (car wash, towing, showroom, service, etc.) may change the binding of non-listed controls, but MUST NOT cancel or relocate the entry for a listed entry. The same control is forbidden from being dynamically reused between a VH2-1 listed function and a non-listed function — that would remove the precondition for blind operation. When a binding is user-configurable, the configuration MUST be resettable, and the default binding after reset MUST be deterministic (see VH6-3).

Boundary conditionsthis clause does not forbid context-dependent controls; what is forbidden is a change that is unknowable or unpredictable. A temporary mode the user has explicitly entered may change non-critical bindings, but entry, current binding, and exit MUST be discernible, and protection of critical entry points still holds.

Design applicationsplit near-hand controls into two categories and treat them separately: one permanently bound (volume, calls, listed functions), one context-dependent (media, navigation, driver assistance). Write down the dividing line between the two categories, and do not let it change with the foreground app or account.

Verification examples

• User side: press the same button under three different foreground apps and record whether the behavior is consistent or whether any change matches user expectation.
• Implementation side: list every possible binding of each near-hand control and its trigger condition; check whether any reuse crosses the list boundary.

Counterexamplesunder-delivery — the steering-wheel scroll wheel is volume in the media screen and becomes zoom in the navigation screen, and the user only finds out by pressing it; over-delivery — every near-hand control is permanently fixed, and the user's most-used new function has no way onto a control within reach and must be found on the screen instead.

VH2-4The consequence of a mis-touch under jolting conditions is limitedMUST¶

In one sentence: If the car jolts and it gets bumped, nothing consequential should happen because of that.

Applies toall in-vehicle input triggerable while driving, including touchscreen, physical controls, and gestures.

Rulein-vehicle input MUST be designed on the premise that unintended triggering will occur under vibration, jolting, and lateral-acceleration conditions; using "the driver will be careful" as a design assumption is forbidden. An operation that would produce a consequence difficult to undo is forbidden from being triggered by a single instantaneous point-touch alone; its confirmation method should make use of motion characteristics not easily reproduced by jolting — a specific location, a sustained duration, a directional motion, or a secondary action — rather than relying only on enlarging the control. A reversible operation MUST have an undo path after a mis-trigger occurs, and it must be usable without prolonged staring. An operation that has already produced a physical consequence or has already been sent externally is not promised to be restorable to its original state: such an operation must provide an applicable abort, stronger mis-touch protection, and a truthful remediation statement; describing it as "undoable" beyond its actual capability is forbidden.

Boundary conditionsthis clause does not specify control size, spacing, or operating force (see the scope statement). This clause does not require adding confirmation to every operation — adding confirmation to low-consequence operations across the board dilutes the meaning of confirmation, and this is the inverse failure mode of this clause; an urgent or immediate control action is forbidden from incurring an unacceptable delay because of a generic secondary-confirmation template. In-vehicle input SHOULD be completable with one hand, and does not require the driver to release both hands from the primary driving controls at the same time; this clause does not specify ergonomic dimensions or layout values.

Design applicationfirst tier operations by consequence, then decide on mis-touch protection measures. A high-consequence, low-frequency operation may require a stronger motion characteristic; a low-consequence, high-frequency operation should remain a single trigger while ensuring it is undoable.

Verification examples

• User side: drive under road conditions the product declares support for, and record where unintended triggers occur and their consequence level.
• Implementation side: list every operation that is difficult to undo and its trigger condition; check whether any of them requires only a single instantaneous point-touch.

Counterexamplesunder-delivery — a jolt in the road brushes a hand against the screen, and the entire navigation route is canceled with no way to undo it; over-delivery — every one-degree adjustment to the climate temperature requires a second confirmation, so the user switches to voice instead, and the voice path itself was not built properly (see VH5-1).

VH2-5Critical entry points do not disappear due to personalization, theming, or updatesMUST¶

In one sentence: The owner changed the skin, the head unit was upgraded, and defrost is still where it was.

Applies toentry points for functions on the VH2-1 list, before and after theme switching, layout customization, driving-mode switching, account switching, and software updates.

Rulethe entry position and operating method for a listed function are forbidden from being changed by a theme, skin, user-customized layout, driving mode, account switch, or software update to the point where relearning is needed. A personalization system is forbidden from treating a listed entry point as an object the user can remove, hide, or demote. When a position change is genuinely necessary, it MUST be treated as a behavior change: with a basis, notified before it takes effect, and given a transition. On an account switch, the position of a listed entry point is forbidden from changing with the account.

Boundary conditionsthis clause does not freeze interface evolution, nor does it forbid improving the layout; what it constrains are two things: an unnotified relocation and handing a critical entry point over to personalization.

Design applicationplace listed entry points within a protected layout region that does not participate in personalization's free rearrangement, and whose structure does not change with the theme.

Verification examples

• User side: switch through every available theme and driving mode, then switch account, and record whether the position of listed entry points changes.
• Implementation side: check whether the set of objects a personalization configuration can act on excludes listed entry points; check whether the update process includes detection and notification of entry-point relocation.

Counterexamplesunder-delivery — after an update, defrost moved from a fixed bar into a new climate card; over-delivery — freezing the entire interface for the sake of stability, forgoing even obviously better improvements.

VH2-6Critical functions remain reachable while the system is not ready, faulted, or updatingMUST¶

In one sentence: The screen hasn't come up, or is updating — safety-related functions cannot disappear along with it.

Applies tohead-unit startup, app crashes, display failure, software upgrade, system degradation, and low-battery protection, and other abnormal states.

Ruleunder the states above, functions on the VH2-1 list MUST remain reachable, and their availability is forbidden from depending on the infotainment system or center display being in normal working condition. The product MUST explicitly define, for each item, the reachable path and the failure-notification method under each type of failure (recorded in veh.control.critical.fallback). Making a listed function unavailable during an upgrade is permitted only when three conditions hold at the same time: the function has been individually and explicitly listed and approved through a dedicated analysis; the vehicle is in a parked state that permits this maintenance; and it has been ensured that the vehicle cannot, during this period, enter a state of use that depends on that function. Before starting, the affected functions, the scope of impact, and the expected recovery condition MUST be stated, and the user MUST be allowed to choose the timing to start; the user choosing the timing does not substitute for the three conditions above. After a failed upgrade, the corresponding usage restriction MUST be maintained, and a practically workable recovery path MUST be provided; entering a process that makes a critical function unavailable without the user's knowledge is forbidden.

Boundary conditionsthis clause does not determine functional-safety-level classification, redundant architecture, or failure-rate requirements, which fall under the functional-safety category excluded in the scope statement. What this clause requires is that a reachable path be defined and verified, not that a specific hardware redundancy scheme be adopted.

Design applicationkeep the control chain for listed functions and the infotainment chain conceptually separate in the design, even when they share hardware. During startup, make listed entry points available first, before loading the rest of the content.

Verification examples

• User side: immediately after a cold start, try to trigger each item on the list, and record the time from power-on to each item becoming available; repeat during an upgrade.
• Implementation side: for each type of injected failure, check the actual reachability of each listed item and whether a failure notification is given.

Counterexamplesunder-delivery — during the tens of seconds the head unit takes to start, neither defrost nor hazard warning can be tapped, and there is no explanation on screen at all; over-delivery — for the sake of redundancy, every function gets two entry points, and the two states disagree, leaving the user to guess which one is real (for the consistency requirement see VH3-6).

3.3 VH3 Information lands in the right place¶

There are several places in the car that can display things, and each has a completely different relationship to the driver's gaze: the instrument cluster sits a little below the line of sight, the head-up display overlays it, the center display requires turning the head, and voice takes up no gaze at all. This principle governs which class of information should land at which position, how much each position can carry at most, and whether that still holds under lighting and failure conditions. It does not govern whether this piece of information should appear right now (that is VH4), nor how much glancing it costs to operate (that is VH1).

VH3-1Driving-critical information does not appear only on the center displayMUST¶

In one sentence: The driver's gaze is not on the center display — do not put anything important only there.

Applies toall information presented to the driver while the vehicle is in a driving-related state.

Rulethe product MUST explicitly define a driving-critical information list (recorded in veh.surface.critical.set); every item on the list is forbidden from appearing only on the center display. Such items MUST appear at a position the driver's gaze already passes through while performing the driving task — the instrument cluster or the head-up display — or be carried by a non-visual channel suited to that information (audio, haptic; for the conditions under which a channel stands, see VH5-2). Information that must be continuously visually presented by law must not be substituted with a single alert tone. The list must cover at least: vehicle state and fault alerts, the current effective mode of driving automation and takeover requests, immediate turn and lane guidance, and items an applicable jurisdiction requires the instrument cluster to carry. Information "also" being on the center display does not substitute for its presentation at its primary position.

Boundary conditionsthis clause does not specify the concrete allocation of each piece of information between the instrument cluster and the head-up display, which is defined by VH3-2; it does not specify the instrument cluster's statutory markings, symbols, and lighting requirements (see the scope statement); nor does it require every item on the list to be placed simultaneously in multiple positions — allocation is the default, redundancy needs a reason.

Design applicationthe basis for settling the list is "what happens if it's missed," sharing its origin with VH4-1's grading basis but serving a different purpose: VH4-1 decides when it appears, this clause decides where it appears. The two should reference the same consequence assessment rather than each doing one separately.

Verification examples

• User side: have a participant report the current value of each item on the list from a normal driving posture, and record items that require turning the head.
• Implementation side: for the list, itemize the presentation position of each entry; check whether any item exists only on the center display.

Counterexamplesunder-delivery — an abnormal tire-pressure reading only shows a small icon on the vehicle-information page of the center display; over-delivery — copying all information onto the instrument cluster as well, turning it into a second center display, so the real alert gets buried within it (for the information-volume upper bound see VH3-2).

Basis and referencesR01's V.D requires that a visually dense display be as close as practically possible to the driver's forward line of sight; R02's 4.3.2.4 has the same intent; R08's §2.1.1.3 requires that lighting and driver-assistance state sit within the driver's direct line of sight; R03's Annex 1 gives an angular range for mounting position. These guidelines do not adopt the angular values within it, which fall under the layout and field-of-view verification excluded in the scope statement.

VH3-2The division of carrying for each display position is explicitly definedMUST¶

In one sentence: What the instrument cluster, head-up display, center display, and voice each carry is written down in advance.

Applies toevery display position and output channel in the vehicle, including the instrument cluster, head-up display, center display, front-passenger display, rear-seat display, voice, audio prompts, and haptics.

Rulethe product MUST explicitly define, for each display position and output channel, which class of information it carries, which it does not, and the upper bound on how much it carries (recorded in veh.surface.role). The division of labor MUST cover "when the same information appears in multiple places, which one is the primary position." When the division of labor changes with the situation (entering an automated mode, entering reverse, entering charging), the rule for change MUST be defined in advance, and modules are forbidden from contending for a display position on their own at runtime. In the absence of a defined division of labor, information will land in the order its function shipped rather than by driving relevance — this is the failure mode this clause is meant to prevent.

Boundary conditionsthis clause does not specify the concrete content of the division of labor, since a reasonable division differs across vehicle models and hardware configurations; what is required is that the division be made, recorded, and consistently enforced. This clause does not forbid situational rearrangement.

Design applicationa division-of-labor definition must at minimum state four things clearly: the categories of information this position carries, the maximum number of concurrent items, which categories explicitly do not land here, and the rearrangement rule for situational changes. When a new function is integrated, judge its placement against the division of labor, rather than modifying the division of labor to fit the new function.

Verification examples

• User side: in a scenario where a navigation turn, an incoming call, and a vehicle prompt occur at the same time, record whether the actual content presented at each display position matches the division of labor.
• Implementation side: pull the division-of-labor definition; sample a number of functions and check whether their actual placement matches the definition, and whether the information volume exceeds the upper bound.

Counterexamplesunder-delivery — every new function decides for itself which screen to land on as it ships, and the instrument cluster ends up with six differently sourced prompt bars coexisting; over-delivery — the division of labor is fixed so rigidly that even obviously reasonable situational changes, such as a simplified night view or rearrangement while reversing, cannot be implemented.

VH3-3The head-up display does not occlude or misalign with the real sceneMUST¶

In one sentence: Something overlaid on the road is worse than no overlay at all if its position doesn't line up.

Applies tovehicles with a head-up display or other display capability overlaid on the driver's forward field of view.

Rulehead-up display graphics are forbidden from occluding real-scene elements the driver needs to see, and are also forbidden from continuing to present in a scene-locked form when registration with the real scene does not hold. When registration error exceeds the tolerance defined by the product, or when positioning or perception confidence is insufficient, it MUST degrade to a presentation form that does not claim spatial correspondence, or the graphic MUST be removed; guidance at the wrong position is forbidden from continuing to be overlaid on the road. The head-up display's information-volume upper bound, available display area, and permitted degree of motion are constrained by VH3-2's division of labor, and motion effects are constrained by VH1-3.

Boundary conditionsthis clause does not specify projection distance, field of view, brightness, or virtual-image position values, nor does it determine windshield optical characteristics or related regulatory requirements (see the scope statement). This clause does not require every head-up display to have scene-registration capability — a presentation form that does not claim spatial correspondence is not subject to the registration requirement.

Design applicationmanage "guidance locked to the road" and "fixed-position numeric values" as two separate categories: the former depends on registration and confidence and MUST have a degradation path; the latter does not depend on them, but occupies display area and is subject to the information-volume upper bound. Degradation must be perceptible to the user, or the user will keep interpreting it as scene-locked.

Verification examples

• User side: observe the behavior of guidance graphics on stretches where positioning accuracy drops (tunnels, under elevated roads, dense urban areas).
• Implementation side: check whether the registration tolerance and confidence threshold have values and a basis; inject a loss of positioning and observe whether it degrades or is removed.

Counterexamplesunder-delivery — a turn arrow is locked to the road but offset by one lane, and the driver follows it into the wrong lane; over-delivery — out of concern over registration errors, the head-up display keeps only the numeric speed, effectively giving up this display position (for the division-of-labor requirement see VH3-2).

VH3-4Legibility is verified under actual lighting conditionsMUST¶

In one sentence: Unreadable at night, in backlight, or in bright glare is the same as not being displayed at all.

Applies toall in-vehicle visual displays, including the instrument cluster, head-up display, center display, and illuminated markings on physical controls.

Rulelegibility MUST be verified across the range of actual lighting conditions the product declares support for; the verification conditions must cover at least: direct midday sun and backlight, nighttime, rapid light/dark transitions entering and exiting a tunnel, and reflection and glare caused by the headlights of vehicles behind. The declared range of supported conditions, the verification method, and the results MUST be recorded (veh.surface.legibility.conditions). The presence of automatic brightness adjustment does not by itself constitute evidence that this clause is satisfied — the adjustment process itself takes place during the very seconds the driver needs to read the information. Contrast, glyph, touch-target size, and spacing MUST be tied to the actual display position, viewing distance, physical dimensions, and test conditions, and CSS pixels must not be taken directly as the head unit's physical dimensions.

Boundary conditionsthis clause does not determine regulatory conformance for lighting and photometry (see the scope statement). The product must cover the foreseeable lighting conditions within its target range of use; where a condition cannot be covered, there must be a reliable alternative carrier or an explicit operating restriction — narrowing the declared scope to exclude everyday backlight, nighttime, or tunnels is not acceptable. Legibility under polarized lenses should be assessed and the conclusion recorded; these guidelines do not require that it necessarily pass.

Presentation requirements: a safety state MUST be expressed with text, symbol, or positional coding at the same time, not relying on color alone. After a long place name, multiple languages, or a unit switch, the object, action, value, and unit MUST NOT be truncated into confusable fragments; when necessary, shorten secondary explanatory text, and shrinking critical text to force a fit is forbidden. Touch-target area, visible boundary, and spacing to adjacent operations must be verified under the actual panel, viewing distance, driving posture, and vibration conditions. Knob or button navigation must have a discernible focus, and the focus must not jump to a different action when the list refreshes. Individual values and their binding to a display position live in veh.visual.*; a single vehicle-wide font size or color scheme cannot substitute for situational verification.

Design applicationtreat legibility as a property of the display position, not a property of the color scheme: a color scheme that holds on the instrument cluster may not hold under the center display's mounting angle. A night scheme is not just dimming the brightness — it is a separate presentation that needs its own verification.

Verification examples

• User side: under each declared lighting condition, have a participant read information from the list and record instances of failed reads and reads requiring multiple glances.
• Implementation side: pull the verification records and the list of conditions covered; check whether re-verification occurs after a revision.

Counterexamplesunder-delivery — white text placed on a light-colored map base becomes unreadable under direct midday sun; over-delivery — to accommodate extreme conditions, the highest-contrast scheme and largest font size are used at all times, so it is glaring at night and the amount of information per screen drops sharply, forcing the user to flip through more pages.

Basis and referencesR10 requires accounting for nighttime brightness and contrast being washed out in sunlight; R01's V.E cites ISO 15008 for text legibility. For the scope of applicability of in-vehicle character legibility see R28; web contrast can serve as an auxiliary check (R25), but cannot substitute for in-vehicle assessment. No citable public test method or pass criterion was found this time for polarized lenses, so this clause only requires assessment with the conclusion recorded.

VH3-5A display failure is a clear state with a fallback locationMUST¶

In one sentence: When the screen goes black, it must be recognizable as the screen going black, and important information must have somewhere else to go.

Applies toany display position or its data source experiencing a black screen, freeze, partial loss, refresh stoppage, or data interruption.

Ruleon a display failure, the system MUST let the driver recognize that this is a failure rather than a normal state — a frozen frame being visually indistinguishable from a normal frame is the most dangerous form this clause is meant to prevent. Driving-critical information (an item on the VH3-1 list) that lands on a failed display position MUST have a predefined fallback location (recorded in veh.surface.fallback), and the fallback MUST be announced. Continuing to show the last known value without any marking when the data source has failed is forbidden; when a value is unavailable, it should be explicitly expressed as unavailable, rather than retaining a number that still looks normal.

Boundary conditionsthis clause does not require every display position to have a fallback location, only items on the VH3-1 list; nor does it require momentary jitter to trigger the failure process — the determination window for a failure is defined by the product with its basis recorded. A listed item MUST NOT satisfy this clause by "being registered as having no fallback": either a valid alternative presentation must be given, or it must point to a restricted use or degraded handling determined through a dedicated analysis — the latter means the original presentation commitment cannot be maintained and must be stated truthfully, rather than writing the gap up as a legitimate configuration.

Design applicationdesign "the data is stale" as an expressible state, not a binary of having a value or not. The design of the fallback path must consider the target display position's information-volume upper bound (see VH3-2); a fallback should not overwhelm the target position as well.

Verification examples

• User side: inject an interruption to the instrument cluster's data source and observe whether the driver notices within a few seconds; inject a freeze on the center display and observe whether it is discernible.
• Implementation side: inject a black screen, a freeze, and a data interruption at each display position, and check whether the failure indication and fallback occur as defined.

Counterexamplesunder-delivery — the instrument cluster's data source disconnects, vehicle speed freezes at its last value, and the driver thinks the display is normal; over-delivery — any momentary dropped frame pops up a full-screen failure notice, turning a display jitter into an interruption (for the grading of interruptions see VH4-1).

VH3-6The same fact does not contradict itself across display positionsMUST¶

In one sentence: The instrument cluster says 80 km of range remain; the center display cannot say 20.

Applies tosituations where the same fact is presented simultaneously across two or more display positions or channels, including voice announcements, screen mirroring, and the same value in a phone app.

Rulewhen the same fact is presented in multiple places, the value and state at each place MUST be consistent. An inconsistency MUST be detected. The primary display position only defines the priority location for presentation, and does not determine which value is true: each class of critical fact MUST separately define its authoritative source, applicable conditions, sampling moment, and staleness criterion (veh.surface.authority). When an inconsistency is detected, first check the source and sampling moment of each instance, and only mark an instance stale when there is evidence that it has expired; when it cannot be adjudicated, present it as "conflicting / not verifiable" and handle it per that information's degradation strategy. Judging another, correct and more recently updated value as stale merely because some value appears at the primary position is forbidden, and indiscriminately turning all instances unavailable while reliable evidence still exists for some of them is also forbidden. Leaving the user to judge for themselves between two values that both claim to be correct is forbidden. The tolerance and determination window for brief inconsistency caused by different refresh rates MUST be explicitly defined (recorded in veh.surface.consistency.tolerance). A critical value announced by voice must be checkable against the others.

Boundary conditionsthis clause does not require all display positions to refresh at the same rate, nor does it require that expressions of different granularity (e.g., "about 80 km" versus "78 km") be judged a contradiction — the permitted range for granularity difference should be stated in the tolerance.

Design applicationcontradictions usually come from each display position pulling its data from a different pipeline separately. Having a single fact be produced by only one source, with each display position only presenting it, is more reliable than reconciling after the fact; where multiple sources genuinely exist, reconciliation and handling must be an explicit step. Two displays agreeing does not prove their common upstream is still valid — a consistency check and a freshness check are two different things.

Verification examples

• User side: observe multiple display positions at once for items such as range, tire pressure, and mode state, and record the occurrence and duration of any inconsistency.
• Implementation side: inject a delay into a single data source and check whether it is detected and handled as defined.

Counterexamplesunder-delivery — the instrument cluster and center display give ranges that differ by several times, and neither states which is the current value; over-delivery — to force consistency, the refresh of every display position is throttled to the slowest channel, so the turn prompt ends up delayed until after the intersection.

3.4 VH4 Interruptions are ranked by consequence¶

Many modules in the car want to speak: the vehicle itself, navigation, communication, media, third-party apps, the driving-automation system. Each of them considers itself important. This principle governs who gets to speak, when, who goes first when several want to speak at once, and whether the user can get back to where they were afterward. It does not govern where this information is displayed (that is VH3), nor how much glancing it costs to respond to it (that is VH1, though this principle's VH4-5 separately constrains the response action).

VH4-1Reminder grading is based on consequence and remaining timeMUST¶

In one sentence: Grading does not rely on a module's own sense of importance; it relies on what happens if it's missed.

Applies toall in-vehicle reminders, alerts, and proactive interruptions, including third-party apps and screen-mirroring sources.

Ruleevery category of reminder MUST be assigned to a predefined level, with grading based on what consequence follows from missing it and how much time remains for the driver to respond (recorded in veh.alert.level). Using the originating module's business importance, the user's subscription or payment status, commercial value, or order of arrival as a grading basis is forbidden. The level determines channel, timing, whether it can be suppressed, whether it can be deferred, and whether it can be overridden. Grading MUST be defined uniformly in one place; modules are forbidden from declaring their own level; a third-party source may apply for a level, but the level is judged by the unified defining party. Every category of proactive reminder must also state who it is for and what action it helps them take; a non-essential reminder with no statable benefit must not proactively appear while driving.

Boundary conditionsthis clause does not specify the number or naming of levels, nor the concrete presentation form for each level. Where an applicable jurisdiction separately mandates a level for a specific alert, the applicable requirement governs and is annotated in the definition.

Design applicationthe number of levels should be commensurate with the number of presentation forms that can actually be distinguished. The grading assessment should share the same consequence assessment as the settling of the VH3-1 list.

Verification examples

• User side: have a participant distinguish reminders of different levels and record whether their urgency can be told apart.
• Implementation side: pull the grading definition and the level assignment of every reminder; check whether any level was self-assigned by its originating module.

Counterexamplesunder-delivery — a third-party app marks its own push notification as the highest level, sharing the same channel as a vehicle safety alert; over-delivery — nine levels are defined, only two are actually used in operation, and the other seven each carry their own timing rule yet are never triggered.

VH4-2Non-essential information is suppressed during high-workload periodsMUST¶

In one sentence: While a person is busy driving, marketing, recommendations, and "you have a new message" can wait.

Applies toperiods of elevated driving workload, including complex intersections, merging, ramps, adverse weather, and low-visibility conditions.

Rulenon-essential information MUST be suppressed during high-workload periods. The product MUST explicitly define the criteria for workload and the scope of suppression (recorded in veh.load.suppress.scope). The criteria may use road context, vehicle dynamics, frequency of driver input, or an existing driver-state monitoring capability. The scope of suppression must cover at least: marketing and recommendation content, social and messaging prompts unrelated to driving, rating and survey requests, and system prompts that can be deferred without consequence. Batch-resending after suppression is lifted is forbidden: suppressed content MUST be re-judged for whether it is still worth happening, based on its own timeliness, and content that has become stale is not sent.

Boundary conditionssafety-related alerts are not within the scope of suppression — the object of suppression is non-essential information, not all information. When a workload-determination capability is not available, an explicit, conservative in-motion suppression rule must still be adopted (for example substituting vehicle dynamics and road class, or suppressing the categories listed in this clause across all driving-related states); this is a conformant outcome, not an exemption. "Handled at the usual timing and concurrency count" does not satisfy this clause — a count upper bound constrains how many items appear at once, not the moment it appears at; a non-essential prompt can just as easily land in exactly those few seconds of a merge.

Design applicationtreat "suppressible" as an explicit attribute of each category of information, settled at its definition, not judged ad hoc at runtime. Suppression and discarding are two different things: after suppression, either re-judge it at a suitable moment based on its own timeliness, or explicitly discard it and state so.

Verification examples

• User side: at complex intersections and ramp stretches, record the number of non-essential prompts that appear; after suppression lifts, record whether a batch resend occurs.
• Implementation side: check whether each category of information is tagged with a suppressible attribute; inject a high-workload state and check whether the scope of suppression matches the definition.

Counterexamplesunder-delivery — an annual driving report pops up while merging into a ramp; over-delivery — the workload criterion is set so broadly that navigation's turn prompt at the intersection is treated as suppressible content and gets suppressed along with everything else.

Basis and referencesR15 requires that a notification be sent only when relevant to the driver's need; R02's 4.3.5.1 requires automatically disabling visual information unrelated to driving and potentially significantly distracting while in motion. The post-interaction residual cost reported in R22 is the reason this clause requires the suppression window and the moment interaction ends be considered separately. No direct source was found this time for "no batch resend after suppression is lifted"; it is derived by working backward from the commitment.

VH4-3Multi-source reminders are arbitrated, not left to contend concurrentlyMUST¶

In one sentence: When three modules want to speak at once, someone has to decide who goes first.

Applies tosituations where reminders from the vehicle system, navigation, communication, media, a third-party app, and the driving-automation system occur simultaneously or close together in time.

Ruleevery reminder MUST go through a single, unified arbitration to decide presentation order, the concurrency cap, and channel allocation; sources are forbidden from directly occupying an output channel. The arbitration rule MUST be defined in advance and stable, with its input being VH4-1's level and timeliness, not order of arrival or the originator's identity. The audio channel is forbidden from playing two semantically different prompts at the same moment; the visual channel's concurrency cap is constrained by VH3-2's information-volume upper bound. Arbitration MUST handle the case where "a higher-level reminder arrives while a lower-level reminder is playing," with whether and how to interrupt defined in advance. Takeover requests, vehicle faults, and collision-related prompts must also enter this same arbitration definition, with time limits and alternative channels recorded item by item.

The same event must be deduplicated by event identifier and by condition change. Before a preempted item resumes, its timeliness must be re-checked; replaying a turn instruction for an intersection already passed is forbidden. Alert deduplication, expiry, and clearance conditions are written into veh.alert.arbitration.rule.

Boundary conditionsthis clause does not specify the concrete arbitration algorithm or the values in a priority table; it does not require arbitration to be centralized within a single software component — what is required is that the rule set be defined centrally and that no source can bypass it.

Design applicationarbitration's output is not just "who goes first" — it also includes "what happens to the other one": deferred, downgraded to another channel, or dropped. All three dispositions must be defined; an arbitration that writes only priority without disposition degrades into dropping under real concurrency.

Verification examples

• User side: construct a scenario where a turn prompt, an incoming call, and a vehicle prompt occur at the same time, and record whether the actual presentation is distinguishable.
• Implementation side: check whether a path exists that bypasses arbitration and plays directly; for a yielded reminder, check its subsequent disposition.

Counterexamplesunder-delivery — the turn prompt, the incoming-call ring, and a low-battery prompt overlap, and none of them can be made out; over-delivery — strict serial queuing, with an urgent alert queued behind a long voice announcement.

VH4-4Vehicle safety alerts are not obscured by the infotainment layerMUST¶

In one sentence: A full-screen app, screen mirroring, or a third-party interface must not cover the vehicle's own alert.

Applies towhile the vehicle is running a third-party app, screen mirroring, video playback, or full-screen content.

Rulethe vehicle's own safety-related alerts are forbidden from being visually obscured by a full-screen app, screen mirroring, a third-party interface, video playback, or a system animation, and are also forbidden from being audibly overridden. The presentation layering and audio priority MUST be enforced at the mechanism level, not dependent on each app voluntarily yielding. Before a third-party runtime environment or screen mirroring connects, the display area it may occupy, the audio channel, and the highest level it may apply for MUST be explicitly bounded and recorded (veh.alert.thirdparty.limit). A third-party source is forbidden from presenting content that is difficult to visually distinguish from the vehicle's own alerts.

Boundary conditionsthis clause constrains obscuring; it does not forbid a third-party app from using full screen, nor does it require every vehicle prompt to forcibly interrupt third-party content — only safety-related alerts are protected by this clause; the rest are handled per VH4-1's level and VH4-3's arbitration.

Design applicationreserve a display area and audio path for safety alerts that third-party content cannot occupy, and make that reservation hold at the mechanism level rather than by convention. The visual language of third-party content (color scheme, icon form) should be distinguishable from a vehicle alert.

Verification examples

• User side: trigger a vehicle alert while screen mirroring is in full-screen navigation, and observe its visibility and audibility.
• Implementation side: check the third-party integration agreement's bounds on display area, audio channel, and level applications; attempt to request over-limit resources from the third-party side.

Counterexamplesunder-delivery — after screen mirroring enters full screen, the vehicle's brake-system fault prompt is buried underneath it; over-delivery — every low-level vehicle prompt forcibly interrupts the mirrored image, so the user turns off all vehicle prompts, losing the safety alerts along with the rest.

VH4-5Responding to a reminder does not require a complex on-screen operationMUST¶

In one sentence: Letting someone know something should not, in passing, require them to make a precise tap.

Applies toall reminders presented to the driver while driving that require or expect a response.

Rulefor a reminder that requires a driver response, the response action MUST be completable without prolonged staring and without precise pointing. Designing "acknowledged" as an operation that must hit a small on-screen target is forbidden. A purely informational reminder is forbidden from requiring any response and MUST be able to dismiss itself; how long it persists does not constitute an operating deadline. When a response has multiple options, the number of options and how they are presented are constrained by VH1-1's glance-occupancy upper bound; when the options exceed that bound, they MUST instead be carried by a non-visual channel or deferred until the vehicle is stationary.

Acknowledging that an alert has been read, silencing the alert tone, and clearing the fault must be kept separate; while a fault condition persists, presenting the vehicle state as normal merely because "acknowledged" was tapped is forbidden. Persistent indication and the conditions for a repeat reminder are recorded in veh.alert.response.path.

Boundary conditionsthis clause does not specify the size of a response control (see the scope statement), and does not forbid providing an on-screen response entry point — what is forbidden is making it the only path.

Design applicationpair a reminder that needs a response with a near-hand path (a steering-wheel button or voice), with the on-screen entry point as a supplement. When multiple options need to be remembered or compared, first reduce the dimensions being compared; whether to defer is decided by occupancy measurement, not substituted by a uniform option count.

Verification examples

• User side: trigger each type of reminder requiring a response while driving, and record the number of glances needed to complete the response.
• Implementation side: list every reminder requiring a response and its response path; check whether any has only a single path through a small on-screen target.

Counterexamplesunder-delivery — a reminder only dismisses after tapping a small X in the corner of the screen; over-delivery — every reminder requires no response and auto-dismisses after a few seconds, including ones that genuinely need the driver to make a choice.

VH4-6After an interruption, the interrupted task can be returned toSHOULD¶

In one sentence: Once the prompt has been read, the thing that was being done is still there.

Applies tohandling of interface state after an interruption ends.

Rulethe obligation to preserve the completed portion of an interrupted task is separately carried by VH1-2 (at MUST strength); this clause does not restate it, nor does it add further strengthening. This clause governs only two things after an interruption ends: first, the user SHOULD be able to return to the interrupted task and its state — it is forbidden to leave the user, after the interruption ends, on an interface related to the interruption's content without providing a return entry point; second, the recovery action itself MUST NOT require glance occupancy beyond VH1-1's upper bound. The recovery method, recovery entry point, and recovery validity period should be defined in advance, with their values following the veh.lockout.resume.ttl already defined in VH1-2, rather than setting up a separate one.

Boundary conditionsthis clause does not require an automatic jump back — an automatic jump back could itself violate VH1-3. What is required is that a return path exist and be low-cost; letting the user decide when to return is the appropriate default.

Design applicationtreat "what was just being done" as a persistently visible, low-salience cue, not an automatic jump. Once the vehicle has come to a stop, the user may already have turned to something else, and an automatic jump back would be a disruption instead.

Verification examples

• User side: trigger an incoming call during a media search, and after the call ends, record how many operations are needed to return to the original task and whether the input was preserved.
• Implementation side: for each type of interruption, check where it lands after ending and whether a return entry point exists.

Counterexamplesunder-delivery — after the call ends, it stays on the call-log page, and the earlier search content is gone; over-delivery — as soon as the interruption ends it automatically jumps back to the original interface, even though the car has already stopped and the user is looking at something else.

3.5 VH5 In-cabin multi-channel use has conditions of standing¶

Voice, audio, and haptics are often treated in the car as the answer to the distraction problem: you don't have to look at the screen, so there's no problem. This principle governs the conditions under which that answer actually holds — a channel must have redundancy, must be in a clear state when unavailable, an acknowledgment must actually be perceptible, cognitive occupancy must be counted, and reference resolution must tighten while driving. Input, confirmation, failure, and recovery must all hold under actual cabin noise, occupants, and channel combinations.

VH5-1Voice is not used as the sole path, nor as an exemption from distractionMUST¶

In one sentence: Adding voice does not make a thing safe, and it does not mean other paths can be removed.

Applies toevery in-vehicle function the product declares can be completed by voice.

Rulea function available while driving is forbidden from having only voice as a path, and is also forbidden from treating "voice is offered" as grounds for that function satisfying VH1-1. Voice interaction occupies auditory, linguistic, and cognitive resources, and its occupancy MUST be measured separately from, and counted alongside, visual occupancy (see VH5-4). The voice path MUST be able to distinguish awaiting wake, listening, processing, taken effect, failed, and canceled; the user must be allowed to abort or switch input, and an already-clarified object or input is not required to be re-stated. At low confidence, clarify the object first rather than guessing at execution; on repeated recognition failure, provide an alternative entry point or end the round, without forcing the user to repeat indefinitely.

Boundary conditionsthis clause does not require every function to have an equally convenient non-voice path — the alternative path may be slower and involve more steps, but it MUST exist and be usable while driving, or fall explicitly within VH1-4's restriction scope with an explanation given. This clause does not apply to a function the product explicitly declares available only while the vehicle is stationary.

Design applicationwhen designing an alternative path for a voice function, the alternative path itself must pass VH1-1's check; placing a deep menu that violates VH1-1 there to serve as "the other path" means neither path actually holds.

Verification examples

• User side: attempt to complete each function with the voice service unavailable, and record which cannot be completed.
• Implementation side: list every function declared to support voice and its non-voice path; check whether any item is reachable only by voice.

Counterexamplesunder-delivery — changing the destination while driving can only be done by speaking, and there is no other way if it can't be said clearly; over-delivery — to satisfy "not sole," every voice capability is given an equally deep on-screen menu, and that menu itself violates VH1-1.

Basis and referencesR08's §2.1.1.4 requires that a function permitted to pass judgment via voice have a separate alternative control; R01's Phase 1 explicitly does not cover voice, so its visual-manual acceptance conclusions cannot be used to vouch for the voice path. R21 and R22 report that the cognitive-load difference between hands-free and handheld calling is small, and that the mean load of in-vehicle voice systems sits in the upper-middle range of the scale — this is the core basis for this clause's "voice is not used as an exemption from distraction."

VH5-2Channel unavailability is a clear state with a fallbackMUST¶

In one sentence: When the microphone or Bluetooth is gone, it must be recognizable, and there must be another way to do it.

Applies tounavailability or degradation of the microphone, speaker, haptic actuator, network connection, and recognition service.

Rulewhen a channel is unavailable or degraded, it MUST be an explicit state to the user, and it is forbidden to present as "no response." Every channel MUST have a predefined fallback path (recorded in veh.channel.fallback), and the fallback MUST be announced with a statement of what changed. Silently dropping an already-triggered driving-related reminder when a channel is unavailable is forbidden — an item on the VH3-1 list that lands on that channel MUST instead be carried by another channel. The announcement itself is subject to VH4: it is an interruption and must be handled per its level, and repeatedly announcing the same instance of unavailability is forbidden.

Volume and channel allocation on the audio channel MUST NOT improperly mask a necessary alert: the objects of assessment include mutual masking among in-cabin reminders, as well as audible information from outside the vehicle (sirens, horns, construction and reversing signals) being jointly masked by cabin noise, media playback, and the product's own output. The criterion for the masking assessment is whether the target sound can be identified, not its order on a mixing priority table; the assessment conditions must cover the cabin-noise range and common media volumes the product declares support for.

Boundary conditionsthis clause does not require every channel to have a fallback — a non-critical function may be defined as having no fallback, provided the affected function and reminder are named. A channel carrying an item on the VH3-1 list or a function on the VH2-1 list is not eligible for "no fallback": it must be given a valid alternative carrier, or point to a restricted-use disposition determined through a dedicated analysis. Whether momentary jitter constitutes unavailability is determined by a window defined by the product.

Design applicationmake channel state an explicit, system-queryable status that each function checks before initiating, rather than dispatching and waiting for a timeout. The user-facing wording should state the consequence ("voice can't be used to change the destination right now"), not just report component status.

Verification examples

• User side: disconnect the network and microphone, attempt to trigger a voice function, and record whether the user can tell within a few seconds what happened and what to do.
• Implementation side: inject unavailability into each channel and check whether the fallback occurs as defined and whether the affected reminders are rerouted.

Counterexamplesunder-delivery — the voice assistant does not respond at all due to a network outage, and the user presses the wake key three times in a row; over-delivery — every connection jitter announces "service unavailable," announced a dozen times over one drive (for the total-volume constraint see VH4-3).

VH5-3Non-visual acknowledgment carries the confirmation dutySHOULD¶

In one sentence: Whether an operation took effect must be knowable without looking at the screen.

Applies tooperations the driver initiates while driving, especially functions on the VH2-1 list and safety-related operations.

Rulefor an operation while driving, "whether it took effect" SHOULD be knowable without looking at the screen — an audio cue, haptic feedback, or an actual, audible and felt state change (the sound of a fan, wiper motion) all qualify. Using a visual change that exists only on screen as the sole acknowledgment for a function on the VH2-1 list, or for a safety-related operation, is forbidden. The acknowledgment MUST express the actual result, not "input was received": giving an acknowledgment indicating the action has taken effect before it has actually taken effect is forbidden. A haptic signal must be perceptible and distinguishable against the background of road vibration; continuous adjustment must not saturate attention with dense acknowledgments.

Accepted, in progress, taken effect, failed, and result unknown must be distinguishable, recorded in veh.channel.receipt.mode. When a command has been sent but its acknowledgment is lost, success must not be presumed from an animation completing or from a timeout; query the actual state first, then decide whether it is safe to retry. When a repeated key press, voice, and touch occur concurrently, the system must merge the same intent or adjudicate by a defined order, without re-initiating payment, communication, or mutually canceling toggle actions. Acceptance feedback and taken-effect acknowledgment each define their own time limit and measurement start/end points, not mixed together.

Boundary conditionsthis clause does not require an independent, human-perceptible acknowledgment for every operation — a perceptible change the function itself produces is a conformant acknowledgment, and is usually better than an added alert tone. A continuous-adjustment operation is not required to have an acknowledgment for every single step.

Design applicationfirst check whether the function already has a natural non-visual acknowledgment; only add one if it doesn't. When adding one, use existing system semantics rather than inventing new ones.

Verification examples

• User side: with the screen covered, trigger each item on the list and record whether the participant can judge whether the operation took effect.
• Implementation side: list the acknowledgment form for each item on the list; check whether any item has only an on-screen visual change, and whether any acknowledgment precedes the actual effect.

Counterexamplesunder-delivery — pressing defrost only changes an icon's color on screen, with no change felt by hand or heard by ear; over-delivery — every minor volume adjustment gets a vibration plus a tone, and continuous adjustment turns into a string of noise.

VH5-4The cognitive occupancy of hands-free interaction is counted tooMUST¶

In one sentence: Hands haven't moved, eyes haven't left, but the mind is still busy — that is occupancy too.

Applies tovoice, audio, and other interaction paths that do not occupy the hands or gaze.

Rulethe resource occupancy of hands-free and eyes-free interaction MUST be independently assessed and counted into that function's total occupancy; directly judging "hands stayed on the wheel, eyes stayed on the road" as acceptable occupancy is forbidden. The product MUST define, for these paths, a measurement method for occupancy, its scope of applicability, and an upper bound (the method recorded in veh.load.cognitive.method, the acceptance condition recorded in veh.load.cognitive.max), and state the method's limitations. Hands-free does not mean attention-free — this is this clause's entire reason for existing. The measurement result MUST be used together with the visual-path measurement result to judge whether the function meets the conditions for being available while driving (see VH1-1, VH1-4).

Boundary conditionsthis clause does not specify a measurement method for cognitive load, nor does it adopt any particular measurement paradigm as prescribed; what is required is that a method be chosen, recorded, and used consistently for comparisons within the same product. This clause does not require cross-product comparability. The conclusions of related public research are each bound to their own task and participant conditions, and must be stated together when cited (see reference.md).

Design applicationthe means of reducing cognitive occupancy differ from those for reducing visual occupancy: shorten each conversational turn, lead with the conclusion, reduce the number of options that must be compared mentally, avoid requiring the user to remember the previous step's content. "Showing less" on screen does not automatically equal "less burden" in voice.

Verification examples

• User side: using a chosen method, compare the occupancy of the same function's voice path against its on-screen path, and record the direction of the difference between the two.
• Implementation side: check whether any function skips the occupancy assessment merely because "it's voice."

Counterexamplesunder-delivery — a voice interaction requiring the driver to mentally compare four options is exempted from assessment because the screen isn't needed; over-delivery — because cognitive occupancy is hard to measure, voice is restricted to executing only a single fixed command, and the user switches to their phone's voice assistant instead.

Basis and referencesR21's scale shows hands-free and handheld calling score similarly, pointing to hands-free not eliminating cognitive load; R22 reports mean load and its range across 257 participants and 10 production systems, and reports that after five days of practice a difficult interaction remains difficult, with an observable residual after the interaction ends. These two sources provide direction and the existence of an effect, not a directly adoptable pass line, so this clause requires that the method, baseline, scope of applicability, and acceptance condition be recorded and used consistently (see also Appendix B.4, item 1).

VH5-5Reference resolution and fusion tighten while drivingSHOULD¶

In one sentence: "Set this as the destination" must resolve to something precise while driving; if it can't be resolved precisely, don't guess.

Applies tooperations while driving that involve referring expressions ("this," "there," "that place from earlier") or cross-channel binding.

Rulereference binding while driving SHOULD be stricter than while parked: when resolution does not succeed, guessing at execution is forbidden, and it must fall back to explicit selection or a clear statement that it could not be resolved. When a difficult-to-undo consequence is involved, the user must be made to confirm the specific object and action before execution; the confirmation itself satisfies VH4-5. The fusion window SHOULD be no longer than the window used while parked; if a different value is genuinely needed, the waiting cost, the consequence of mis-binding, and the driving-context verification result MUST be recorded. Lengthening the window merely to raise the fusion success rate is forbidden, and combining input from different occupants or an expired object into a single command is also forbidden. The fallback path is likewise subject to visual and cognitive occupancy verification, and is deferred until parked when it exceeds the acceptance condition. The window, object validity period, and timeout disposition are recorded in veh.channel.fusion.window.

Boundary conditionsthis clause does not forbid using referring expressions while driving — what is forbidden is guessing when resolution does not succeed. This clause does not require improving recognition accuracy; what it requires is tightening behavior on the failure side.

Design applicationdesign "resolution did not succeed" as a normal path, not an exceptional branch — its rate of occurrence is naturally higher while driving. The fallback path's cost must be low enough that the user is willing to take it, or the user will keep retrying the original path.

Verification examples

• User side: issue a referring command in a scenario where the referent is ambiguous, and record whether the system executes against some unconfirmed object.
• Implementation side: check whether the binding threshold and fusion window differ between driving and stationary; check whether any silent execution occurs under low confidence.

Counterexamplesunder-delivery — "navigate to here" picks the map's center point when the reference is unclear, taking the user somewhere else; over-delivery — no referring expression is accepted at all while driving, and the user must speak the full address every time, so the length of a single conversational turn ends up exceeding its own limit.

3.6 VH6 The cabin is shared by multiple people¶

A phone usually has one owner; a car does not. Over its lifecycle it will be driven by multiple people, sat in by multiple people, and will be rented out, shared, and sold. This principle governs who is driving, who is operating, whose name a preference is recorded under, what a passenger can change, and what is left in the car after a person gets out. Treating the cabin as a single-user device is a persistent category of error in this domain.

VH6-1Who is driving and who is operating are determined separatelyMUST¶

In one sentence: These are two different things, and they're determined on different grounds.

Applies toevery mechanism involving user identity or role, including personalization, exemptions, permissions, and data ownership.

Rule"who is carrying the driving task" and "who is operating this interface" MUST be determined separately and recorded separately; inferring one from the other is forbidden. The former determines the strength at which these guidelines' obligations apply (see the state table in the opening section), and the latter determines whether an exemption holds (see VH1-5) and whose name personalization is written under (see VH6-3). The determination basis, confidence, and failure disposition for both MUST be explicitly defined (recorded in veh.occupant.role.*); on determination failure, handle it under the more conservative assumption that "the driver is operating." A person carrying a monitoring or takeover responsibility is still treated as the driver, and does not automatically gain passenger permissions because of an account, a seat label, or a mode's name.

Boundary conditionsthis clause does not require equipping occupant-recognition or seat-sensing capability; when it is not present, handle it per the conservative default, and record the determination capability's actual scope in the Token. This clause does not require the role-determination result to be shown to the user.

Design applicationtreat role as two independent fields, not a single "current user." The logged-in account, the key that was inserted, the person sitting in the driver's seat, and the person touching the screen may be four different answers.

Verification examples

• User side: have someone other than the owner drive the vehicle, and observe the behavior of recommendations, preferences, and data ownership.
• Implementation side: check for any code path that treats account identity directly as the driver; check the default branch on determination failure.

Counterexamplesunder-delivery — whoever is logged in is assumed to be driving, and after the owner lends the car out, every trip and preference is recorded under the owner's name; over-delivery — every time someone gets in, all occupants are required to individually confirm seat and identity before any function can be used.

VH6-2Passenger operation does not change the driver seat's critical presentationMUST¶

In one sentence: The front passenger is picking a song — that must not flip the driver's navigation to a different page.

Applies toall operations on the front-passenger display, rear-seat display, shared center display, and passenger-device connections.

Rulepassenger operation is forbidden from preempting the driver seat's VH3-1 critical information or an output channel the driver is currently using, and is forbidden from relocating a VH2-1 critical entry point or operating an action marked driver-exclusive. A non-motion critical action explicitly allowed for passenger collaboration MUST be executed through a verified entry point and permission; a rear-seat or child interface is additionally bounded by VH6-6's scope. The scope a passenger can affect MUST be explicitly defined (veh.occupant.scope.passenger). An ordinary high-frequency function does not automatically become driver-exclusive merely by being in veh.control.frequent.set. Shared state such as climate, windows, and media volume may be adjusted according to permission, but a change affecting the driver MUST be made knowable to the driver, and its presentation is still subject to VH4's grading and arbitration.

Boundary conditionsthis clause does not forbid a passenger from participating in collaborative acts such as selecting a navigation destination — what is required is that this kind of change reach the driver in the form of a proposal rather than taking effect directly, and the proposal itself is handled per VH4. When sharing the same screen, this clause requires that the driver seat's presentation not be preempted, not that the hardware be split into separate screens.

Design applicationsplit the results of passenger-side operations into three categories: those affecting only the passenger side (take effect immediately), those affecting shared vehicle state (take effect and notify), and those affecting the driver's task (act as a proposal). Write down the boundary between the three categories.

Verification examples

• User side: have the passenger perform a sequence of operations on the front-passenger side while recording changes to the driver-seat display and audio channel at the same time.
• Implementation side: list every action triggerable from the passenger side and its scope of effect; check for any path that directly rewrites the driver seat's presentation.

Counterexamplesunder-delivery — the front passenger searches media on the center display, and the driver's navigation gets switched away; over-delivery — the front passenger can do nothing but watch, so the driver ends up operating it for them while driving, raising the risk instead.

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

In one sentence: Learned preferences are recorded against the person, not the car, and they can be reset to zero.

Applies topreferences, habits, recommendations, frequent destinations, and adaptive behavior the system has learned.

Rulepersonalization MUST be bound to an identifiable subject — an account, a key, a user profile, or an explicitly labeled "unidentified user"; accumulating personalization as an attribute of the vehicle itself is forbidden. The bound subject, the binding basis, and the disposition on identification failure MUST be explicitly defined (veh.occupant.profile.binding). Every category of personalization MUST be resettable, and the reset MUST reach configuration derived from it. When the subject is uncertain, handle it as an "unidentified user"; folding it into the most recently identified subject is forbidden. An anonymous preference is bound only to the current session of use; accumulating it across sessions of use via a shared anonymous profile is forbidden; seat or mirror memory recall MUST NOT change driving posture and field of view without notice while driving.

Boundary conditionsthis clause does not require mandatory login, nor does it require biometric-recognition capability. A memory item tied to body position, such as a seat or mirror, may be bound to a position profile rather than an account, provided that profile is itself resettable and is not used as a behavioral profile.

Design applicationstore "what this car has learned" separately from "this person's preferences." The former should contain only items related to the vehicle itself (maintenance interval, tire-pressure baseline); the latter follows the subject and can be cleared as a whole.

Verification examples

• User side: after a second user drives for a while, check whether the first user's recommendations have been contaminated; after performing a reset, check whether derived configuration disappears along with it.
• Implementation side: list every personalization item and its bound subject; check for any accumulating item with no subject binding.

Counterexamplesunder-delivery — the car has learned "at this time you usually go to a certain place," and keeps recommending it when a different person drives; over-delivery — login is required every time someone gets in, and without logging in even seat and climate memory are withheld.

VH6-4Shared and rental vehicles default to being more conservativeMUST¶

In one sentence: Not knowing who the last person was, the default should not remember anyone.

Applies tovehicles used for sharing, rental, ride-hailing, test drives, showroom display, and corporate fleets.

Rulethe default configuration for this class of vehicle MUST be more conservative than for a private vehicle: by default, no persistent personal profile is established, contacts and call history are not saved by default, destination history is not saved by default, account credentials are not saved by default, and recommendations requiring long-term personal data are not enabled by default. The operating form MUST be an explicit product configuration item (recorded in veh.occupant.tenancy.mode); substituting "the user can turn it off themselves" for a conservative default is forbidden. Personalization the user proactively turns on MUST be bound to the session of use, and disposed of per VH6-5 when that session ends.

Boundary conditionsthis clause does not forbid a shared vehicle from offering personalization — what is required is that it default to off, be turned on by the user with informed knowledge, and be bound to the session of use. This clause does not determine the division of data responsibility between the operator and the manufacturer.

Design applicationtreat the session of use as a first-class object: clear at the start, clear and give an acknowledgment at the end. Settings needed for this drive, such as seat position, may be retained within the session of use — they are not the same category as a behavioral profile.

Verification examples

• User side: use the vehicle for the first time in rental form and check for any trace left by the previous user; after connecting a phone, check the default sync scope.
• Implementation side: check whether veh.occupant.tenancy.mode actually changes the set of defaults, rather than being just a flag.

Counterexamplesunder-delivery — a rented car syncs the phone's contacts into the head unit by default and retains them long-term; over-delivery — a shared vehicle does not allow even seat and mirror position to be remembered within the current session of use, requiring readjustment every time someone gets in.

VH6-5Personal data can be cleared after leaving the vehicle, and the clearing is verifiableMUST¶

In one sentence: After the car is returned, the contacts, places visited, and accounts must actually be deletable.

Applies toall cases of a user ending their use, the vehicle being returned, an account being closed, and the vehicle changing hands.

Ruleafter a user ends their use, their personal data generated in the vehicle MUST be clearable, and the clearing MUST reach its derivatives — device pairing records, contacts and call history, messages, destination and trip history, accounts and credentials, voice samples and wake records, and recommendations and personalization configuration generated from this data. The clearing MUST have a verifiable completion acknowledgment: stating what was cleared, what remains, and when it completed. Delayed clearing caused by being offline or a component not being powered MUST be shown as pending, not as completed. The product MUST provide a clearing path completable within the vehicle; providing only a path that requires another device or contacting customer support to complete is forbidden.

The scope of clearing, trigger conditions, each storage location, and failure disposition are recorded in veh.occupant.data.lifecycle. When local data has been cleared but the cloud-side revocation has not yet completed, display it item by item as "cleared on this vehicle / pending remotely"; the next user must not be able to access data pending clearance. While a deletion request is pending, background sync must be prevented from writing the data back; unpairing and revoking access credentials are each separately verified.

Boundary conditionsthis clause does not determine conformance with each jurisdiction's data regulations (see the scope statement). An item that cannot be deleted due to a statutory retention obligation or a safety-incident investigation MUST be named and stated, and must not be described vaguely as "some data retained." This clause does not require clearing the vehicle's own operating and fault records.

Design applicationdesign clearing as a trackable disposition rather than a single click: list the scope, execute, give an acknowledgment, and for any incomplete item state the reason and expected completion condition. The clearing entry point should appear at moments the user actually passes through, such as returning or transferring the vehicle, rather than being buried deep in settings.

Verification examples

• User side: after performing a clear, re-pair a phone and open navigation and voice history, and check whether prior content is still visible.
• Implementation side: for each category of data, check whether clearing reaches its derived personalization configuration; perform a clear after disconnecting the network and check whether the state shows as pending.

Counterexamplesunder-delivery — "delete user" at car return only clears the home-screen avatar, while Bluetooth pairing and navigation history remain; over-delivery — clearing is made an irreversible single step with no confirmation, and a user's mis-tap loses the navigation they were actively using for this trip (for mis-touch constraints see VH2-4).

VH6-6The operable range for rear-seat and child occupants is explicitSHOULD¶

In one sentence: What the back seat can and cannot change must be settled in advance.

Applies torear-seat displays and controls, and in-vehicle interfaces potentially used by children.

Rulethe operable range at these positions SHOULD be explicitly defined (recorded in veh.occupant.scope.rear, veh.occupant.scope.minor). A related operation is forbidden from changing the vehicle's motion-related state or the state of a function on the VH2-1 list, and is forbidden from initiating payment, outgoing communication, or changing account settings without authorization from the driver or a guardian. The default configuration for child use SHOULD be independently defined, rather than inherited from the adult configuration and tightened item by item — inherited tightening defaults to open on any newly added function. Audio output from rear-seat content must not occupy a channel the driver is currently using (see VH6-2).

Boundary conditionsthis clause does not require the system to have the capability to recognize an occupant's age; when it is not present, handle it by position and explicit configuration (such as a child mode), rather than by inference. This clause does not determine regulatory requirements for the protection of minors (see the scope statement).

Design applicationdefine the rear seat as an independent permission domain, not a subset of driver-seat functions. When a new function is integrated, it defaults to not entering the rear-seat domain or the child domain, joining only through an explicit decision.

Verification examples

• User side: from the rear seat, attempt to change navigation, driver-assistance settings, and account settings, and record the actual reachable range.
• Implementation side: check whether the rear-seat and child configurations are independently defined; after adding a new function, check its default availability in both domains.

Counterexamplesunder-delivery — the rear-seat display can directly change the navigation destination and turn on driver-assistance functions; over-delivery — the rear seat can do nothing but play already-selected content, with even volume and brightness requiring the driver to handle them.

4. Terminology and definitions¶

This chapter defines the design objects used in these guidelines. A task is a stretch of interaction with a verifiable result; an interruption only pauses progress, and does not automatically undo a result that has already occurred.

5. Operating states and component contracts¶

This chapter turns the rules into design objects that can be handed off. State names are for design and engineering communication; they are not required to be shown as these enumerations in the driving interface.

5.1 Do not collapse different states into a single "available"¶

Evidence for the vehicle context must include at least the source, the sampling moment, and validity; concrete speed and gear criteria are defined in the vehicle-model preset. AOSP's Parked, Idling, and Moving states illustrate the need to distinguish temporarily stationary from parked, but the platform's examples do not substitute for a vehicle model's own criteria; the application should consume the effective restriction set issued by the platform (R12, R14).

5.2 Core transitions¶

5.3 The three-question contract for the six components¶

Every component handoff answers: what facts are needed, what does the user's action change, and what proves it took effect.

State copy states the consequence and the next step, for example "Voice is temporarily unavailable; use the steering-wheel button instead," not just an error code. The driving interface keeps the minimum information; detailed technical diagnostics are viewable once parked.

6. Minimum delivery and acceptance¶

6.1 One design record¶

The following template is filled in per individual task. An existing vehicle-model preset can be referenced directly, stating only the difference; do not turn every Token into a driver-facing setting.

Task and outcome: who, under what vehicle context, achieves what actual result?
Scope and exclusions: which functions/actions, display positions, occupants, languages, and usage conditions?
Path selection: why are fixed controls / touchscreen / voice / post-park handling suitable, and what is the cost of the alternatives?
Facts and permissions: where does the result come from, who can initiate it, who can change it, what happens when unknown?
Primary path and exceptions: start-off, interruption, mis-touch, disconnection, lost acknowledgment, concurrent passenger use, end of session.
Configuration: which vehicle-model presets are adopted, which fields are adjusted, who decided, what is the basis, the effective conditions, and the dependencies?
Verification: rule number → parameter → bench evidence → user task result; unverified items and the permitted scope of use.

6.2 Three kinds of evidence delivered separately¶

Each result records the task's start and end points, vehicle and hardware conditions, preset identifier, tested population, method, baseline, determination rule, actual result, and evidence location. Glance, cognitive load, and driving performance are reported separately, not summed into a single "safety score" without basis. After a visual layout, voice announcement, operating path, or hardware condition changes, re-check the affected evidence.

6.3 Acceptance conclusion and veto items¶

• Pass: within a clear scope of task, population, hardware, and environment, the applicable requirements have evidence.
• Restricted: only a parked-only or already-verified scope of functions is permitted, with the restriction enforced by mechanism; a critical control that has not passed cannot be opened up through a "research trial."
• Fail: a baseline failure exists, or a critical criterion, capability, or evidence is missing.

If a critical control is locked out by the interface, a stale value is treated as the current value, an alert is obscured, an unknown result is misreported as success, or personal data is exposed to the next user, any one of these blocks acceptance for the affected scope, and it cannot be offset by an average completion rate. Appendix A is used for item-by-item injection; over-delivery must also be paired-tested: excessive lockout, repeated confirmation, excessive acknowledgment, resume-prompt harassment, and overly broad alerts.

Appendix A: Fault-injection verification checklist and classification test¶

This checklist is used to verify whether a clause actually takes effect; it adds no new obligation. Inject item by item and record the system's actual behavior; recording "not applicable" is a conformant result, recording "not tested" is not (for the distinction among the four states see Appendix C.2). Injections in this checklist should be performed under vehicle states and lighting conditions the product declares support for, with the injection conditions and result recorded together.

Hazardous injections should be performed first in a simulator, on a bench, or at a closed test track. Injections such as black screen, freeze, head-up display misalignment, mis-touch inducement, and alert masking are forbidden from being performed freely on open roads; when evidence genuinely must be obtained under actual road conditions, there must be a dedicated safety plan, explicit termination conditions, and an abort means available at all times, with the environment and termination conditions recorded for each instance. The tested population should cover the target users' differences in age, language, and familiarity — do not extrapolate from the results of a few young, skilled users.

A.1 Visual occupancy and task interruption

A.2 Reachability of critical functions

A.3 Information placement and display failure

A.4 Interruption and arbitration

A.5 Channels and multimodality

A.6 Multiple occupants and data residue

A.7 Classification test

Used to verify whether Chapter 1's split holds: take 10 to 15 concrete requirements (which may come from these guidelines' clauses, or from actual review comments), and have at least three reviewers who did not participate in writing them independently judge which principle each belongs to. When disagreement over assignment concentrates between some two principles, it means those two principles' normative objects have not been separated — at that point the split of the principles should be adjusted, rather than adding an intermediate layer or supplementary mapping notes. The two places known to need priority testing are stated explicitly in Chapter 1: VH1 and VH2 (occupancy versus reachability), VH3 and VH4 (placement versus timing). The number of reviewers and the disagreement criterion in this appendix are an internal check method these guidelines suggest, not a literature-verified standard.

Appendix B: Boundaries of evidence and source types¶

B.1 Criteria for normative terms

The sole basis for marking something "MUST" is: without it, some commitment made to the driver or occupants would fail under a foreseeable situation. The three categories of evidence below provide different kinds of support; they are not three independent mandatory sources. A single implementation reference or a single failure record alone is not enough to decide on marking "MUST" —

The five rules marked "SHOULD" (VH1-6, VH4-6, VH5-3, VH5-5, VH6-6) are all trade-off questions, not baseline questions: a deviation may have a legitimate reason, but it must be recorded and accept the same verification. Among them, VH5-3 does not specify the concrete form of an acknowledgment, and VH6-6 does not require age-recognition capability. Each of these five contains forbidden-level clauses (see 2.2), and a clause's strength is not lowered by the rule heading being "SHOULD."

B.2 What these guidelines do not do

They do not give numeric thresholds for glance duration or task duration, do not give control size, spacing, or operating force, do not give values for display brightness or contrast, do not give a measurement paradigm for cognitive load, do not give the form or number of physical controls, and do not give the number or naming of alert levels. These are decisions for the product, regulations, and dedicated assessments; these guidelines only specify that such decisions must be made, must have a basis and a measurement method, must be re-checkable, and which values and practices are not permitted.

Nor do these guidelines make the following determinations, and adopting these guidelines cannot replace them: determinations of vehicle functional safety and safety of the intended functionality, regulatory conformance certification in each jurisdiction, conformance of the instrument cluster's statutory markings and lighting, ergonomic and field-of-view verification of the cockpit's physical layout, the scoring results of a third-party scoring protocol, dedicated accessibility and age-friendly requirements, and legal determinations of privacy and data compliance.

B.3 Conditions for using numeric values

Public guidelines in this domain do have time-based criteria. Each is bound to a specific test method, task category, applicable population, and voluntariness statement: which class of task it applies to, which method was used to measure it, who it applies to, and whether it is mandatory or voluntary all differ. These guidelines therefore adopt a consistent approach — the main text only requires that the upper bound be explicitly defined, have a measurement method, have a cited basis, and be re-checkable; the concrete value is carried by the product in veh.glance.* and veh.load.*, separately constrained by the applicable regulations, the chosen evaluation method, and the product's own verification. When citing a value from a guideline, the conditions under which that value applies in the original text, and its source number, must be stated together; where the original text cannot be obtained, its value is not cited.

B.4 The three places where these guidelines' evidence is thinnest

Listed explicitly, not concealed behind clause language:

1. VH5-4 has a method standard, but no cross-product acceptance threshold. That hands-free interaction still has occupancy is supported by public research, but "how much occupancy counts as acceptable" has no cross-product recognized criterion, and cannot be directly derived from a method standard into a universal pass line. ISO 17488's DRT can be used to assess a secondary task's cognitive load effect on attention (R29), but it does not directly predict accident risk; the product must still choose a baseline, tested population, statistical method, and acceptance condition — filling in just the method's name is not enough.
2. VH2-1's list boundary depends on judgment. The answer to "which functions are safety-related" is not entirely consistent across different jurisdictions, different scoring protocols, and different vehicle models; what these guidelines give is a must-check entry table and a requirement that "every entry must be given a conclusion with its basis recorded," not a complete list. A product may expand the entries; skipping the check on a must-check entry is forbidden — when this vehicle is not equipped with it, record it as not applicable and state the basis; this is a different thing from "deleting the entry from the list."
3. VH1-5's passenger determination lacks public effectiveness evidence. For "what combination of evidence is sufficient to determine the operator is a passenger," this search found no directly adoptable public criterion or misjudgment-rate data. These guidelines therefore only specify that the default direction must be conservative and the basis must be statable, without specifying which sensing means to adopt, and without claiming that any particular combination has been verified effective.

B.5 Sources

For the complete source cross-reference, verification status, and search record, see reference.md. A clause in these guidelines does not hold merely because some product has done it this way; a product's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way." Likewise, the existence of a value in some guideline only proves that guideline made that specification under its own applicable conditions, not that the value applies to every object these guidelines apply to.

Appendix C: Determining the scope of applicability¶

This appendix is an application reference for the opening state table, used to determine the applicable strength of each clause in these guidelines on a specific project; it adds no new obligation.

C.1 Five questions to answer first

The two lists (veh.control.critical.set and veh.surface.critical.set) are the two most important pieces of product input in these guidelines: if they are set too narrow, most of these guidelines' protections fail along with them; if set too broad, VH2's and VH3's requirements spread to functions that don't need them, diluting the reachability and discernibility of the truly critical items. The basis for settling the lists MUST be recorded, and re-checked whenever functions are added or removed.

C.2 What to do when a capability is not present

The capabilities mentioned in various places in these guidelines (driver-state monitoring, occupant recognition, head-up display, haptic actuator, scene registration) are not required by these guidelines to be equipped. When recording, distinguish four states, none substituting for another:

not_applicable and disabled are acceptable when their conditions hold; unconfigured cannot pass acceptance through configuration. unknown is a legitimate operating state — correctly executing its conservative branch can pass verification, but an unknown fact must not be recorded as known. The dividing line for judgment is "does this clause's trigger condition hold," not "do we have this component": without a head-up display, registration tolerance can be recorded as not applicable; without occupant recognition, driver-seat protection cannot be recorded as not applicable — the latter's trigger condition (a driver-seat interface exists) still holds, and the handling is to execute VH1-5's "treated as the driver when evidence is insufficient." When a capability is not present but the clause still applies, record that capability's actual scope in the Token, and record "executed per conservative default" on the affected clause. Using a "not applicable" record to conceal a function that should have been implemented but was not is forbidden.

---

Implementation acceptance scenarios¶

The scenarios below turn existing clauses into re-checkable acceptance input, without setting up an additional generic performance threshold. Select by the product's applicable capabilities, supplementing with real devices, users, input sequences, and evidence; record the reason when not applicable, and an item not executed must not be recorded as passed.

Each scenario separately checks the configuration's effective values, the execution record, and a user-comprehensible result. Preserve the version, target, event timing, scope of failure, and recovery result; an unknown external result is not filled in as either success or failure.