The symptom wall
Welcome to Meridia, a mid-size city of about 600,000. (It is hypothetical — a stand-in for every system you will ever be handed.) The dashboard is lit up red. Read the wall first. Each tile is a symptom: something you can see and measure. None of them is the disease.
Median rent, 3 years
Two-bed apartments up from $1,450 to about $2,000.
Average commute
The council’s stated target is 30 minutes. It is going the wrong way.
Re-congested in 9 months
The Harbor Road was widened from 4 to 6 lanes. Traffic is back to where it started.
Downtown transit ridership
Falling, even as more people commute by car.
The tempting move is to attack each tile directly: cap the rent, widen another road, cut the “underused” bus line. An AI optimiser pointed at any single tile will do exactly that, fast. But these four tiles are not four problems — they are four readings off one hidden structure of stocks, flows, delays, and feedback loops. Diagnose the structure, not the symptom.
Symptom or underlying structure?
This is the foundational discrimination. A symptom is a surface reading you can point at on the dashboard. An underlying structure is a stock, a flow, a delay, or a feedback loop that produces those readings over time. Click each statement to move it between bins, then check.
Name the loop, then mind the delay
Every structure under Meridia is a feedback loop of one of two kinds. A reinforcing loop (R) amplifies itself — more leads to more, a vicious or virtuous cycle. A balancing loop (B) pushes back toward a goal — it resists change and seeks equilibrium. Click a dynamic on the left, then the label-plus-consequence on the right that fits it. Link all four, then check.
Mind the delay
The council finally approves 2,000 new homes — enough to genuinely ease the shortage. Here is the question that breaks most decision-makers: from the day approval is signed, how many months until renters actually feel rents stabilise? Drag to your best guess, then reveal the true curve.
Run the system: the overshoot trap
You are now Meridia’s transport chief. The commute is 45 minutes; the target is 30. Each round you set one control: how much road capacity to add (or remove). Here is the cruel part — capacity you add this round only takes effect next round (construction delay), and every time roads feel faster, induced demand pulls more cars on until they fill up again. Slam the lever and you will watch the meter overshoot past the target and rebound the wrong way. Drive for five rounds.
Round 1: set the road-capacity lever
Pick how aggressively to change capacity this round. Remember the one-round build delay and induced demand.
Trace the ripple
1. Spot the hidden loop
Here is the causal-loop diagram the council used to justify widening the Harbor Road. It treats widening as a simple open chain that ends in “shorter commute.” That is exactly why the road re-congested in nine months. Click the two links that are missing or wrong — the ones that, once added, turn this open chain into the induced-demand balancing loop that erased the gain. Then check.
The council’s model (click the broken/missing links):
2. Pick an intervention — watch the ripple
The mayor wants one intervention on Meridia, funded now. Pick one and watch its first-, second-, and third-order ripples unfold — then try the others. The meter shows where the commute lands 18 months later. It can move the wrong way.
Climb the leverage ladder
1. Which lever is stronger?
Two proposals land on the mayor’s desk, both aimed at the commute. One tweaks a number inside the existing system. One changes what the system is for. Pick the higher-leverage intervention — then check your reasoning.
2. Order the leverage ladder
Donella Meadows ranked the places to intervene in a system from weakest to strongest. The surprise: the levers that are easiest to reach and argue about — fees, buffers, numbers — are the weakest. Order these six Meridia interventions from weakest leverage (top) to strongest (bottom), then check.
3. Find the wrong-direction push
Meadows’ deepest warning: people often find the high-leverage point — and then push it the wrong way, “with a great deal of enthusiasm.” Here are six items on Meridia’s budget. Select every one that aims at a real leverage point but shoves it in the wrong direction (making the system worse). The skill is exhaustiveness.
Design the intervention, then carry it out
1. Build a counter-loop
Now you design the intervention package. Toggle structural elements on and off and watch the system-health meter respond. Structural moves — adding a balancing loop, shortening a delay, changing the goal — lift it. Parameter tweaks barely move it, and one seductive option lowers it: feeding the reinforcing sprawl loop. The meter can fall.
2. Your diagnosis — a fresh system
New case, same moves. Read it, then write three things: the loop driving it, the archetype it matches, and the highest-leverage move — not the obvious one. Then self-assess against the checklist and compare with a model answer.
The case
A SaaS support team is drowning. Tickets keep climbing, so the manager keeps hiring more agents. Each new hire helps for a few weeks, then the backlog is worse than before. Meanwhile the engineering team — whose buggy releases generate most of the tickets — is fully booked shipping new features, and an AI assistant has been deployed to auto-close tickets faster, which nudges the close-rate KPI up nicely.
A strong model diagnosis
Loop: Buggy releases → more tickets → team copes by hiring agents and auto-closing → the pain is masked, so engineering is never forced to fix the root cause → bugs (and tickets) keep growing. The coping flow even has a delay: each hire helps briefly, then the rising inflow overwhelms it again.
Archetype: Shifting the Burden (with a dash of Fixes That Fail). The symptomatic fix — more agents, faster auto-close — relieves pressure but quietly atrophies the fundamental fix (shipping fewer bugs). The AI auto-closer is the trap: it optimises a symptom KPI and removes the very signal that would push engineering to act.
Highest-leverage move: Change the goal/feedback, not the staffing parameter. Route ticket root-cause data straight into engineering’s priorities and make “defects escaping to support” a metric they own — so the inflow gets fixed at source. Hiring and auto-close treat the backlog stock; only closing the bug-inflow drains the bathtub.
3. Carry it out
The whole point of the Ripple Room is what happens after you leave it. Here is your protocol on a card — then name one system in your own work where an AI or a KPI is busily optimising a symptom, and state the higher-leverage point it’s missing.
The Ripple Room protocol
You’ve read the structure.
You sorted symptom from structure, named the loops, felt a delayed system overshoot and swing the wrong way, traced an intervention’s ripples three orders deep, and ranked your levers the way Meadows did. That is the judgment layer AI can’t supply — deciding which lever the automation should pull, and in which direction.