A highlight that fades once seen, rather than once resolved, lets an open problem drop from view

What it is

When a highlight fades should track the anomaly's own risk lifecycle: being seen by an operator, being worked on, and actually being resolved are three different states. If the highlight fades simply because the operator pressed acknowledge, or because a reading briefly dipped back inside its threshold, an unresolved risk can drop out of the operator's attention while it is still there.

Why it happens

A brief, strong cue — a flash or a color change — is what pulls a new anomaly out of the background and captures attention; a persistent but less intrusive state marker is what keeps reminding the operator it is still unresolved, serving as external memory in place of continuous fixation on one point. Binding both jobs to the same signal — flashing, typically — creates a forced choice: keep flashing and fatigue the operator while masking the capture cue for the next new event, or stop flashing and look, visually, exactly like return to normal. Treating "just occurred," "acknowledged," "still unresolved," and "cleared" as four separately codeable states is what lets capture and persistence each do their own job.

Acknowledging an alarm only tells the system "a person has seen this" — it says nothing about whether the underlying problem is solved. Yet in many system architectures the only state transitions that are cleanly and reliably captured are "alarm raised" and "alarm acknowledged": acknowledgement has a crisp event boundary, while "has the problem actually gone away" usually has no equally crisp trigger and needs separate clearance logic to be built in. Without that extra logic, the path of least implementation effort is to tie the flashing's stop condition to acknowledgement, and acknowledgement collapses into resolution on screen — so the most dangerous state, acknowledged but still unresolved, ends up looking indistinguishable from a fully cleared one. This gets worse once sustained attention is interrupted: after a while nobody is actively watching a point that no longer flashes, and peripheral scanning rarely re-notices a static marker with no transient of its own, because vigilance for an unchanging, transient-free signal decays over time — the same underlying mechanism as the vigilance decrement seen during prolonged monitoring, just operating at a shorter timescale.

Studying it

In a simulated environment, design three anomaly types — acknowledged but persisting, intermittently self-clearing and recurring, and requiring a manual close — and measure how often operators later omit them when asked what is currently unresolved, how often they re-acknowledge something they had already acknowledged (a sign they forgot the earlier acknowledgement), and whether different presentation schemes let operators reliably distinguish "acknowledged, still present" from "cleared." A shift-handover task is particularly worth designing: have the incoming operator name every currently unresolved anomaly from the display alone, without the log, then check the omissions against the actual log.

Where it stops holding

Some transient conditions do not need to stay prominent once their triggering condition ends — a brief instrument spike, for example, needs a complete event record but not continued salience. Keeping every historical anomaly highlighted creates its own visual load, trading the risk of missing something for a screen where everything looks like it needs attention. Separately, some anomalies are deliberately, time-bounded suppressed by an operator — commonly called alarm shelving — which is an explicit action that should leave a record and be revisited when it expires. If shelving is shown with the same persistent marker as an ordinary acknowledgement, it loses the traceability and expiry reminder that are the point of shelving in the first place, and operators cannot tell a quiet point apart as "judged safe and deliberately left" versus "simply unseen."

Applying it

Give a new anomaly a brief, high-intensity capture cue, then — once acknowledged or after some interval — switch it to a visually distinct but still clearly readable "unresolved" marker rather than no marker at all; move it out of the active area only once a predefined clearance condition is met, such as the reading returning to normal and staying there, or a linked work order closing, and never let a manual acknowledgement alone trigger that step. Give anomalies that are deliberately shelved their own presentation, distinct from both "unresolved" and "cleared," and have the system re-prompt when a shelf period expires. How to check: pull real historical cases where an alarm stayed acknowledged and unresolved for an extended period, replay the display state from that time, and confirm it was visually distinguishable from a cleared alarm; separately audit shelving records for entries that ran past their review date.

Related

• Same group: Y1.06.1 Spatially localized anomaly highlighting · Y1.06.2 Salience aligned with alarm priority · Y1.06.3 Salience competition during multiple anomalies
• Nearby: Y2.05 Alarm suppression and shelving · Y2.07 Alarm response and acknowledgement
• Search terms: alarm shelving · alarm acknowledgement · vigilance decrement