Feedback Loops

intent

a system has a feedback loop when its output circles back as input to the next cycle. reinforcing loops amplify (compound interest, viral growth, bank runs, death spirals). balancing loops self-correct (thermostats, price discovery, immune response). the killer is delay: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot. operators then systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0, 1 scale).

use this skill when: system shows nonlinear surprise (collapse, oscillation, death spiral, growth flywheel); you're intervening in a complex system and success depends on how it responds; trends aren't extrapolating well; bullwhip or oscillation appears in any quantity that should be steady; a capex/AI-adoption flywheel is compounding and you need to know when balancing limits (power, supply, cost, AI-native competition) will bite and whether it will overshoot.

do not use when: decision is one-shot linear with no feedback to future decisions; insufficient data to map loops (hand-waving without structure); decision is too time-bounded for delays to matter; exogenous shock dominates internal dynamics obviously.

inputs

• concrete system case: name of org, market, supply chain, or product where you observe oscillation, collapse, or surprise behavior. if no case, trigger coach mode (see procedure, step 1).
• variable of interest: the specific output you're tracking (inventory, hiring, price, user growth, margin, etc.). without this, analysis becomes vague narrative.
• observed behavior pattern: recent trend data, timeseries, or narrative description (e.g., "revenue grew 3 years, then collapsed in 6 months").
• intervention plan (optional): what you're considering changing (policy, process, parameter, investment). needed to stress-test against system response.
• historical data or domain knowledge: rough magnitude of key delays (procurement cycle, hiring ramp, feedback perception lag). if unavailable, make assumptions explicit.
• external systems or dependencies: supply-chain partners, market competitors, regulatory bodies, technology platforms. these often house hidden reinforcing or balancing loops.

no external API or database connections required. this is a structural diagnosis tool, not a data-fetching tool.

procedure

step 1: determine mode (engine vs. coach)

• input: user's request and concreteness level.
• output: mode assignment.
• if user brings a concrete case with variable of interest, run engine mode (step 2 onward).
• if user is unfamiliar with feedback loops or has no concrete case, run coach mode: ask one diagnostic question, stop, wait for response before advancing. repeat for steps 3, 4, 5. do not lecture.

step 2: name system and variable of interest

• input: case description from user.
• output: one-line system statement and one-line variable statement.
• example: "system = Acme supply chain inventory management; variable = days of inventory on hand (DIOH)."
• if vague, push back: "what specific number are you trying to predict or control?"

step 3: list drivers and outputs

• input: system boundaries identified in step 2.
• output: two lists: drivers (inputs to your variable), outputs (what your variable changes in turn).
• drivers for DIOH: order-forecast error, lead time, demand signal, production capacity.
• outputs of DIOH: carrying cost, stockout risk, cash flow, buying decisions.
• stay concrete. no generic "market forces."

step 4: identify loops

• input: drivers and outputs from step 3.
• output: causal chains where a variable feeds back to itself. list each loop separately (R1, R2, B1, B2, etc.).
• example: DIOH high → carrying cost up → pressure to reduce orders → forecast error grows → DIOH stays high (R loop). DIOH low → stockout risk → expedited orders → procurement cost up → margin pressure (R loop). Price high → demand down → inventory accumulates → price discount (B loop).
• trace by hand. no algorithm. if you find >5 loops, focus on dominant ones (step 6).

step 5: classify each loop (R or B)

• input: each causal chain from step 4.
• output: R or B label and reasoning (sign count).
• count negative signs in the chain. even number of negatives or all positives = reinforcing (R). odd number of negatives = balancing (B).
• example: "A up → B down (negative) → C down (positive) → A up (negative). two negatives: B loop."
• sign count is mechanical. do it on paper if needed. wrong classification breaks everything downstream.

step 6: locate delays

• input: each causal chain from steps 4 and 5.
• output: where delays occur and rough magnitude (hours, days, weeks, months, years).
• delays are where intuition fails. examples: procurement lead time (weeks), hiring ramp (months), market perception lag (quarters), technology capability build (years), balancing feedback from market price (minutes to days, rarely longer).
• for each delay, ask: "how long from cause to observable effect?"
• if delay is irreducible, model it explicitly. do not pretend to reduce it.

step 7: identify dominant loop

• input: all loops, their classification, delays, and observed behavior pattern from step 1.
• output: which loop (R1, B1, etc.) is driving current behavior and why.
• in growth phase: R dominant. in maturity or overshoot: B catching up. in crisis or collapse: suppressed R taking over.
• check: predicted behavior from dominant loop must match observed trend. if not, re-classify or find missed loop.
• example: "observed: inventory oscillation with 8-week cycle. dominant loop: B loop with 4-week delay, producing 2-cycle overshoot."

step 8: map stocks and flows

• input: causal chains and variable definitions from step 2.
• output: identify which elements are stocks (accumulations: inventory, headcount, debt) and which are flows (rates: hiring, orders, spending).
• critical error: "higher hiring rate" ≠ "we have enough people." hiring is a flow; headcount is a stock. check both.
• for your variable, is it a stock or flow? if stock, what inflows and outflows feed it?
• example: "DIOH is a stock (inventory on hand). inflows = production rate + incoming shipments. outflows = sales rate."

