# Forcing Functions

URL: https://mechanisticmindset.com/wiki/forcing-functions
Tags: system-architecture, practical-application

# Forcing Functions

#system-architecture #practical-application

## <span id="key-principle" className="legacy-heading-anchor" />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. The probability comparison is roughly 0.3–0.6 for “I will do X,” depending on [willpower state](/wiki/willpower), against 0.95–0.99 when the system prevents not-X. Physical bypass limits the latter.

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:<br/>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<br/>forcing function]
    C --> D[Checklist implemented<br/>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 | Probability of Success | Failure Mode | Sustainability |
|----------|----------------|------------------------|--------------|----------------|
| **Mental reminder** | High; it occupies working memory. | 30–60%, depending on attention and stress | The person forgets under load. | It degrades over time. |
| **Habit/training** | Medium; installation requires [30 repetitions](/wiki/30x30-pattern). | 70–85% after installation | Stress restores an old pattern. | It works if maintained. |
| **Forcing function** | Zero; the constraint is external. | 95–99%, limited by physical bypass | The person deliberately circumvents it. | It persists until removed. |

## <span id="integration-with-existing-frameworks" className="legacy-heading-anchor" />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.

The probability calculation without a forcing function is:

```
P(correct_action) = willpower_available × attention_on_task × time_not_stressed
                  ≈ 0.6 × 0.7 × 0.5 = 0.21 (21% success rate)
```

With the constraint in place, the remaining failure is deliberate bypass:

```
P(correct_action) = 1 - P(deliberate_bypass)
                  ≈ 1 - 0.02 = 0.98 (98% success rate)
```

The [Boltzmann](/wiki/statistical-mechanics) account expresses the cost mechanism as `P(behavior) ∝ e^(-E/kT)`. Increasing E for the unwanted behavior makes its probability approach zero, even when available energy T is high. Removing the action entirely gives it infinite cost. 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 raises access to 4 effort units. 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, with infinite cost, or very expensive, at much more than 5 [willpower units](/wiki/willpower). The thermodynamic account then selects the permitted or cheaper action automatically.

### 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 from present evidence always approves.

### 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 (impossible during 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 below 2 units of activation cost is easy enough to require strengthening. A cost above 5 units, or physical impossibility, is adequate. Most physical constraints require zero maintenance because they persist, 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 | Probability of Repeat |
|--------|--------------------------------|-----------------------|
| “I'll be more careful” | It names no mechanism. | 80% |
| “I'll remember to check” | The reminder competes with other priorities under stress. | 60% |
| “I'll try harder” | The system still permits the same failure. | 90% |
| “I won't let it happen again” | The promise adds no constraint. | 70% |

A proposed change can instead specify how the workflow will catch or prevent the error:

| Answer | Forcing Function Type | Probability of Repeat |
|--------|-----------------------|-----------------------|
| “I'll add an automated test that catches this.” | A failed test blocks merging; bypass requires an override. | Less than 5% |
| “I'll create a pre-deploy checklist in CI/CD.” | The procedural gate requires steps to be passed or actively skipped. | Less than 10% |
| “I'll pair program for these changes.” | A partner can catch the error. | Less than 20% |
| “I'll add this to code review requirements.” | The reviewer receives the relevant information. | Less than 15% |

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 [4-7 slots](/wiki/working-memory)]

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 resource equation gives stress a multiplier of 1.5–3:

```
Cognitive_load = Internal_constraints × Stress_multiplier

Where:
  Internal_constraints = things you must remember
  Stress_multiplier = 1.5-3× under pressure

External constraints have:
  Cognitive_load = 0 (environment handles 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 below Tier 3 [willpower](/wiki/willpower). 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 raises the cost of use to the 6 units required for 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 at zero ongoing resistance cost 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 costs 4 units 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 threshold treats a bypass below 3 willpower units as too easy and a bypass above 5 units, or an impossible bypass, as 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. At 2 units each, that costs 100 units daily. Installing a lock is an intervention in the conditions producing those decisions; the comparison assigns it 10 units once and zero thereafter.

```
Instance strategy:
  Day 1: 100 willpower units
  Day 30: 3000 willpower units cumulative
  Day 365: 36,500 willpower units cumulative
  → Exhaustion, failure, reversion

Architecture strategy:
  Day 1: 10 willpower units (install forcing function)
  Day 30: 10 willpower units total
  Day 365: 10 willpower units total
  → Sustainable indefinitely
```

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) applies this over 30 days of installing triggers, defaults and prevention. The initial causal investment produces a permanent probability shift, after which the architecture handles ongoing execution. The design question is what installed constraint would make the behavior automatic indefinitely.

## 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, above 5 units. A locked drawer can 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, raising the cost of checking from 0.1 units to 4. The thermodynamic account predicts continued work becoming 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 only 0.1 units between an impulse and a check.

Removal gives access infinite cost, a locked drawer gives it a 4-unit cost, 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 below 3 units warrants strengthening; above 5 units or 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.