Front-passenger actions should not inherit driving lockouts
Aliases: passenger display · co-driver input · passenger exemption
What it is
The front passenger is not the driver. Once the system treats the action as the passenger’s—an independent passenger display, or the stack explicitly handed over—that action should not inherit the driver’s in-motion limits: keyboards can open, lists can be browsed, long content can be read. Limits exist to protect the driver’s eyes and hands, not to make the whole cabin bored once speed rises. When identity is not yet split, collateral lives in lockout logic. When identity is split and the passenger keyboard still greys out, that is the failure named here.
Why it happens
The passenger’s visual loop does not hold the lane. Long glances, both hands off, cognitive load have a different cost structure; copying the driving lockout has no matching mechanism. Passengers are often there to take work: type a destination, answer a message, run the music. Lock those in the passenger’s hands and the task returns to the driver, or flees to the passenger’s own phone—a screen the car does not govern, which may be held up in the driver’s sight line. An independent passenger display exists to be a surface free of driving constraints. If it is only a mirror of the stack with a speed lock on top, it has not divided the work.
Studying it
Compare three conditions: passenger types on an independent display, passenger types on an unlocked stack, driver types. Measure the driver’s glances and hands-off, and who actually finishes the task. Ask passengers what they do when it locks.
Independent variables: input surface (passenger display / stack / phone), driving lockout applied or not, task type (place search, media, long reading). Dependent variables: driver eyes-off and hands-off, who completes the task, passenger pick-ups of a phone.
Lab passengers cooperate. Real ones sleep, refuse, or run brightness that hits the driver. High completion does not mean the driver was not pulled back in—watch whether the driver takes over mid-task.
Where it stops holding
A passenger action that immediately changes driving state (stability off, automation level, killing the cluster) is not an exemption. It is driving the car, and still needs the driver’s confirm. A child in the front seat who can reach the glass turns exemption into unsupervised high privilege. Light from a passenger display leaking onto the windscreen, or night-time glare, is interference with the driver—a leak problem, not a keyboard-lock problem. With no passenger, exemption does not apply.
Applying it
- Once identity is the passenger, open input tasks by default: keyboard, search, and media browsing on the passenger display or a passenger mode of the stack, without the driver’s grey buttons.
- Actions that change driving state still need the driver’s confirm, placed where the driver can reach and the passenger cannot finish alone.
- Verify by asking the passenger, in motion, to search a place and answer a message without help. If the driver has to take over, or the passenger pulls a phone, exemption did not hold. The driver’s eye tracking should not stretch for this task.