step 9: predict behavior pattern

• input: dominant loop (R or B), delays, stocks, flows.
• output: expected trajectory without intervention (exponential, oscillation, S-curve, equilibrium, collapse).
• pure R, short delay: exponential growth or collapse.
• pure B, no delay: equilibrium, stable.
• pure B, long delay: oscillation and overshoot (cobweb cycle, bullwhip).
• R + B, competing: S-curve (see s-curve-technology-adoption skill).
• mismatch between predicted and observed = missed loop or misclassified loop. re-run step 4.

step 10: identify leverage (Meadows hierarchy)

• input: dominant loop, stocks, flows, delays.
• output: ranked list of intervention points, lowest to highest leverage.
• meadows hierarchy: parameters (knobs, bonuses, targets, metrics) → buffers (inventory, cash, slack) → information structures (what signals reach decision-makers) → decision rules (policies, thresholds) → delays (lead times, feedback cycles) → balancing loop strength (reinforcement of self-correction) → reinforcing loop dominance (which growth loop wins) → goals (what the system optimizes for) → paradigm (deep belief about how the world works).
• lowest leverage: tweak a parameter (bonus, target, metric). usually fails; system fights back via balancing loops.
• higher leverage: shorten a delay, add a buffer, change who sees what signal.
• highest leverage: alter the goal or paradigm the system optimizes for. rare. most powerful.
• example: "low: raise DIOH target. medium: share end-demand signal with suppliers (shorten feedback delay). high: shift from 'maximize utilization' to 'minimize lead time variability'."

step 11: stress-test intervention against system response

• input: proposed intervention, dominant loop, balancing and reinforcing loops.
• output: predicted system response, backfire risk, and falsifier.
• balancing loops fight back: suppress a symptom, the loop compensates elsewhere.
• reinforcing loops restore trajectory: push one parameter, the loop re-amplifies via other channels.
• example: "intervention: cut inventory target by 20%. system response: suppliers tighten delivery windows, stockouts rise, expedite costs spike, margin loss offsets inventory savings. backfire risk: high. falsifier: if expedite costs don't rise or stockouts don't increase, diagnosis is wrong."
• if intervention is structural (not parameter-level), backfire risk is lower.

step 12: document diagnosis output

• input: all prior steps.
• output: structured diagnosis record (see output contract).

decision points

if user has a concrete case with variable, then run engine mode (steps 2, 12 directly).

else if user is unfamiliar or has no concrete case, then run coach mode: ask step 3 question (what specific behavior do you see right now?), wait for response, advance. repeat for steps 4 and 5. do not lecture or explain theory before user responds.

if observed behavior does NOT match predicted behavior from dominant loop, then re-run step 4 (identify loops) or step 5 (classify). do not proceed to step 10 until match is found.

if intervention is purely parameter-level (bonus, target, metric), then escalate to step 10 and propose structural alternative at higher leverage.

if stocks and flows are not explicitly separated, then request clarification before proceeding. conflating them is a common failure mode (Sterman 1989).

if delays are hand-waved ("supply chain delays") rather than sized, then require rough magnitude (days, weeks, months) or mark as assumption and sensitivity-test the diagnosis.

if more than 5 loops are identified, then rank by impact (does this loop show up in the timeseries?) and focus on top 2, 3. secondary loops can be noted but not analyzed in full.

