# Ratchet

URL: https://mechanisticmindset.com/wiki/ratchet
Tags: core-framework, system-design

# Ratchet

#core-framework #system-design

## What It Is

Fixing a bug and adding a test accomplish different things. The fix corrects the current behavior. The test keeps the next change from silently bringing the bug back. Finding the error required a search; retaining the fix requires a structure that survives that search.

A **ratchet** is a structure that holds a gain after it has been made. In the mechanical version, a wheel turns forward while a pawl drops behind each tooth. The pawl makes reverse rotation physically impossible. Progress can stop without the wheel surrendering the position it has reached.

A boundary, default, cached routine, test, verifier, automation or intermediate configuration can perform the same job. It turns a gain made once into a floor below which the system cannot fall. A path or waypoint can be discovered through search; the ratchet holds it after discovery.

Without retention, a system can solve the same error repeatedly while each trial begins from the same floor. With ratchets, the floor is monotone: it never decreases as the system accumulates history. This gives a stricter definition of progress: **errors closed AND held closed**. Closing an error without a lock is a temporary fluctuation that has not yet reverted.

[Prevention architecture](/wiki/prevention-architecture) and [taste compilation](/wiki/taste-compilation) describe related structures. Prevention blocks entry into a bad state; a ratchet blocks departure from a good one. Taste compilation applies retention to judgment by capturing it in a reusable bundle. The sections below distinguish the first relationship and develop the general retention account behind the second.

## Ratchets, Not Hill-Climbing

Daily effort can raise performance without raising the level you retain. Willpower changes, attention moves elsewhere, and a difficult week can erase progress that was expensive to make. Repeated effort does not compound if each gain leaks away before the next attempt.

The distinction appeared while designing the weekly loop of a shared goal system:

> "Our goal is not to just assume that we can hill climb on it — the strategy of convergence is to test out structures that can serve as ratchets that lock in progress towards it."

A weekly loop can test boundaries, defaults, containers and automations, then keep the ones that hold a gain. This applies [selection over design](/wiki/selection-over-design) to the structures supporting the work: their value is established by whether they persist and change what happens, rather than by confidence in the original design.

The food-hall example makes the test concrete. A spending-and-food collapse led to a standing boundary concerning that place, that state and that card. On the next approach, the boundary took effect and the crisis did not repeat. The earlier incident had changed the structure the person encountered later. Its lesson no longer depended on remembering the incident or recovering the motivation felt afterward.

| | Hill-climbing | Ratcheting |
|---|---|---|
| Progress model | Continuous upward push | Close an error, install a lock, move on |
| What a bad week costs | Everything since the last peak | Nothing below the highest pawl |
| Powered by | Willpower at every step | Structure installed once |
| Same mistake | Recurs indefinitely | Illegal after first closure |
| Trajectory shape | Sawtooth around a plateau | Staircase |

## Entry-Blocking vs Exit-Blocking

[Prevention architecture](/wiki/prevention-architecture) and [forcing functions](/wiki/forcing-functions) remove transitions into bad states. The donut is not bought, the app is not installed, or the case never reaches the judge.

A ratchet removes transitions out of good states. The fixed bug cannot return, the next agent cannot lose a converged skill, and a boundary still holds when the situation recurs. Both operations delete an edge from a [state machine](/wiki/state-machines); they address different edges.

| | Prevention architecture | Ratchet |
|---|---|---|
| Blocks | Entry into bad states | Exit from good states |
| Governing question | "How do I never end up there?" | "How do I never lose this?" |
| Typical failure addressed | Relapse into a known trap | Regression from a known gain |
| Cost logic | Zero willpower per avoided temptation | Zero re-derivation per retained gain |
| Time orientation | Defends the future from the past | Carries the past into the future |

The food-hall boundary can be described both ways. As a barrier to entering the crisis state, it is prevention. As a barrier retained from one encounter to the next, it is a ratchet. Prevention describes what the structure blocks; ratcheting describes the fact that the system kept the change it learned.

That distinction explains why many prevention rules do not necessarily produce accumulated progress. A life can contain such rules and still reset every month if none survives the month. Retention is what lets the next attempt begin from a different state.

## What Qualifies as a Lock

A lock is a **retained structural change that alters the next traversal**. Remembering a lesson does not meet that definition unless the lesson has changed what will happen next.

