Attention should go to whichever robot raises an exception, not to each in fixed turn
Aliases: event-driven attention allocation · human-swarm interaction
What it is
Attention across a supervised fleet should be allocated by exception — event-driven, management-by-exception — rather than by fixed round-robin polling that checks every robot in turn.
Why it happens
Polling spreads a fixed attention budget evenly across the fleet regardless of whether any given robot needs it right now. Most robots are nominal most of the time, so time spent polling them is pure loss compared with an exception-based scheme — time that could instead go toward robots actually showing a problem. Event-driven supervision pushes the signals worth attending to — performance drift, fault warnings, a task step needing confirmation — to the operator instead of requiring the operator to hunt for them. That shift has a cost: the detector now defines what the human can see, and a poorly set threshold can keep a genuine anomaly out of the operator's view indefinitely. Thresholds are typically calibrated once at deployment, but sensors drift with use and mission conditions change, so detection quality degrades from its calibrated baseline unless thresholds are recalibrated — event-driven supervision is a maintained component, not a one-time design decision that holds indefinitely.
Studying it
Typical comparisons pit round-robin inspection against exception-based or hybrid interfaces at matched fleet sizes, measuring overall task performance, response time to injected anomalies, and workload. A separate strand of work targets threshold misconfiguration directly: too loose a threshold misses real anomalies, too tight a one degenerates into high-frequency polling in disguise, since frequent false alarms consume attention just as polling does — the same mechanism behind alarm flood in classical human factors work. These studies typically inject detector misses and false positives deliberately rather than evaluating only a perfectly performing detector, which would systematically overstate the benefit of exception-based allocation.
Where it stops holding
Exception-based allocation only works if the system can detect and classify anomalies reliably; if detection itself is inaccurate — missing events or flooding false ones — the strategy's advantage is eroded or reversed. Tasks whose purpose is preventive, non-exception inspection, such as routine patrol as the mission itself, still need polling and should not be converted wholesale to exception-based supervision. Going long stretches without looking at nominal robots also erodes the operator's situational context for each one, leaving them under-informed the moment a real handover is needed. If the detector cannot aggregate correlated anomalies, alerts sharing one root cause get pushed one by one as if independent — nominally still exception-based, but functionally a small alarm flood that wastes attention in a different way than polling does, though with the same net effect.
Applying it
Treat automated anomaly detection and tiered alerting as core interface functionality rather than a status panel the operator patrols manually. Every push should state which robot, what evidence triggered it, how severe the consequence is, how much response time remains, and the detector's own confidence; rank by risk, keep unresolved items visible, and schedule low-frequency active sampling as a backstop. Validate by comparing time-to-response before and after the exception-based interface ships, while tracking false-alarm rate to confirm it stays below the point where operators start experiencing alarm fatigue, and stress-test the queue design against several anomalies arriving at once.