Clicking acknowledge only means someone saw the alarm, not that the problem is fixed
Aliases: acknowledgement is not resolution · alarm acknowledgement
What it is
Acknowledging an alarm only means someone has received the message and accepted responsibility for assessing it; it does not mean the trigger condition has cleared, treatment has been completed, or the risk is closed. This leaf is about how state should be presented and should evolve after acknowledgement; what fields a message should contain and how sound and light should map onto priority belong to the other two leaves in this group. If an interface moves an acknowledged alarm straight out of the operator's normal active view, it presents a purely workflow-level state as if it were the process itself returning to normal — a mapping error at the presentation layer.
Why it happens
Acknowledgement closes a communication loop — it proves the message reached a person from the system — while treatment and risk closure close a field or control loop and require the process itself to provide evidence of recovery. These are different kinds of evidence and cannot be represented by the same action or the same timestamp. What actually needs recording is who took ownership and when, what action was actually taken afterward, whether the trigger condition itself has recovered, and on what basis the alarm was judged closeable — all four are necessary.
Where it stops holding
For a purely informational event, acknowledgement may be the only action required, since there is nothing to treat beyond being aware of it; for a condition that recovers automatically, treatment may need no manual closing step at all. But these categories must be defined in advance, during alarm rationalization, never left for the operator to judge case by case in the moment — that produces inconsistent treatment of the same alarm class by different people. The closure rule itself must also leave a trail for later audit.
Applying it
The default sort order of the active alarm list must not push an acknowledged alarm visually out of the way, burying a genuinely unresolved, high-risk item deep in the list. The interface should clearly distinguish five states — new, acknowledged but unresolved, under treatment, condition recovered, and verified closed — with an owner and timestamp on every transition. Validate with two replay scenarios designed specifically for this: a condition that persists after acknowledgement, and one that briefly recovers and then recurs; check that the alarm list, the process display, and the historical log all agree on the same state for the same alarm, with no contradictions between them.