The test is: if you showed up amnesiac tomorrow, would the gain still hold? A note to yourself or a resolution fails. A test suite, automation, default or boundary that takes effect on approach passes. These structures preserve the consequence of the earlier learning without requiring you to reconstruct it first.

The main kinds of lock differ in where the change is stored and how it is enforced:

| Lock type | Form | Canonical treatment |
|---|---|---|
| Behavioral lock | Forcing function, precommitted rule, boundary | [Forcing Functions](/wiki/forcing-functions), [Prevention Architecture](/wiki/prevention-architecture) |
| Neural lock | Cached habit — a routine burned in until it runs without deliberation | [Discipline](/wiki/discipline), [30x30 Pattern](/wiki/30x30-pattern) |
| Judgment lock | Verifier, golden set, rejection ledger | [Taste Compilation](/wiki/taste-compilation), [Lockfile](/wiki/lockfile) |
| Data lock | Monotonic, append-only substrate — captured once, never re-derived | [Accrual Substrate](/wiki/accrual-substrate) |
| Code lock | Write-path validation — illegal transitions unrepresentable | This article, below |

## Intermediate Ideal States

A distant goal can be too far away to reach in one search. But choosing arbitrary milestones does not solve that problem if nothing in reality supports them.

> "The search needs to find ratchet systems and reach intermediate ideal states, otherwise it feels like trying to bench 300lbs while being detrained ... Setting arbitrary milestones like typical goals seems iffy/aspirational/airy and not reality-backed."

An **intermediate ideal state** is a configuration you have actually reached, checked against reality and can retain with a lock. It is a [macrostate](/wiki/macrostate-engineering) with two requirements: it is reachable from the current state, and it is holdable once reached.

The search discovers these waypoints. A lock then makes the reached waypoint the starting point for the next search. This differs from inventing a number in a planning session and declaring it a milestone; the intermediate state has demonstrated both its accessibility and its ability to persist.

The career example describes that sequence:

> "She did an internship, and after the internship she got an offer from the company. That's cool. You should do that. You should just build up your career in a ratchet."

An internship converts to an offer, the offer to a title, and the title to a floor under the next move. The sequence is structured so that failure at a later step does not surrender an earlier completed one.

## Persistence Is Memory

Trying for the 10,000th time differs from trying again only if something from the previous trials survives.

> "I never really thought about persistence as memory. ... You either need the accumulated trials, or repeated trials create something between version one and version two. The value is retained memory."

Elapsed time and grit do not supply that retention by themselves. The trials must accumulate somewhere or produce a change between version one and version two. Otherwise, the 10,000th attempt repeats the first with additional wear. Moving from version N to N+1 requires something retained between trials, which is the job of a ratchet.

Let $j$ be the gain a trial produces and $c \in [0,1]$ the fraction structurally retained. After $n$ trials, the floor rises with $\sum c \cdot j$, while recurring effort remains proportional to $(1-c) \cdot j$.

At $c = 0$, every attempt requires the full effort again. The floor never rises, so persistence remains a description of the person rather than an accumulated asset. At $c$ near 1, each trial raises the floor and leaves live effort available for work beyond what has already been secured.

[Taste compilation](/wiki/taste-compilation) applies this to judgment: $j$ is the verdicts exerted and $c$ is the fraction captured into the bundle. The general condition is **persistence pays only at $c > 0$**. Increasing $c$ requires installing retention when the gain is made; it does not require more talent.

## The Code Form: Make Backsliding Unrepresentable

A test can expose a regression. A stronger lock removes the ability to encode the regression at all. The design notes for an event-sourced orchestration system describe such a rule:

> "Every append validates through the reducer first so illegal transitions cannot reach disk."

In that system, a basin without a termination condition cannot be constructed. A completion claim with zero commits cannot be recorded. Derived states are computed instead of stored, removing the possibility that a stored copy disagrees with its inputs.

These restrictions enforce correctness where a write occurs. Review does not have to notice the illegal state afterward because that state cannot reach the record. This is [structure over request](/wiki/structure-over-request) applied to retention: the system's permitted forms exclude the divergence that an instruction would merely ask it to avoid.

A test suite supplies a softer version of the same lock. A regression can still be represented, but it cannot pass unnoticed.

