The system must detect at runtime whether the environment supports the default modality

What it is

At relevant moments, the system should test whether the default input or output modality actually works, and monitor critical conditions during use. Availability is more than hardware presence: the microphone has permission and adequate signal, speakers are not muted, a screen is visible, a haptic actuator is perceivable, a recognition service is reachable, and noise or lighting permit the channel to function.

Why it happens

A static capability list cannot predict runtime state. Headphone connection, Bluetooth latency, revoked permission, system mute, a disconnected display, a removed wearable, rising noise, or glare can change a channel mid-task. Detection therefore layers: a fast preflight before the task; confirmation before critical steps; low-cost monitoring of signal quality or device state during use. Each channel also needs an “available” threshold—recognizable speech signal-to-noise, haptics that survive grip and clothing, or visibility given brightness and gaze direction.

Studying it

Measure detection around device and context events: connect or remove headphones, drop Bluetooth, revoke permission, mute, change noise and lighting, or remove a wearable; record whether detection occurs, its latency, correctness, and false alarms. Variables include preflight timing, sampling frequency, thresholds, and device model. Outcomes include true positives, false-available, false-unavailable, notice latency, and interruption. Connect sensor events, permission events, and user retries in logs to verify detection precedes impact.

Where it stops holding

Runtime does not license continuous high-frequency sensing. Noise, gaze, location, or physiological monitoring costs battery and raises privacy risk; private conversation and meeting content should not be retained merely for detection. Physical limits remain: a masked speaker may be hard to detect without a test tone, and speech quality may be unknowable before the user speaks. Distinguish “hardware exists,” “permission allows,” and “current quality is sufficient”; never treat the first as full availability.

Applying it

• Define preflight items, runtime monitors, and failure thresholds for each default modality.
• Separate permission, hardware, system, and environmental-quality states; show the current conclusion rather than a generic “unavailable.”
• Recheck before critical operations and use low-power event listeners for device and permission changes during a task.
• Verification: stage each failure class, then measure detection lead time, misclassification, and whether users still try the dead channel.

Related

• Within the group: D5.10.2 Detection failure should actively offer alternatives rather than fail silently · D5.10.3 Detection latency changes perceived responsiveness
• Adjacent: D5.04.1 Noise, light, and social setting determine modality availability · D5.08.4 Frequent fallback indicates that the fusion window or recognizer needs adjustment
• Search terms: runtime detection · modality availability · preflight check