A forcing function placed at the wrong step blocks legitimate operations instead of hazardous ones
Aliases: misplaced gate · false positive block · wrong checkpoint
What it is
Whether a forcing function actually blocks a hazard depends on which step of the flow it sits at, not merely on whether it exists. If the checkpoint sits far upstream of where the hazardous action would actually happen, or sits at a node that most people passing through are actually reaching for perfectly legitimate, safe reasons, the forcing function ends up blocking a large volume of otherwise fine, normal work — while the hazardous action it was meant to stop may not even pass through that checkpoint at all, and completes just the same.
Why it happens
When a designer places a forcing function, they have a typical hazardous path in mind, but the actual reasons real users arrive at a given node are usually far richer than that one typical path — the same node might be the last step before a hazardous action is about to happen, or it might be a completely harmless waypoint on a huge number of legitimate paths. If the checkpoint is placed on this kind of "mixed node," the forcing function has no way to tell whether this particular pass-through is headed toward a hazard or toward a legitimate outcome, so it has to block everyone who passes through equally — meaning protection and interference happen at the same time: the genuinely hazardous action, if it has another route that avoids this node, completes anyway, while a large number of legitimate operations end up paying for a risk that was never theirs.
Studying it
A standard way to diagnose whether a forcing function is misplaced is to instrument the whole operation path and separately measure, among people blocked at this checkpoint, the proportion who were actually en route to a hazard versus the proportion who were actually doing something legitimate — in other words, the checkpoint's false-positive rate — while also checking, in reverse, whether users who did complete the hazardous action actually took a path that avoided this checkpoint entirely. Looking at both numbers together says far more than just counting "how many times this checkpoint fired": a high block count might simply mean a lot of legitimate users got caught in the crossfire, not that it's actually preventing much risk.
Where it stops holding
Judging whether a checkpoint is misplaced assumes there's some independent way to tell whether a given pass-through is genuinely headed toward hazard. If that judgment has no reliable basis at all — intent simply can't be distinguished before this point — then placing the checkpoint anywhere runs into the same false-block problem, and that's not something a better placement can fix; it calls for reconsidering which mechanism should be used to guard against this risk in the first place.
Applying it
Before setting up any forcing function, map out every path in the flow that passes through a candidate checkpoint, and mark which ones ultimately lead to the hazardous action and which lead to legitimate ones. Only place the gate at this node if the hazardous and legitimate paths are highly separated there — meaning the overwhelming majority of people reaching this point really are headed toward the hazard; if the separation isn't strong enough, move the checkpoint further downstream, to the step where the hazardous action is actually about to occur. Verification: after launch, measure what fraction of this checkpoint's total blocks turn out to have genuinely been hazardous actions. If that fraction stays low over time, the checkpoint is in the wrong place and needs to move further along the operation path — strengthening the block at the current location won't fix it.
Related
- Same group: A10.14.1 forcing functions are implemented as lock-in, lockout, or interlock, each matching a different risk pattern · A10.14.5 stacking too many forcing functions drives skilled users to hunt for unconventional shortcuts
- Nearby: A10.04 description-similarity errors · A10.06 error-proofing design
- Search terms:
misplaced gate·false positive block·forcing function placement
Cards in the same group
- A10.14.1Forcing functions are implemented as lock-in, lockout, or interlock, each matching a different risk pattern
- A10.14.2Software-level forcing functions can be bypassed by privileged users, physical ones usually can't
- A10.14.4Interlock's intermediate states need explicit feedback, or users will assume the system has frozen
- A10.14.5Stacking too many forcing functions drives skilled users to hunt for unconventional shortcuts