Y4.03.2Ritualized checkingdesign

A second signature that just repeats what the first person said protects nothing at all

Aliases: ritualized checking · functional safety

What it is

Ritualized checking happens when a checker mechanically signs, simply repeats the answer the operator already gave, or clicks approve without ever touching the source evidence themselves. The workflow completes and the signature field fills in, but no independent information was added anywhere in the process — the protective layer exists in name only, because the second independent judgment it depends on to intercept error never actually happened.

Why it happens

High repetition, low variation between instances, and schedule pressure combine to train checking from a genuine judgment into an automated reflex — a checker who has seen many similar cases unconsciously defaults to "probably fine like last time" and compresses careful verification into a quick glance. If the interface shows the operator's proposed answer before asking the checker to "confirm," it has actively done the anchoring for the checker: attention quietly shifts from "is this action correct" to "does this number match what I just saw" — two completely different cognitive tasks, and the second one requires no expertise to pass. A subtler problem lies in how management measures this: auditing "check completion rate" or "signature completeness" actually rewards a checker for finishing the workflow quickly, not for genuinely catching a problem — a checker who never finds a discrepancy looks, by this metric, like the best performer.

Where it stops holding

A fast check is not by itself evidence of ritual — a skilled checker really can complete a high-quality independent verification in a short time, and inferring quality from duration alone only encourages people to slow down deliberately to appear diligent. On the other side, pursuing blinding so aggressively that it also hides the background context a checker needs can leave them unable to make an accurate judgment for lack of context — over-hiding information and over-exposing it early are two opposite failure paths for the same design problem, and both weaken protection, just through different mechanisms.

Applying it

The interface must not design "both parties agree" as the default, encouraged success path; instead, treat a checker finding a discrepancy as evidence the protective layer is working correctly, and record and acknowledge that outcome at least as prominently.

  • Require the checker to independently reacquire a critical value, or answer a question that tests genuine understanding of the current situation, before revealing the operator's proposed action.
  • Log which evidence the checker actually consulted, what disagreement they raised, and whether they ever cancelled the action — not just whether a signature was eventually given.
  • How to check: test with seeded errors the checker is not told about in advance, and measure the actual detection rate — not check-completion rate or average duration, metrics that ritualized checking can easily inflate.

Related

  • Same group: Y4.03.1 Two-person verification · Y4.03.3 Independence in dual verification
  • Nearby: Y7.03 Procedural deviation · Y2.09 Alarm fatigue and the cost of false alarms
  • Search terms: Ritualized checking · functional safety · safety-critical systems

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y4.03.2