> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# one-way-ratchet
> A doctrine that guarantees correctness via monotonic growth (always-add, never-remove) — and therefore requires a counter-doctrine for periodic prune-down to prevent unbounded accumulation.
computer-science public-policy
# One way ratchet
## Description
A doctrine that guarantees a desirable property (correctness, completeness, safety, auditability) by mandating monotonic growth: always add, never remove. The doctrine works locally — every addition is justified, every preservation is safe — but the system accumulates unboundedly over time. Without a paired pruning counter-doctrine (always-add + periodic-cull = stable system), the ratchet eventually produces bloat, slowness, or maintenance pressure that exceeds the doctrine's original value.
The concept picks out a specific failure mode of correctness-first design: rules that are individually right but collectively produce the wrong shape because they lack a counter-rule. The diagnostic question — *"if we never stopped adding, would the system stay useful?"* — distinguishes one-way-ratchets that need counter-doctrines from genuinely-bounded accumulation (where natural turnover or external pressure does the pruning automatically).
## Triggers
**User-initiated:** User describes a system that has accumulated cruft, bloat, or unmanageable size despite each individual addition being justified. Vocabulary cues: "ratchet," "monotonic," "always add," "never delete," "rot," "bloat," "cruft."
**Agent-initiated:** Agent notices a doctrine that produces monotonic growth, asks "what's the counter-doctrine?", and finds none. Candidate inference: "this needs a paired pruning rule, not just a sunsetting hope."
**Situation-shape signals:** Doctrines articulated as "always X" or "never not-X." Slow CI, slow startup times, large config files, deep dependency trees. "We can't tell what's still needed" rhetoric.
## Exclusions
* **Natural turnover** — biological systems with cellular replacement, populations with births + deaths, codebases with employee turnover: the prune happens without explicit doctrine.
* **External pressure that prunes** — markets remove failing products; users remove tools they don't use; the system has implicit pruning even without internal counter-doctrine.
* **Truly bounded resources** — when storage or computation is finite and binding, the system can't ratchet unboundedly; the constraint forces selection.
* **Append-only is the right shape** — git history, audit logs, scientific publications. The concept would mislead if applied to systems where monotonic growth is the design point, not the failure mode.
## Structure
## Relationships
* [doctrine](/concepts/doctrine) — the correctness rule is a doctrine; the counter-rule is also a doctrine. The pair is what stabilizes the ratchet.
* [graduation-promotion](/concepts/graduation-promotion) — graduation is a one-way ratchet by default (promotion without demotion produces accumulation); explicit demotion is the counter-doctrine.
* [asymmetric-gate](/concepts/asymmetric-gate) — one-way-ratchet is the limiting case of asymmetric-gate.
* [hysteresis](/concepts/hysteresis) — ratchets produce hysteresis: state depends on full history, reversal requires explicit work.
* [cargo-cult](/concepts/cargo-cult) — copying the add-doctrine without the prune-doctrine is a canonical cargo-cult instance ("we test like Google does!" — without Google's culling discipline).
## Examples
"always pass new rules to fix this incident" without a sunset-clause counter-doctrine produces regulatory accretion that strangles the original purpose.
"always add, never remove dependencies" produces NPM-pocalypse; the counter-doctrine is dependency-pruning passes.
"never delete a backup" without a counter-doctrine produces unmanageable archives.
"we never remove config flags" leaves cruft that nobody understands; the counter-doctrine is a periodic "what's actually used?" audit.
Manny Lehman's longitudinal studies of large software systems through the 1970s — most famously OS/360 at IBM — produced a set of empirically observed regularities he formulated as "laws of software evolution." The 1980 statement was empirical rather than prescriptive: Lehman wasn't recommending growth, he was reporting that he could not find systems-in-active-use that escaped it.
Three of Lehman's eight laws line up directly with the one-way-ratchet structure. **Law VI — Continuing Growth** states that the functional content of an E-type (evolving) system must continually increase to maintain user satisfaction over the system's lifetime; users adapt to the system, push its boundaries, and surface new requirements that compound. **Law VII — Declining Quality** states that the perceived quality of an E-type system will appear to be declining unless rigorous adaptation and evolution effort is expended to compensate; complexity grows and the system drifts toward unmaintainability. **Law III — Self-Regulation** is the structural counterweight: the evolution process is self-regulating, with measurable trends and statistical regularities — meaning organizations *do* respond, via release-cadence discipline, refactoring cycles, and resource allocation, even when no one named the doctrine explicitly. (Related laws — Continuing Change and Increasing Complexity — capture adjacent facets: features added are locally justified, and the aggregate is monotonic growth with declining quality unless complexity-management work happens.)
**Inference**: Read together, the three laws describe a ratchet that is sometimes balanced by an unnamed counter-rule and sometimes is not. The systems that escape Lehman's quality-decline trajectory are the ones in which the self-regulation step is explicit — periodic complexity-pruning, dependency-pruning, test-suite pruning — rather than implicit. The diagnostic for any long-running codebase: are Continuing Growth (Law VI) and Declining Quality (Law VII) being balanced by a named, scheduled, observable Self-Regulation move (Law III)? If the answer is "we hope to refactor eventually," the ratchet is unbalanced and the decline is on the books.
"always log, never lose" exhausts storage; log rotation is the counter-doctrine.
"always add a comment when reviewing" + no counter-doctrine produces noise that drowns signal.
Martin Fowler's *Refactoring* (1999) named the prune-doctrine that has to exist alongside the ordinary build-doctrine for a codebase to remain workable. Without an explicit refactoring practice, software is a one-way ratchet: every correctness-driven addition (a defensive check, a special case, a defensive abstraction) is monotonically retained because no actor is incentivized to prune it. Each retention is locally correct; the accumulated mass is what becomes the problem.
**Inference**: Any system whose correctness incentive points only toward addition needs a paired pruning incentive to stabilize. The diagnostic transfers to test suites, configuration files, log retention policies, dependency lists, government regulations, and concepts catalogs — wherever the local-correctness reasoning is asymmetric, the global mass grows without a counter-doctrine.
"we never delete tests" produces a slow CI that nobody trusts; the counter-doctrine is quarterly test-relevance review.