An alarm message should name the object, the deviation, and the first safe action, not just a code
Aliases: action-oriented alarm message · alarm rationalization
What it is
An action-oriented alarm message lets the operator identify the affected object, the current deviation, and the first safe response directly from the message text, rather than exposing only an internal tag or fault code. This is the on-screen form of what alarm rationalization — a core deliverable of the ISA-18.2 alarm management lifecycle — already requires on paper: every rationalized alarm must document a cause, a consequence, and a corrective action. If that corrective action stays in the rationalization record while the live display still shows a bare tag, actionability never actually reaches the operator. Any embedded guidance must be conditional on the current operating mode and on what the operator is actually authorized to do, and it must never assert an unverified root cause as settled fact.
Why it happens
During an incident, reading time is the scarcest resource. A bare tag forces three separate hops — find the object in the alarm list, locate the matching procedure, then return to the object to act — and those hops alone can consume more time than the eventual response. Placing "what is deviating, by how much, and what to do first" directly in the message, with a link into the relevant procedure step, removes the orientation and retrieval hops from the response window; it does not simply make the text easier to read. Raw sensor values and diagnostic detail still belong in a secondary detail view for verification and must not be compressed out of the message.
Where it stops holding
The structure assumes the current state maps onto a reasonably well-defined first action, but complex faults often do not have one: the same trigger can call for different, even contradictory, responses during startup, maintenance, and normal operation. In that situation, confidently specific instructions are more dangerous than an honest "cause undetermined, begin discrimination steps" — the operator may execute an action tailored to the wrong scenario. Automatically generated guidance must still respect interlocks and authorization; a wording template cannot be allowed to talk its way around a safety interlock or past what the operator is actually cleared to do.
Applying it
Fix the message template to five fields — object, deviation direction and magnitude, consequence or response window, first action, and procedure entry — and generate a distinct version per operating mode rather than sharing one template across all of them. Validate with uncoached exercises: show operators an isolated alarm message with no other context and time whether they select the correct object and state the correct first action. Track separately any failure caused by misleading guidance itself — a confident but wrong instruction that triggers a harmful intervention is worse than an operator who simply fails to find the object, and it should be repaired first.
Related
Cards in the same group
- Y2.04.2An alarm that triggers after there's no time left to respond is functionally just noise
- Y2.04.3A message that only says fault or abnormal leaves the operator guessing from memory, not procedure
- Y2.04.4Whether an alarm is actionable should be settled before commissioning, not patched tag by tag after