Being seen and being fixed are different states that one acknowledge click shouldn't conflate

What it is

"Acknowledged" in an alarm workflow means someone has received the message and accepted responsibility for assessing it; "treated" means a specific corrective action has actually been carried out and there is evidence it took effect. If both meanings share one button, the team can no longer tell from that button alone whether the risk is still present, who is currently working it, or whether someone simply silenced the tone. This leaf is about whether these two concepts should ever be merged into one state; when an alarm should escalate, who is authorized to acknowledge, and how timestamps should be recorded belong to the other three leaves in this group.

Why it happens

Acknowledgement closes a communication-level loop, proving the message reached a specific person; treatment closes a control- or field-level loop, usually requiring the process itself to show a response before it can genuinely be considered complete — the two require entirely different kinds of evidence. Only by modeling them as separate states can a manager calculate where a real response delay actually occurred — no one accepted it, someone accepted but never acted, or someone acted but the process recovered slowly — and only then can an abandoned alarm, acknowledged and never followed up, be detected, while the next shift can see clearly who actually owns what happens next.

Where it stops holding

For a purely informational event that needs no separate treatment, acknowledgement can legitimately be the final action, and forcing a separate "treated" state adds nothing; for a condition that recovers automatically, treatment may need no manual closing command at all. But these categories must be defined in advance, during alarm rationalization, and written into configuration — never left for the operator to judge on the spot, which produces inconsistent treatment of the same alarm class across shifts and individuals.

Applying it

Split the state machine into four explicit stages — accepted/acknowledged, under treatment, condition recovered, verified closed — and record the acting person's identity and a timestamp on every transition each role is authorized to make. Validate with two scenarios built specifically for this: a trigger condition that persists without ever being treated, and someone marking the alarm closed before the process has actually recovered. Check whether the team can still see from the interface that the risk remains open in both cases, rather than being misled by one generic "acknowledged" state.

Related

• Same group: Y2.07.2 Escalation of unacknowledged alarms · Y2.07.3 Role-aligned acknowledgement authority · Y2.07.4 Timestamped alarm response trail
• Nearby: Y2.06 Alarm presentation · Y1.06 Detecting and highlighting anomalies
• Search terms: alarm acknowledgement · alarm lifecycle · alarm management