Actionability Checklist¶
Issuance gate — instantiates Signal Value Preservation
Gates each signal on a single question — does it name a specific action its receiver can take right now? — so signals that imply no response never fire.
The Actionability Checklist is a short go/no-go gate a candidate signal must pass before it may fire: it must name the exact action its receiver should take, and the receiver must be the person who can take it. The one idea that makes it this mechanism and not its siblings is that it filters on actionability rather than on volume, evidence quality, or authority — a firing that would not change what the receiver does is treated as noise no matter how true it is. Where other guards ask "is this correct?" or "have we sent too many?", this one asks the narrower, sharper question: what will the receiver do about it, and can they? If the honest answer is "nothing" or "not them," the signal is killed or demoted to a passive log.
Example¶
A hospital rolling out medication-safety pop-ups in its electronic health record runs every proposed alert through the checklist. An alert reading "patient is taking five or more medications" fails: true, but it names no action the prescriber can take at that moment, so it becomes a passive entry in the chart rather than an interrupting pop-up. An alert reading "serum potassium 6.2 with a new ACE-inhibitor order — consider holding" passes: it names the condition, the specific action (hold the drug), and fires to the person who can do it. Applied across hundreds of rule types, the checklist quietly kills the majority of interrupting alerts and keeps the ones that survive tightly coupled to a decision — the direct countermeasure to alert fatigue, where clinicians learn to click past every pop-up because most demanded nothing of them.
How it works¶
Each candidate signal must answer three questions before it is allowed to interrupt anyone: What must the receiver do? (a concrete action, not "be aware"), Who is that receiver? (the actor who controls the action, at the moment they see it), and Is the action theirs to take now? A signal that cannot answer all three is either suppressed or routed to a non-interrupting channel. The distinguishing move is that it binds a firing to a response specification, not merely to a claim — the signal and the action it demands are defined together.
Tuning parameters¶
- Action-specificity bar — how concrete the named action must be, from "do something" to "hold drug X at this dose." A higher bar kills more low-value alerts but can suppress genuinely ambiguous-but-important warnings.
- Passive-channel fallback — whether failed items are deleted or demoted to a silent log. A fallback preserves information without spending attention; too generous a fallback becomes a dumping ground no one reads.
- Receiver-match strictness — whether the named actor must be the exact recipient. Strict matching prevents "someone should handle this" diffusion; too strict and boundary cases fall through the cracks.
- Recheck trigger — re-running the checklist when a signal's action goes stale (the drug is discontinued, the runbook changes), so a once-actionable alert doesn't linger after its action disappears.
When it helps, and when it misleads¶
Its strength is that "what will they do about it" is the most reliable filter against noise there is — most channel bloat is informational firings that demanded nothing, and this gate removes them at the source. Its failure mode is that some genuinely important signals carry no immediate action: situational awareness, a slow-building risk, "the storm is three days out." A rigid actionability bar suppresses exactly those, and the checklist is easily run backwards — declaring an inconvenient alert "non-actionable" to justify killing it. The discipline that guards against this is to keep a reviewed passive channel for information-only signals rather than deleting them outright, and to let the actor, not the issuer, certify that a signal is non-actionable.[n1]
How it implements the components¶
response_coupling_rule— its core: it binds every firing to a specific required response and refuses any signal that couples to none.signal_claim_definition— it forces each signal to state precisely what it claims, so the matching action can be named; a mark asked to carry several incompatible claims fails the gate.
It does not measure how often a signal is right (signal_base_rate_monitor, false_alarm_and_miss_ledger) — that's Base-Rate and Precision Dashboard — nor ration total issuance volume (receiver_attention_budget) — that's Alert or Label Budget.
Related¶
- Instantiates: Signal Value Preservation — the checklist supplies the per-signal actionability gate the archetype's issuance discipline depends on.
- Sibling mechanisms: Alert or Label Budget · Audience-Specific Routing Filter · Signal Issuance Rubric · Public Criteria Register
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: The mechanism imposes a standing three-part eligibility rule on every candidate signal and suppresses or reroutes any signal that cannot name an immediate action and responsible receiver, so its operative form is a policy constraint.
Nearest alternative: Representation, Specification & Plan — The checklist is the rule's carrier; its operative effect comes from gating whether a signal may fire, not from serving as a passive reference artifact.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Gating alarms on a specified operator response and demoting signals that cannot change action is rooted in safety engineering and human-factors alarm management.
Related originating lineages:
- Aviation & Aeronautics — Flight-deck warning design developed strict distinctions among awareness cues, cautions, and warnings tied to feasible crew procedures.
- Human-Computer Interaction — Attention limits, interrupt costs, recipient fit, and alert fatigue supply the interface-design logic.
- Medicine & Healthcare — Clinical decision support developed major evidence and professional practice around actionable versus nuisance alerts.
- Systems Thinking & Cybernetics — A signal's value is defined by its coupling to an available control response.
Review resolution: Requiring an alarm to specify a feasible operator response is most directly rooted in safety engineering and human-factors alarm management. Aviation, HCI, clinical alert safety, and control-system thinking are materially formative convergent lineages; the page's compact go/no-go checklist is a synthesis of them.
Attribution caveat: Aviation, process safety, and clinical informatics developed closely related actionability disciplines; engineering is the broadest primary lineage.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
Actionability is receiver-relative: the same signal is a clear call to action for one audience and pure noise for another. That is why this gate pairs naturally with Audience-Specific Routing Filter — the checklist decides whether a signal implies an action, and the routing filter decides for whom.
[n1] Alert fatigue — the desensitization that sets in when receivers face so many alerts, many of them low-value, that they begin overriding or ignoring all of them, including the critical ones. It is well documented in clinical informatics, and the standard corrective is to cut low-actionability alerts rather than make the survivors louder — the logic this checklist enforces. ↩