In environments where multiple switch-aware applications are running simultaneously (e.g., a background AAC proxy app controlling a foreground web browser), the OS-SD MUST arbitrate input routing to prevent collisions. Apps MUST NOT self-declare priority; instead, they MUST declare their functional intent via the requested_mode field in the SwitchControlManifest.
To support both standard foreground applications and background "Computer Control" paradigms, the OS-SD MUST support the following three subscription tiers:
- exclusive_foreground: The Client App receives switch events ONLY when it holds active OS window focus. If focus is lost, the OS-SD pauses the event stream to this app until focus returns.
- primary_controller (Focus-Agnostic): The Client App receives exclusive global access to the switches, regardless of whether it is in the foreground or background (e.g., Grid 3 or VoiceGarden driving the OS). This tier supersedes foreground applications.
- passive_observer: The Client App receives a read-only copy of switch events globally, regardless of focus. The app CANNOT consume, block, or alter the event routing. Multiple apps MAY hold this status simultaneously.
To prevent malicious or accidental lockouts—especially regarding the powerful primary_controller tier—the OS-SD MUST enforce a strict user-arbitration flow when competing access requests occur. If App A currently holds a primary_controller session, and App B requests either primary_controller or exclusive_foreground status:
- Pause: The OS-SD MUST temporarily pause routing events to App A.
- System UI Overlay: The OS-SD MUST transition to STATE_OS_ROUTING and display a modal, high-contrast System UI Overlay (e.g., "App B is requesting switch control. Transfer control from App A?").
- User Resolution: The user utilizes standard OS-level scanning to select "Transfer" or "Deny".
- Resolution:  If Transfer: App A receives a SESSION_REVOKED payload, and App B receives ACCEPTED.  If Deny: App B receives a REJECTED (USER_DENIED) payload, and App A resumes receiving events.
- Timeout Failsafe: If the user cannot or does not respond to the System UI within a defined timeout (e.g., 15 seconds), the OS-SD MUST default to "Deny" to prevent the user from being stranded in the arbitration screen, automatically returning control to App A.
When a hardware switch event is generated, the OS-SD MUST route the event sequentially from top to bottom. Once a tier consumes the event, routing stops.
- Failsafe Verification: If the event matches the System Escape Hatch (Trigger A), the OS-SD forcefully reclaims control and halts routing.
- System UI Override: If the OS-SD is currently displaying a System UI Overlay (like the Arbitration UI or a low battery warning), the OS-SD consumes the event to navigate the overlay.
- Primary Controller: The event is passed to the active primary_controller session (focus-agnostic).
- Foreground Handoff: If no primary_controller exists, the event is passed to the active exclusive_foreground session (must hold window focus).
- OS Fallback (STATE_OS_ROUTING): If no Client App session exists or holds focus, the OS-SD translates the event into standard system UI navigation. (Note: Active passive_observer sessions receive a duplicate of the event asynchronously, independent of this hierarchy, and do not consume the event).
6.5.4 Mutual Exclusion (Mutex)
To prevent catastrophic UI conflicts, the OS-SD MUST enforce strict Mutex rules based on the tiers:  Foreground: Mutex is naturally handled by the OS window manager. Only one app can hold window focus at a time.  Primary Controller: Mutex is handled explicitly by the System Arbitration UI (Section 6.5.2). If a new app requests control, the user MUST approve the handoff, ensuring two apps never hold primary_controller status simultaneously.