if balancing loop is caught in a death spiral (e.g., price falls, demand doesn't rise, margin falls further, price falls again), then note that death spirals are reinforcing loops disguised as balancing loops. reclassify and find the structural circuit-breaker (price floor, subsidy, capacity reduction, etc.).

output contract

feedback-loop diagnosis report

format: structured plain text or markdown.

required fields:

system / variable:
  [name of system and the specific output being tracked]

loops identified:
  R1: [causal chain, e.g., "demand up → production up → hire → capacity up → cost down → price down → demand up"]
  R2: [if present]
  B1: [causal chain, e.g., "inventory high → carrying cost up → price cut → demand up → sales up → inventory down"]
  B2: [if present]

delays:
  [location]: [rough magnitude, e.g., "procurement lead time: 6 weeks" or "market perception of price change: 2, 4 weeks"]

dominant loop:
  [R1 or B1, etc.]: [brief explanation of why it dominates in current phase]
  [predicted behavior from this loop and rough timeframe, e.g., "oscillation with 8, 10 week cycle"]
  [observed behavior]: [match? or mismatch indicating missed loop?]

stocks and flows:
  stocks: [list, e.g., "inventory on hand, headcount, debt balance"]
  flows: [list, e.g., "hiring rate, production rate, ordering rate"]

predicted behavior without intervention:
  [trajectory: growth / collapse / oscillation / equilibrium]
  [timescale: weeks / months / years]
  [saturation point or tipping point, if relevant]

leverage points (meadows hierarchy):
  lowest (parameters): [knobs that don't work; why]
  medium (delays, buffers, information): [structural levers; why they work better]
  highest (goals, paradigm): [what would need to shift; is it feasible?]

intervention: [your proposed move]
  system response: [how balancing/reinforcing loops will react]
  backfire risk: [high / medium / low; why]
  structural vs. parameter: [which type]

falsifier:
  [observable outcome that would prove the diagnosis wrong, e.g., "if expedite costs don't rise when inventory is cut, the cost-feedback loop doesn't exist"]

file location: in your working doc, issue tracker, or slide deck , wherever the decision-maker sees it. not a separate artifact.

completeness check:

• system and variable named clearly
• at least one R and one B loop identified with full causal chains
• delays sized with rough magnitudes
• dominant loop identified and predicted behavior matches observed (or mismatch noted and investigated)
• stocks and flows distinguished
• leverage recommendation is not lowest-level parameter adjustment (unless structural alternatives are unavailable)
• system response to intervention spelled out
• falsifier is observable and specific, not vague

outcome signal

the skill worked if:

• you stopped extrapolating trends in a feedback system. feedback systems switch regime when dominant loop changes. recent trend ≠ baseline for prediction.
• you identified where your intuition will fail. delays are the culprit. if you name them, you've found the shock.
• you stopped proposing "be more careful" or exhortation. identical structures produce identical dysfunction (Sterman 1989). if your recommendation is still parameter-level, you didn't move up the meadows hierarchy.
• you can predict how the system will fight back. balancing loops resist suppression; reinforcing loops restore trajectory. if you can't name the system response, diagnosis is incomplete.
• your intervention recommendation is structural, not symptomatic. shorten a delay, change who sees what signal, shift the goal, build a circuit-breaker. not "raise the bonus."
• you have a falsifier. you named one observable outcome that would prove the diagnosis wrong. if behavior doesn't match, you know where to re-investigate.
• the decision-maker stops fighting the feedback loop and starts working with it. death spirals become design problems. growth flywheels become transition-planning problems. oscillation becomes a delay-management problem. that's the shift.

---

method in action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement (examples/forresters-beer-distribution-game-stermans-1989-measurement.md)

2026 lens: The AI Capex Boom as a Reinforcing Loop Meeting Its Balancing Limits (2024, 2026) (examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md)

---

loop patterns pack

R growth: network effects, viral k>1, compounding learning curves. risk: hits a balancing limit you don't control.

R collapse: death spirals, bank runs, adverse selection cascades. defense: structural circuit breakers, fast intervention.

B working: market price discovery, wages, thermostats. don't suppress healthy balancing loops.

B + long delay → oscillation: bullwhip, cobweb cycles, capacity build-out. defense: shorten delays, damp response, share end-demand data.

R + B → S-curve: technology adoption. see s-curve-technology-adoption skill. to extend growth, kick off a second R loop before the first saturates.

---

common rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

fake move	reality
[D] "just be more careful or disciplined"	identical structures produce identical dysfunction regardless of who operates them (Sterman 1989). exhortation is marginal; structural redesign is real.
[D] treating delay as friction to reduce rather than structural feature to model	many delays are irreducible. for those, model explicitly. don't pretend to reduce them.
[D] extrapolating recent trends in a feedback system	feedback systems switch regime when dominant loop changes. recent observations are loop outputs, not reliable baselines.
[D] confusing stocks and flows	"higher hiring rate" ≠ "enough people." flow ≠ stock. check both.
[D] "it's the market or external event"	often operators created the variability themselves (Sterman's subjects blamed constant demand). check internal generators first.
[D] parameter adjustment when structure is the problem	"raise the bonus or add a metric" = noise in a structurally-driven system. move up the meadows hierarchy.
[D] "death spiral = inevitable doom"	death spirals are loops with modifiable structural components. find the most modifiable arrow.
[D] "let's push harder on the growth loop"	leverage is in understanding what balancing loop catches up and when, not in pushing parameters harder.
[O] add observations here after real use , paste the actual failure pattern and what went wrong	what went wrong and why

---

red flags

• trends extrapolated in a feedback-driven system
• oscillation blamed on external variability without checking internal loop generators
• intervention at parameter level when loop structure is the source
• "be more careful" proposed in a forrester-adversarial structure
• stocks and flows confused
• death spiral or growth narrative with no loops, nodes, or delays specified
• all interventions at lowest (parameter) leverage level

---

verification checklist

• system and variable named
• at least one R and one B loop identified with full causal chain
• each loop classified by sign-counting (even negatives = R; odd = B)
• delays identified with rough magnitudes
• dominant loop identified; observed behavior consistent with predicted behavior
• stocks and flows distinguished
• predicted behavior matches actual (if not, re-classify or find missed loop)
• leverage points ranked; recommendation not at lowest level if higher leverage is accessible
• system response to intervention considered
• observable falsifier named

---

primary sources: see references/sources.md

composes with: `