Skip to content

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.[1]

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.

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.

References

[1] 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. ↩