The riverbed account in [Intelligence Is Water](/wiki/intelligence-is-water) describes the same restriction in terms of accessible microstates. Each ratchet removes routes through bad states. With enough locks, only the paths selected for retention remain available.

## The Limit: Ratchets Hold Gains; They Don't Generate Them

A structure that prevents loss still needs something that produces a gain.

> "You cannot just mistake your way into making money."

Errors followed by retained updates were producing durable improvements. That is a real learning loop, but it can converge entirely on avoiding loss. A system consisting only of locks can prevent every repeated failure while producing no experiments, contacts or paths to income.

A stationary wheel with a pawl illustrates the missing part: without something turning the wheel, the mechanism acts as a brake. Every ratchet therefore needs a generative structure that produces gains worth holding. Retention begins after a gain exists.

A [basin](/wiki/basin) has a different job again. It collects incoming information, observations and developments toward a goal. A ratchet holds gains already made. A basin can keep filling without any gain being retained, while a ratchet can remain idle because there is nothing to hold.

## Integration with the Mechanistic Framework

### Connection to [Taste Compilation](/wiki/taste-compilation)

Judgment supplies $j$, and capture into the bundle supplies $c$. Writing back after each selection event preserves the verdict for later generations. "The system ratchets instead of resets" describes this law applied to a generation pipeline.

### Connection to [Prevention Architecture](/wiki/prevention-architecture) and [Forcing Functions](/wiki/forcing-functions)

Prevention blocks entry into a bad state; retention blocks departure from a good one. Both depend on enforcement. The hierarchy in forcing functions determines how reliably a boundary takes effect, and a lock is only as strong as that enforcement.

### Connection to [Accrual Substrate](/wiki/accrual-substrate)

An append-only, monotone record applies retention to observations. Once information is captured, it never has to be derived again, so the substrate's retained floor rises as it accumulates.

### Connection to [Macrostate Engineering](/wiki/macrostate-engineering)

An intermediate ideal state is a macrostate that has been reached and can be held. A sequence of such states breaks an otherwise unreachable destination into configurations that can be reached and retained one at a time.

### Connection to [Structure over Request](/wiki/structure-over-request)

A correction that "ratchets into machinery" replaces a request with an enforced structure. Validation on the write path is the limiting case: forgetting to retain the correction has no permitted encoding.

### Connection to [Discipline](/wiki/discipline) and [30x30 Pattern](/wiki/30x30-pattern)

A routine practiced to automaticity stores the gain in neural tissue. Because it no longer needs deliberation, a low-willpower day cannot take it away. The habit performs the retention function that the pawl performs in the mechanical ratchet.

### Connection to [Basin](/wiki/basin)

A complete pursuit system needs both collection and retention. The basin gathers material toward the goal; the ratchet preserves gains made while pursuing it. Success at one does not guarantee success at the other.

## See Also

- [Taste Compilation](/wiki/taste-compilation) applies the retention inequality to judgment.
- [Lockfile](/wiki/lockfile) makes a judgment lock into a versioned, forkable artifact.
- [Prevention Architecture](/wiki/prevention-architecture) blocks entry into bad states.
- [Forcing Functions](/wiki/forcing-functions) describes the enforcement on which locks depend.
- [Accrual Substrate](/wiki/accrual-substrate) applies monotone retention to captured data.
- [Macrostate Engineering](/wiki/macrostate-engineering) supplies the account of holdable intermediate configurations.
- [Intelligence Is Water](/wiki/intelligence-is-water) describes how a lock reduces accessible microstates.
- [Structure over Request](/wiki/structure-over-request) builds retention into permitted operations.
- [State Machines](/wiki/state-machines) represents locks as removed transitions.
- [Selection over Design](/wiki/selection-over-design) explains why candidate locks are tested before being retained.
- [Discipline](/wiki/discipline) develops the automatic-routine account.
- [30x30 Pattern](/wiki/30x30-pattern) describes how repeated routines become cached.
- [Basin](/wiki/basin) distinguishes collecting toward a goal from retaining a gain.
- [Error Signal](/wiki/error-signal) describes the loop that produces a gain; a lock keeps the closed error from needing to be paid for again.

Progress requires both closing an error and keeping it closed. The next search is useful because it begins above the floor that the previous one secured.