FrameworkLevel 7 · EmergenceWorlds & loops
Compounds Or Rots
Any system that feeds its own output back into itself is on one of two trajectories. The fork is a single property, and most systems default to the wrong one.
The shape
Any system that runs continuously and feeds its own outputs back into itself is on exactly one of two trajectories — and they start from the same place:
- The rotting loop. It acts on a partial view, hides its own side effects, lets the record of what it is drift away from what it actually does, and so every future action is less informed than the last. Documentation goes stale, hidden couplings break silently, the next actor trusts a surface that's no longer true. It decays, invisibly, while looking busy.
- The compounding loop. It observes its own effects, repairs the surfaces that describe it, and so every future action is more informed than the last. Each pass makes the system more self-readable, which makes the next pass safer, which makes the system extend rather than merely survive.
The fork between them is a single property: does the loop make itself more self-readable over time, or less? Compounding systems repair their own observability as a first-class activity. Rotting systems treat it as something to do later, and "later" never comes.
Two corollaries ride along:
- Boundaries should learn, not just block. A system that survives contact with the world runs a membrane — recognize what's arriving, evaluate whether it belongs, admit or reject, and refine from each decision. A wall that only blocks can't adapt; an absent boundary drowns. The learning step is what makes the boundary alive.
- The engine is one thing at different resolutions. The way you think, the way your system runs that thinking, the artifacts it produces, and the things it teaches are not separate — they're the same structure compiled at different levels. Which is why a compounding loop's outputs become the raw material for its next turn.
Why it matters
This is the difference between a system that gets better the more it's used and one that gets worse the more it's used — and most systems, left alone, rot. The rot is silent: every individual action seems fine, the decay only shows up downstream, and by the time anyone notices, the cause is buried. "We added AI and at first it helped, then everything got weirdly fragile" is the rotting loop. So is the codebase nobody can change anymore, and the team whose institutional knowledge evaporates every time someone leaves.
The reframe: you don't get a compounding system by having smart parts. You get it by making the loop repair its own self-description every cycle — and you get a rotting one by skipping exactly that. The choice is structural and it's made (or defaulted on) every single pass.
How to think with it
- For any system you run, ask: after each cycle, is it more self-readable or less? Does it know more about itself, or has its self-description drifted from reality?
- Find where the record drifts from the truth — the stale doc, the hidden coupling, the "only so-and-so knows how this works." Those are the rot points. A compounding loop repairs them as part of the work, not as a someday task.
- Check your boundaries: are they walls (block everything, can't adapt), absent (admit everything, drown), or membranes (selectively admit and learn from each decision)? Only the membrane compounds.
- Treat the loop's outputs as inputs. If what the system produces doesn't feed back to make the next cycle richer, you have activity, not compounding.
Honest caveat. What this doesn't cover: the machinery that performs the repair automatically — detecting hidden effects and patching the surfaces that describe them without a human remembering. That's what the engine does; this is the idea it implements.
Distilled from: seven disciplines · l7 emergence · docmagic stack · blanket · composition · holographic work