# Forcing Functions URL: https://mechanisticmindset.com/wiki/forcing-functions Tags: system-architecture, practical-application # Forcing Functions #system-architecture #practical-application ## What It Is A deployment fails because nobody checked the logs. Promising to remember next time leaves the same failure possible: during another busy deployment, the check still depends on someone remembering it. A deployment gate changes that condition. The deploy button stays unavailable until the required log check has passed. A **forcing function** makes an unwanted action physically impossible or much more expensive. It changes the actions the system permits, so success no longer depends on a reminder surviving stress, distraction and limited [working memory](/wiki/working-memory). A mental commitment works in what [superconsciousness](/wiki/superconsciousness) calls user space: it competes with other priorities and depends on attention and available effort. An environmental constraint remains active without that cognitive load. Whether “I will do X” happens depends on the [willpower state](/wiki/willpower) at the moment X is due. When the system prevents not-X, the only way left to fail is a physical bypass. Forcing functions implement [prevention architecture](/wiki/prevention-architecture) by removing an option or changing its cost. Forgetting cannot defeat a constraint that the environment enforces. ## Mental Todo List vs Physical Forcing Function The reminder leaves the deployment process unchanged. Under load, the same omission can recur: ```mermaid graph TD A[Mistake occurs] --> B[Boss: What next time?] B --> C[Answer: I'll remember] C --> D[Mental note added] D --> E[Next deployment:
Stressed, WM full] E --> F[Forget to check] F --> G[Same mistake] G --> A style G fill:#ff9999 ``` A CI/CD gate makes the log check a condition of deployment. When verification is missing, the deployment is blocked and returns to that condition: ```mermaid graph TD A[Mistake occurs] --> B[Boss: What next time?] B --> C[Answer: I'll add
forcing function] C --> D[Checklist implemented
in CI/CD] D --> E[Next deployment] E --> F{Logs verified?} F -->|No| G[Deploy blocked] F -->|Yes| H[Deploy succeeds] G --> E style H fill:#99ff99 style D fill:#99ccff ``` Habit and training occupy an intermediate position. Repetition can improve performance, but stress can still restore an older routine. | Approach | Cognitive Load | Success Depends On | Failure Mode | Sustainability | |----------|----------------|--------------------|--------------|----------------| | **Mental reminder** | High; it occupies working memory. | Attention and stress at the moment | The person forgets under load. | It degrades over time. | | **Habit/training** | Medium; installation takes [a month of repetition](/wiki/30x30-pattern). | The habit having been installed, and kept up | Stress restores an old pattern. | It works if maintained. | | **Forcing function** | Zero; the constraint is external. | Nobody physically bypassing it | The person deliberately circumvents it. | It persists until removed. | ## Altering Probability Space Before a constraint is installed, a correct action can compete with five incorrect actions. Which one happens depends on attention, stress and available effort. Removing the incorrect actions leaves only the correct action, or the correct action and an expensive bypass. Without a forcing function, the correct action needs three things at the same moment: enough willpower available, attention on the task, and a time when the person is not stressed. Each of them is often missing, and all three are present together less often than any one of them. With the constraint in place, the correct action no longer waits on those three. The remaining way to fail is a deliberate bypass. In statistical mechanics, the [Boltzmann](/wiki/statistical-mechanics) distribution, `P ∝ e^(-E/kT)`, says that the higher a state's energy, the less often a system is found in it. Behavior can be pictured the same way: raising the cost of the unwanted behavior makes it rarer, and removing the action entirely is the limit of that, an infinite cost, at which it does not happen at all. The picture orders the options without pricing them, because the effort of reaching a locked drawer is not an energy that can be put into the formula. In [control-system](/wiki/cybernetics) terms, the constraint bounds what an actuator can do regardless of its control signal. ## Categories of Forcing Functions ### 1. Physical Removal (Strongest) Removing the option gives the strongest constraint. An alarm across the room requires standing up to silence it. Locking a phone in a drawer puts a walk and a key between an impulse and the phone. A kitchen closure enforces an eating window ending at 2pm instead of relying on resistance after 8pm, and a CI/CD rule blocks a merge until tests pass. These arrangements replace a promise with a condition on the action. The unwanted action becomes impossible, or so expensive in [willpower](/wiki/willpower) that reaching it takes a deliberate effort. In the energy picture, the permitted or cheaper action is then the likelier one, and it no longer has to be chosen each time. ### 2. Temporal Constraints (Strong) A temporal constraint limits an action to a particular window. An eating window closing at 2pm makes further eating a violation of the system, with a high psychological cost. Keeping meetings off the calendar after 2pm preserves a period for deep work. A deployment freeze after 3pm prevents a rushed evening deployment when willpower is degraded. The constraint channels activity into the available time instead of requiring a fresh decision whenever the action arises. ### 3. Procedural Locks (Strong) A procedural lock requires an earlier step before a later action becomes available. A mandatory 24-hour wait for purchases over $500 prevents an impulse from becoming an immediate purchase. Deployment gates require tests, review, staging and logs before production. A prepared gym sequence works through ordered cues: laid-out clothes, a bag by the door and a calendar block make skipping require actively dismantling the preparation. A pill organizer with an alarm and visible placement requires someone to ignore several medication cues. The prepared path lowers the correct action's [activation energy](/wiki/activation-energy), while bypassing the sequence raises the cost of the incorrect action. ### 4. Social Commitment Devices (Moderate) A prepaid trainer attaches financial loss and social shame to a missed workout. A public ship date puts reputation at stake, while an accountability partner makes abandoning a goal consequential to a relationship. The person can still violate the commitment, which is why this category is weaker than physical prevention. Each arrangement installs a [counterparty](/wiki/counterparty) who holds the other side of the commitment. That person can also be appeased: a missed session can be explained, apologized for or renegotiated. A physical constraint does not accept an explanation. A self-issued rule is weaker still because the person who wants the exception also judges whether to allow it; a judge deciding case by case sees only the present evidence, and the present evidence favors the exception. ### 5. Information Forcing Functions (Moderate) Public daily weigh-ins make weight drift visible. Public [commit or word counts](/wiki/tracking) expose low output, and a live spending tracker on the home screen makes each purchase visible immediately. The feedback delay falls from months or years to a day or less. Information that remains in view is harder to ignore, but it can still be ignored. These devices work through visibility rather than a physical barrier. ## Forcing Function Design Protocol The deployment failure can be diagnosed by asking what allowed it. The specific failure was deploying without checking logs. The check was optional and depended on memory. Requiring verification before the deploy button becomes active removes that route to failure. The proposed hierarchy orders constraints by strength: ``` Weakest → Strongest: 1. Mental reminder ("I'll remember next time") 2. Checklist (can skip if stressed) 3. Social commitment (expensive to violate but possible) 4. Information forcing (make failure visible) 5. Procedural lock (requires sequence) 6. Temporal constraint (unavailable outside the window) 7. Physical removal (option doesn't exist) ``` Levels 5–7 provide the intended design target. Reminders and skippable checklists fail under load; social and information devices depend on social or psychological costs that can weaken over time. Implementation includes an attempt to bypass the constraint. A bypass that takes only a moment's effort, a tap or a reach, needs strengthening. A bypass that takes a deliberate effort, such as a walk and a key or a reinstallation, or one that is physically impossible, is adequate. Physical constraints mostly persist without upkeep, but apps can be reinstalled, locks disabled and time rules ignored. Repeated bypass can mean the constraint is too weak. It can also mean the constrained behavior serves a need that should be understood before the restriction is made stronger. ## The Boss Question: Proper Answers When a manager asks what will prevent a repeat, an answer should identify which condition will change. Promises leave the following routes to recurrence: | Answer | Why the error remains possible | |--------|--------------------------------| | “I'll be more careful” | It names no mechanism. | | “I'll remember to check” | The reminder competes with other priorities under stress. | | “I'll try harder” | The system still permits the same failure. | | “I won't let it happen again” | The promise adds no constraint. | None of these answers changes anything about the next deployment. The conditions that produced the mistake are all still in place, so a repeat is as possible as it was the first time. A proposed change can instead specify how the workflow will catch or prevent the error: | Answer | Forcing Function Type | |--------|-----------------------| | “I'll add an automated test that catches this.” | A failed test blocks merging; bypass requires an override. | | “I'll create a pre-deploy checklist in CI/CD.” | The procedural gate requires steps to be passed or actively skipped. | | “I'll pair program for these changes.” | A partner can catch the error. | | “I'll add this to code review requirements.” | The reviewer receives the relevant information. | These differ in how much they close. The automated test blocks the merge by itself, and getting past it takes an override. The checklist gate can still be actively skipped. A pairing partner or a reviewer catches the error when they notice it, which depends on their attention in the way the original check depended on yours. The reusable answer names a constraint, the error it addresses and the mechanism that prevents it: ``` "I'll implement [specific forcing function] that makes [error type] physically impossible/very expensive by [mechanism]." ``` ## Externalizing vs Mental Load Remembering logs, tests, documentation, notifications, backups and staging can already exceed available capacity before other tasks arrive: ``` Your brain's job: ├─ Remember to check logs ├─ Remember to run tests ├─ Remember to update docs ├─ Remember to notify team ├─ Remember to backup data ├─ Remember to verify staging └─ [10+ other items competing for a few slots] Result: Items get dropped, especially under stress ``` External tools retain those requirements and enforce them at the relevant point: ``` Environment's job: ├─ CI/CD: Cannot deploy without passing tests ├─ Pre-commit hook: Cannot commit without formatted code ├─ Calendar: Meeting reminder pops up automatically ├─ Linter: Cannot merge with warnings ├─ Script: Backs up before destructive operations └─ Checklist: Visibly incomplete until all items done Your brain's job: Execute what system requires Result: Cannot forget because system enforces ``` The load grows with the number of things that must be remembered, and stress makes each of them heavier to carry. A requirement the environment enforces adds nothing to that load, because the environment holds it. A requirement stored only in the person's head has to survive that load. An enforced requirement remains in the workflow, allowing the person to execute what the system requires without maintaining the reminder. ## Forcing Functions for Common Failure Modes A morning routine can begin with a calendar alarm, a visible journal and preset coffee. An automatically opened [braindump](/wiki/the-braindump) template supplies the next activity. A prepaid trainer or a gym bag blocking the doorway similarly makes a missed workout harder to overlook. Depleted decisions can be restricted to a morning calendar period, with no decisions after 6pm or when [willpower](/wiki/willpower) is low. A 24-hour delay for a decision above a chosen dollar amount or impact threshold can be enforced by manager approval or an automated delay. That makes “sleep on it” part of the procedure. Deleting social apps means every use has to begin with a reinstallation, instead of relying on a promise to stop after 30 minutes a day. Website blockers during work hours remove the option of treating every impulse as a break. Closing the kitchen means putting food away and turning the lights off, with the [eating window](/wiki/nutrition-architecture) publicly tracked. Not buying junk food prevents eating it without any ongoing resistance, because it is absent. A 9–11am calendar block can come with notifications off, a single task tab and the phone in a drawer. A Friday deadline gains external consequences from a public commitment, a scheduled pairing session and a deliverable required at the next meeting. ## The Pre-Mortem Protocol A phone in a drawer still permits several failures. Retrieving it takes a walk but remains possible. The computer may provide the same distractions. The phone may never enter the drawer before work starts. Locking the drawer increases the first bypass cost. Blocking social media on the computer closes the alternative route, and making “Phone in locked drawer” a morning checklist gate addresses the missing setup. Testing the bypass is necessary because a constraint can work against one route while leaving another untouched. The pre-mortem uses the same test as the design protocol: a bypass that takes only a moment's effort is too easy, and one that takes a deliberate effort, or is impossible, is adequate. ## Meta-Causality: Be Causal Once About the Thing That Will Be Causal Forever Resisting a phone 50 times a day requires 50 separate interventions, and the next day requires 50 more. Installing a lock is an intervention in the conditions producing those decisions, and it is made once. ``` Instance strategy: Day 1: 50 acts of resistance Day 30: 1,500 acts of resistance, cumulative Day 365: 18,250 acts of resistance, cumulative → Every one of them has to hold Architecture strategy: Day 1: 1 intervention (install forcing function) Day 30: 1 intervention total Day 365: 1 intervention total → Nothing left to resist while the lock stays ``` The initial change removes states from the available action space, giving it continuing effects. [Level 4 agency](/wiki/ladder-of-agency) calls this engineering the probability distribution, compared with predicting behavior or influencing one decision at a time. The same relationship appears when junk food is not bought, a morning sequence has an automatic trigger, distractions are blocked, or a [default response](/wiki/state-machines) becomes the healthy one. Those arrangements keep producing the desired behavior after the design intervention. [Agency](/wiki/agency) is used at the architectural level so that it need not be exercised at every later decision. The [30x30 pattern](/wiki/30x30-pattern) is a month of daily repetition, spent here installing triggers, defaults and prevention. The aim of that initial causal investment is a lasting shift in what happens by default, after which the architecture handles ongoing execution. The design question is what installed constraint would make the behavior automatic. ## Common Objections and Responses A restriction can feel rigid, but constant mental self-control imposes its own rigidity: vigilance is required throughout the day and can fail under stress. A phone in a drawer removes 50 occasions to resist checking it, freeing attention from repeated self-monitoring. An emergency escape remains available at a high cost: a locked drawer can still be opened for an urgent need. If bypass happens weekly, the escape is serving a routine use rather than an emergency, so the design needs strengthening or revision. External constraints are also a form of control exercised by the system's designer. Installing a working constraint uses deliberate effort to create sustained control. [Conscious override](/wiki/superconsciousness) can then be reserved for installation and emergencies, instead of being repeatedly depleted by ordinary decisions. ## Examples from Will's Systems Deleting DoorDash addressed money and time lost to delivery food after a weekends-only promise failed. Will deleted the app and installed a redirect for attempts to reinstall it. The reported result was zero DoorDash spending for more than 70 days and zero willpower spent resisting it. Will's eating window addressed late-night snacking when tired. The kitchen closed at 2pm, the last meal was at 1:30pm, and he fasted for 12 hours until the next meal. Eating after closure required breaking the system, imposing a high psychological cost. Evening resistance was eliminated after repeated attempts to resist cravings had failed. During work, locking the phone in a drawer replaced a failed breaks-only rule. Access required standing, walking and unlocking, where before it had taken a reach. In the energy picture, that makes continued work the favored action, allowing less fragmented [focus](/wiki/focus). A morning mantra became a gate after remembering the sequence failed. Work could not begin until the mantra was logged. The resulting streak exceeded 200 days, and work followed the prerequisite naturally instead of beginning in reactive mode. ## Designing Your Own Forcing Functions A specific failure description makes the design assessable. “I check the phone 50 times daily during work” identifies an action, a context and a frequency. The visible, accessible phone puts nothing but a reach between an impulse and a check. Removal makes access impossible, a locked drawer puts a walk and a key in the way, an app blocker introduces moderate friction, and a social commitment creates a reputational cost. Turning the phone off and locking it away is the strongest option. A drawer during work blocks is a feasible compromise; bypassable app time limits are the weakest acceptable option because they still create friction. The constraint then needs both a bypass test and observation in use. A bypass that takes only a moment's effort warrants strengthening; one that takes a deliberate effort, or is impossible, is adequate. If the restriction creates problems for legitimate use, it is too rigid for the actual need. Iteration seeks a constraint strong enough to prevent the failure while allowing that legitimate use. ## The Forcing Function Mindset Failure analysis begins with what the system allowed. A reminder adds another item to remember, whereas a constraint changes the conditions under which the mistake can happen. [Mechanistic thinking](/wiki/moralizing-vs-mechanistic) directs the repair toward that condition: the specific action that remained possible and the requirement that would prevent it. ## Related Concepts - [Prevention architecture](/wiki/prevention-architecture) supplies the general principle implemented by forcing functions. - [Counterparty](/wiki/counterparty) explains why social commitments bind and why another person can accept an exception. - [Superconsciousness](/wiki/superconsciousness) concerns the deliberate intervention used to install constraints. - [Activation energy](/wiki/activation-energy) explains the cost of an available action or bypass. - [Statistical mechanics](/wiki/statistical-mechanics) develops the probability and energy account used here. - [Willpower](/wiki/willpower) supplies the resource accounting for repeated resistance. - [Cybernetics](/wiki/cybernetics) describes constraints on actuator behavior. - [Working memory](/wiki/working-memory) explains why remembered requirements fail under load. - [Moralizing vs mechanistic](/wiki/moralizing-vs-mechanistic) distinguishes a character judgment from a change to the system.