Forcing functions are implemented as lock-in, lockout, or interlock, each matching a different risk pattern

What it is

A forcing function is a design constraint that makes it impossible to proceed to the next step unless some precondition is met — it doesn't remind you not to do something, it makes doing it physically or logically impossible in the first place. "Forcing function" is an umbrella term, not a single technique; in practice it's implemented through three mechanisms, each aimed at a different risk pattern. Lock-in prevents a user from exiting an ongoing operation prematurely when interruption itself would cause harm. Lockout prevents a user from entering a state or zone that's dangerous by itself. Interlock constrains several operations to happen in a specific order, so skipping the order makes it impossible to proceed. What the three share is moving the judgment of "should this be allowed to continue" off the user and onto the system's own preconditions; what separates them is which end of the action each one blocks.

Why it happens

These three have to be kept separate because the risk structure behind each is completely different. Lock-in targets the risk that "stopping partway is more dangerous than finishing" — a microwave door staying locked while it runs, a program refusing a forced quit mid-write. If a user were free to exit at that point, the act of exiting is itself what causes the harm, so lock-in isn't about preventing completion, it's about preventing interruption during the process. Lockout targets the opposite risk: "entering this state is itself where the danger begins" — an elevator car can't move while its doors are open, power is cut when a machine's safety guard is lifted. The risk here isn't in exiting midway, it's that once this state is entered, everything that follows is already exposed to danger, so the block has to sit at the entry point. Interlock targets a risk carried by the order of operations itself: the brake has to be pressed before shifting out of park, identity has to be verified before a sensitive action proceeds. If the order gets scrambled, the later step ends up resting on a precondition that was never actually satisfied, and interlock uses a physical or logical block to make the later step untriggerable until the earlier one has actually completed. None of the three rely on the user "remembering" or "noticing" anything — they write the correct order, or the safe state, directly into whether the system can even execute the next step.

Studying it

As a formal design concept, forcing functions were first systematized to analyze error-prevention design in everyday objects and industrial equipment; the standard way to evaluate them is to review how the incidence of a given failure class — misoperation, entering a hazard zone, skipping a step — changed after the corresponding lock-in, lockout, or interlock mechanism was introduced. A great deal of this evidence comes from industrial safety and equipment design, since forcing functions were first applied to high-consequence mechanical and industrial systems. Whether a given forcing function design holds up hinges on whether it's targeting the right failure mode: if the errors that actually occur aren't the ones the designer thought they were blocking, the incident rate won't drop even though the forcing function exists, because it's blocking the wrong direction.

Where it stops holding

All three mechanisms depend on the precondition being something the system can judge accurately; if the underlying sensor or state flag that judgment relies on is wrong, the forcing function will just as reliably block a legitimate operation or let through the one it was supposed to catch — its reliability has no ceiling above the reliability of the state judgment it's built on. The three mechanisms also aren't mutually exclusive: a complex flow can perfectly well use lock-in to prevent premature exit and interlock to constrain step order at the same time; which one to use depends on where in the operation the risk actually sits, not on a designer's preference.

Applying it

When designing any flow involving a high-consequence action, first locate where the risk actually sits: if the risk is "exiting partway causes harm," use lock-in; if the risk is "entering a state is itself dangerous," use lockout; if the risk is "doing steps out of order means a later step rests on a false precondition," use interlock. Don't lump the three together as "just add a restriction" — they block different failure modes, and using the wrong one means the risk was never actually blocked at all. Verification: for every forcing function, write down explicitly which risk scenario it corresponds to and which failure mode it's meant to intercept, then test it against real or simulated misoperation data. If a given error's rate doesn't drop after the mechanism ships, the original read on where the risk sits was wrong, and the fix is to relocate where in the operation the risk actually occurs, not simply to make the existing mechanism stricter.

Related

• Same group: A10.14.2 software-level forcing functions can be bypassed by privileged users, physical ones usually can't · A10.14.3 a forcing function placed at the wrong step blocks legitimate operations instead of hazardous ones · A10.14.4 interlock's intermediate states need explicit feedback, or users will assume the system has frozen
• Nearby: A10.06 error-proofing design · A10.03 omission errors and execution errors
• Search terms: forcing function · interlock · lockout · lock-in