Without a predefined fallback, edge cases present as random system failure

What it is

Sun angle, a passer-by, a dark glove, a fingerprint on the lens: these are edge cases a deployment will meet. Without a predefined fallback, their shape on the user side is sometimes works, sometimes doesn’t, no pattern—random failure. The implementation may have a log line for each; the user sees one face, a moody device. Randomness is the outward symptom of a missing script, not the recognizer’s personality.

Why it happens

Edge conditions push scores and tracking off the training distribution. The happy path has no exit. Each failure’s proximal cause differs (backlight this time, a glove the next) while product behavior is always “no command came out.” People cannot learn a strategy under patternless reinforcement: they neither stably change stance nor stably find a button; they only trust the whole device less. Operations drown in tickets because “random” cannot be reproduced for a technician. Predefined fallback collapses many proximal causes into a few states a user can learn (switch to a large motion, use keys, go fix the light). The feeling of randomness drops even if the underlying error types remain many.

Studying it

Collect a week of failure events in the field or a high-fidelity mock, code proximal cause, then code user-visible behavior. In a system with no fallback, causes are many and visible behavior is almost only “no response.” After introducing fallback, measure whether kinds of visible behavior shrink and whether user strategy can be described. In interviews ask “what will you do next time”: “try my luck again” means random failure is still there; “if the light is bad I use keys” means the script has been learned.

Where it stops holding

A lab that only tests canonical stance and lighting never meets the edge cases and will conclude fallback is unnecessary. Truly random hardware faults (a loose connector, thermal reboot) cannot be caught by a recognition script; they should go to service, not be dressed as recognition fallback. A game that deliberately keeps “hard recognition” as challenge must not be turned into fallback; failure there is play, not emergency. A one-off demo with a human standing by suppresses the feeling of randomness by staffing, and does not represent unattended deployment.

Applying it

• Before launch, list high-frequency proximal causes from a week of venue video and assign each a user-visible state, rather than an engineer-only log line.
• Treat “users say it sometimes doesn’t work” as a missing-fallback signal. Walk visible states before retraining the model.
• At acceptance ask on-site users “what do you do when recognition fails.” If they cannot name a next step, it is still random failure.

Related

• Same group: C4.25.1 When recognition fails, the system should follow a predefined fallback rather than going silent · C4.25.2 Fallback can mean shrinking to a simpler gesture set or switching to another modality · C4.25.3 Fallback should not happen silently; users need to know they are in a degraded state
• Adjacent: C4.31 Lighting, occlusion, and environmental conditions · C4.24 Recognition confidence and bias direction
• Search: edge case · random failure · learned strategy