{"id":"ff66547c-dc32-4d8f-978b-0041d5d72a50","entityType":"agent","slug":"clawhub-deciqai-feedback-loops","name":"Feedback Loops","canonicalUrl":"https://www.xpersona.co/agent/clawhub-deciqai-feedback-loops","canonicalPath":"/agent/clawhub-deciqai-feedback-loops","generatedAt":"2026-10-11T04:34:00.921Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":null},"description":"Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"... Skill: Feedback Loops Owner: deciqai Summary: Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T17:59:42.787Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/feedback-loops.json) v1.0.4 | 2026-07-09T11:17:30.887Z | us","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:feedback-loops","sourceUrl":"https://clawhub.ai/deciqai/feedback-loops","homepage":"https://clawhub.ai/deciqai/skills/feedback-loops","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/deciqai/feedback-loops","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/deciqai/skills/feedback-loops","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":null},"stars":null,"forks":null,"downloads":1188,"packageName":null,"latestVersion":"1.0.5","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T02:30:20.618Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T02:30:20.692Z","lastCrawledAt":"2026-10-11T02:30:20.618Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T02:30:20.618Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.5","createdAt":"2026-07-16T17:59:42.787Z","changelog":"Description tail link + agents machine-readable metadata line (deciqai.com/s/feedback-loops.json)","fileCount":6,"zipByteSize":18972},{"version":"1.0.4","createdAt":"2026-07-09T11:17:30.887Z","changelog":"Refresh: 2024-2026 AI-era worked examples added (strategy/leadership + systems/game-theory batch)","fileCount":6,"zipByteSize":19023},{"version":"1.0.3","createdAt":"2026-07-08T11:02:28.043Z","changelog":"Footer now uses /c/<slug> short link (fixes UTM truncation when SKILL.md is read in a terminal)","fileCount":5,"zipByteSize":12338},{"version":"1.0.2","createdAt":"2026-07-08T00:47:49.411Z","changelog":"Refreshed content + GitHub star link in footer","fileCount":5,"zipByteSize":12316},{"version":"1.0.1","createdAt":"2026-07-07T20:33:08.705Z","changelog":"Add catalog categories and topics","fileCount":5,"zipByteSize":12460},{"version":"1.0.0","createdAt":"2026-06-28T09:17:10.897Z","changelog":"Initial publish","fileCount":5,"zipByteSize":12223}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17a4mqcnk515kvaca5ze55d0x88pfpx:feedback-loops","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T04:34:00.916Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-deciqai-feedback-loops/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":null},"readme":"Skill: Feedback Loops\n\nOwner: deciqai\n\nSummary: Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"...\n\nTags: latest:1.0.5\n\nVersion history:\n\nv1.0.5 | 2026-07-16T17:59:42.787Z | user\n\nDescription tail link + agents machine-readable metadata line (deciqai.com/s/feedback-loops.json)\n\nv1.0.4 | 2026-07-09T11:17:30.887Z | user\n\nRefresh: 2024-2026 AI-era worked examples added (strategy/leadership + systems/game-theory batch)\n\nv1.0.3 | 2026-07-08T11:02:28.043Z | user\n\nFooter now uses /c/<slug> short link (fixes UTM truncation when SKILL.md is read in a terminal)\n\nv1.0.2 | 2026-07-08T00:47:49.411Z | user\n\nRefreshed content + GitHub star link in footer\n\nv1.0.1 | 2026-07-07T20:33:08.705Z | user\n\nAdd catalog categories and topics\n\nv1.0.0 | 2026-06-28T09:17:10.897Z | user\n\nInitial publish\n\nArchive index:\n\nArchive v1.0.5: 6 files, 18972 bytes\n\nFiles: examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md (12612b), examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (3556b), skill-card.md (2687b), SKILL.md (9256b), _meta.json (133b)\n\nFile v1.0.5:SKILL.md\n\n---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n  More: deciqai.com/c/feedback-loops\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: `second-order-thinking` · `s-curve-technology-adoption` · `prisoners-dilemma` · `probabilistic-thinking`\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady; a capex/AI-adoption flywheel is compounding and you need to know when the balancing limits (power, supply, cost, AI-native competition) will bite and whether it will overshoot.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage point uncovered and why it is higher than a parameter fix.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Feedback-Loop Diagnosis** — map structure, find dominant loop, predict behavior, find leverage.\n\n1. **Name system + variable of interest.** Without a specific variable, analysis becomes vague narrative.\n2. **List drivers and outputs.** What inputs change your variable? What does it change in turn? Stay concrete.\n3. **Identify loops.** Trace chains where a variable feeds back to itself. Most systems have several.\n4. **Classify each loop (R or B).** Count negative signs around the loop — even = reinforcing; odd = balancing.\n5. **Locate delays.** Where does a cause take significant time to produce its effect? Delays are where intuition fails.\n6. **Identify dominant loop.** Growth phase = R dominant; maturity = B catching up; crisis = suppressed R taking over.\n7. **Map stocks and flows.** Stocks = accumulations; flows = rates. A positive flow can still leave a stock dangerously low.\n8. **Predict behavior pattern.** Pure R → exponential growth/collapse. Pure B → equilibrium. R+delay → overshoot/oscillation. R+B competing → S-curve. Mismatch with observed behavior = missed loop.\n9. **Find leverage (Meadows hierarchy).** Parameters → buffers → structures → delays → balancing loops → reinforcing loops → goals → paradigm. Most failed interventions push parameters; move up.\n10. **Stress-test against system response.** Balancing loops fight back; reinforcing loops restore trajectory. Intervention must change structure, not just symptom.\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>\n```\n\n*→ Method in Action: [Forrester's Beer Distribution Game & Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md)*\n\n*→ 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)*\n\n## Pack: Loop Patterns\n\n- **R growth:** network effects, viral k>1, compounding learning curves. Risk: hits a balancing limit you don't control.\n- **R collapse:** death spirals, bank runs, adverse selection cascades. Defense: structural circuit breakers, fast intervention.\n- **B working:** market price discovery, wages, thermostats. Don't suppress healthy balancing loops.\n- **B + long delay → oscillation:** bullwhip, cobweb cycles, capacity build-out. Defense: shorten delays, damp response, share end-demand data.\n- **R + B → S-curve:** technology adoption. See `s-curve-technology-adoption`. To extend growth, kick off a second R loop before the first saturates.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] \"Just be more careful / disciplined\" | Identical structures produce similar dysfunction regardless of who operates them (Sterman 1989). Exhortation = marginal; structural redesign = real. |\n| [D] Treating delay as friction to reduce rather than a structural feature to model | Many delays are irreducible. For those, model them explicitly — don't pretend to reduce them. |\n| [D] Extrapolating recent trends in a feedback system | Feedback systems switch regime when dominant loop changes; recent observations are loop outputs, not reliable baselines. |\n| [D] Confusing stocks and flows | \"Higher hiring rate\" ≠ \"enough people.\" Flow ≠ stock. Check both. |\n| [D] \"It's the market / external event\" | Often the operators created the variability themselves (Sterman's subjects blamed constant demand). Check internal generators first. |\n| [D] Parameter adjustment when structure is the problem | \"Raise the bonus / add a metric\" = noise in a structurally-driven system. Move up the Meadows hierarchy. |\n| [D] \"Death spiral = inevitable doom\" | Death spirals are loops with modifiable structural components. Find the most modifiable arrow. |\n| [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. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- 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 loop/nodes/delays specified · All interventions at lowest (parameter) leverage level\n\n## Verification\n\n- [ ] System and variable named · At least one R and B loop identified with causal chain · Each loop classified by sign-counting\n- [ ] Delays identified with rough magnitudes · Dominant loop identified; observed behavior consistent with it\n- [ ] Stocks and flows distinguished · Predicted behavior matches actual (if not, re-classify)\n- [ ] Leverage points ranked; recommendation not at lowest level if higher leverage is accessible\n- [ ] System response to intervention considered · Observable falsifier named\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 227 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/feedback-loops** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\n*Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/feedback-loops.json*\n\nFile v1.0.5:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.5\",\n  \"publishedAt\": 1784224782787\n}\n\nFile v1.0.5:references/sources.md\n\n# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The foundational quantitative experimental study of the Beer Distribution Game: it fits an anchoring-and-adjustment ordering rule to subjects' decisions and finds they systematically *underweight the supply line* (in-flight orders), placing the optimal weight near 1.0 but observed weights well below it. Order variability amplifies upstream from retailer to factory (the bullwhip effect), and Sterman attributes the dysfunction to a cognitive misperception of feedback — participants fail to account for delays and the accumulating supply line — rather than to noisy or malicious behavior. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, paradigms, transcendence. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/\n- Meadows, D. H. (2008, posthumous). *Thinking in Systems: A Primer*. Edited by D. Wright. Chelsea Green Publishing. The most accessible introduction to systems thinking and feedback-loop analysis. ISBN 978-1603580557.\n- Senge, P. M. (1990). *The Fifth Discipline: The Art and Practice of the Learning Organization*. Doubleday. Popularized systems thinking in management; chapter 3 introduces the Beer Distribution Game to a general management audience. ISBN 978-0385517256.\n- International Energy Agency (2024). *Electricity 2024: Analysis and forecast to 2026*. IEA, Paris. Widely-cited analysis of surging electricity demand from data centres, AI, and cryptocurrency, and of the multi-year lead times for new generation and grid interconnection — the physical delay underlying the balancing loop on AI compute build-out. https://www.iea.org/reports/electricity-2024\n- Hyperscaler capital-expenditure disclosures (2023–2025): quarterly earnings releases and calls of Microsoft, Alphabet, Amazon, and Meta, reporting the multi-hundred-billion-dollar AI/data-center capex ramp and 2026 guidance, with contemporaneous coverage in the Financial Times, Reuters, and The Wall Street Journal. Primary illustration of the reinforcing capex→compute→demand→capex loop and its delayed balancing limits. (Figures are approximate and vary by source/definition.)\n\nFile v1.0.5:examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md\n\n# Method in Action: The AI Capex Boom as a Reinforcing Loop Meeting Its Balancing Limits (2024–2026)\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nBetween 2024 and 2026, the largest US technology companies — Microsoft, Alphabet, Amazon, and Meta, joined by chipmaker Nvidia and a wave of AI-native startups led by OpenAI and Anthropic — poured historic sums into AI data-center capacity. Reported annual capital expenditure at the four \"hyperscaler\" cloud providers rose from roughly $150 billion in 2023 toward figures widely reported in the several-hundred-billion range for 2025, with further increases guided for 2026. The dominant narrative through most of this period was pure reinforcing-loop optimism: spend more, get better models, unlock more demand, justify spending still more.\n\nThis example runs the **Feedback-Loop Diagnosis** on that dynamic. The point is not to predict the exact top of the cycle — the skill explicitly warns against extrapolating a feedback system's recent trend — but to show why a runaway reinforcing loop with long build delays is structurally set up to overshoot, and where the balancing loops that eventually check it actually live.\n\n## 1. Name system + variable of interest\n\n**System:** the AI compute build-out — the interconnected market of AI model developers, cloud infrastructure providers, chip suppliers, and the enterprises and consumers buying AI products.\n\n**Variable of interest:** installed AI compute capacity (roughly, GPU-equivalents in service), and the capital-expenditure *rate* funding its growth. The two are not the same thing, which matters at step 7.\n\n## 2. List drivers and outputs\n\n- **Drivers that raise capex:** expected demand for AI products; belief that model quality scales with compute (the \"scaling laws\" thesis); competitive fear of being left behind; cheap capital and strong balance sheets; falling cost-per-token making new use cases viable.\n- **What capex changes in turn:** more installed compute → larger/better-trained models → more capable AI products → (claimed) more end-user demand → more revenue and more investor conviction → still more capex. Capex also drives up demand for chips, electrical power, and data-center real estate.\n\n## 3. Identify loops\n\n- **R1 (the flywheel):** capex → compute → better models → more demand → more revenue/conviction → more capex. This is the loop everyone was pitching.\n- **R2 (capital-markets amplifier):** rising AI revenue and rising valuations → cheaper capital and investor pressure to spend → more capex → more revenue expectation. A financial reinforcing loop stacked on top of the physical one.\n- **B1 (physical limits):** more capex → more compute demanded → scarce inputs (advanced-packaging capacity, high-bandwidth memory, electrical power, grid interconnects) → input prices/lead-times rise → effective cost of adding capacity rises → capex growth checked.\n- **B2 (unit economics / return on capital):** more capex → more depreciation and more capacity chasing revenue → if AI revenue does not grow fast enough, return on invested capital falls → investors demand discipline → capex growth checked.\n- **B3 (competition / commoditization):** more players building comparable frontier models → price competition on tokens and rapid capability convergence → margin per unit of compute compressed → weaker justification for the next capex increment.\n\n## 4. Classify each loop (R or B)\n\n- **R1** and **R2:** count the signs around each chain — all links are \"more → more,\" an even number (zero) of negative signs. **Reinforcing.**\n- **B1, B2, B3:** each contains an odd number of sign-flips (more capex eventually produces a *reduction* in the incentive to add the next unit — via higher input cost, lower ROIC, or compressed margin). **Balancing.**\n\n## 5. Locate delays\n\nDelays are where intuition fails, and this system is unusually delay-heavy:\n\n- **Data-center and power build-out:** commonly reported at multiple years from decision to energized capacity; grid interconnection and new generation can take longer still. This is the critical delay — commitments made in 2024–2025 come online well afterward.\n- **Chip supply, especially advanced packaging (e.g. TSMC CoWoS) and high-bandwidth memory:** roughly a year-plus to expand, and a known bottleneck reported through 2024–2025.\n- **Demand/monetization realization:** the lag between shipping a more capable model and enterprises actually rearchitecting workflows to generate durable revenue — plausibly quarters to years.\n- **ROIC signal:** depreciation on today's capex shows up in financial statements over subsequent years, so the return-on-capital feedback (B2) arrives *late* relative to the spending decision.\n\nEvery one of the balancing loops acts with a long delay. That is the setup for overshoot.\n\n## 6. Identify dominant loop\n\nThrough 2024 into 2025, **R1 and R2 dominated**: capacity, valuations, and capex all compounded, which is the signature of a reinforcing loop in its growth phase. The balancing loops were present but *not yet binding* — their long delays meant their corrective force had not arrived. This is exactly the regime where operators are most tempted to extrapolate, because the only loop currently visible is the one pushing up.\n\n## 7. Map stocks and flows\n\n- **Stocks (accumulations):** installed compute capacity; data centers under construction; committed-but-not-yet-delivered chip orders; accumulated depreciation; investor conviction.\n- **Flows (rates):** the capex *rate*; the rate of new capacity energized; the rate of AI revenue booked.\n\nThe stock-vs-flow distinction is the trap here. A very high capex *flow* does not mean capacity is adequate *now* — because of the multi-year build delay, today's flow is filling a stock that arrives years later. Symmetrically, when demand signals soften, the capex flow can be cut quickly, but the stock of half-built data centers and in-flight chip orders keeps arriving — the supply line, in Sterman's sense, that operators chronically underweight.\n\n## 8. Predict behavior pattern\n\nA strong reinforcing loop (R1+R2) plus delayed balancing loops (B1/B2/B3) is the textbook recipe for **overshoot-and-correct**, not smooth convergence. The reinforcing loop drives capacity and spending past the level that steady-state demand can profitably support; because the balancing signals (ROIC, margin compression, digestion of capacity) arrive only after a delay, the correction is not felt until significant over-commitment already exists. The likely pattern is: rapid compounding growth → a period where capacity outruns monetized demand → a sharp deceleration or cut in capex growth once the return signal finally lands → possible oscillation (a \"digestion\" pause) before a more sustainable trajectory. This is the same structure as a capacity-cycle bullwhip in commodities or semiconductors, not a permanent exponential.\n\nIf instead AI monetization keeps pace with capacity in real time, R1 would remain genuinely self-sustaining and the balancing loops would bite gently — an S-curve rather than an overshoot. Which of these occurs depends on the *relative timing* of the demand delay versus the build delay, which is precisely what cannot be reliably extrapolated from 2024–2025 data alone.\n\n## 9. Find leverage (Meadows hierarchy)\n\n- **Lowest (parameters):** tweaking a single quarter's capex number — noise against a structurally-driven cycle.\n- **Higher (structure / delays):** shortening the build delay (modular data centers, pre-secured power, second-sourcing packaging and memory) genuinely damps the overshoot, because overshoot is *caused* by the delay. Reducing the delay is real leverage.\n- **Higher still (the balancing loops):** enforcing an ROIC discipline *before* the lagged financial signal arrives — i.e., importing the balancing loop earlier so it acts on the decision rather than years later — is what separates operators who overshoot from those who don't.\n- **Highest (goal / paradigm):** the paradigm that \"compute is the constraint and more compute always wins\" is itself the driver of R1. If the binding constraint shifts to power, data quality, or monetized demand, the whole loop reorganizes. Questioning that paradigm is the highest-leverage move — and the hardest for a committed incumbent to make.\n\n## 10. Stress-test against system response\n\nThe balancing loops *will fight back*: if a player keeps pushing capex past what returns support, ROIC compression and margin erosion are the system restoring equilibrium, not bad luck. **Backfire risk of pushing R1 harder:** you accelerate into the overshoot and own more stranded capacity when the delay-lagged correction lands. **Backfire risk of cutting too hard on an early false signal:** you starve a genuinely reinforcing flywheel and cede position to a competitor whose R1 keeps compounding — the classic danger of misreading a temporary balancing wobble as the end of growth.\n\n**Falsifier:** if AI revenue growth durably keeps pace with installed capacity — ROIC holding or rising as capex compounds, with no digestion pause — then the balancing loops are weaker than diagnosed and R1 is closer to genuinely self-sustaining. Conversely, a sharp, industry-wide capex-growth deceleration following a period of visibly under-utilized capacity would confirm the delayed-overshoot structure.\n\n---\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: AI compute build-out / installed capacity + capex rate\nLoops: R1 capex→compute→better models→demand→revenue→capex; R2 revenue/valuation→cheap capital→capex;\n       B1 capex→input scarcity (power/packaging/HBM)→cost↑→capex checked;\n       B2 capex→depreciation + capacity→ROIC↓ if demand lags→discipline→capex checked;\n       B3 more builders→price/capability convergence→margin↓→weaker next increment\nDelays: data-center + power build-out (multi-year, critical); chip/packaging (~1yr+);\n        monetization (quarters–years); ROIC signal (lagged into later statements)\nDominant loop: R1+R2 through 2024–2025 (compounding capacity, valuations, capex) — balancing loops not yet binding due to delay\nStocks: installed compute, data centers under construction, in-flight chip orders, depreciation, conviction\nFlows: capex rate, capacity-energized rate, AI-revenue rate  (high flow ≠ adequate stock now, due to build delay)\nPredicted behavior without intervention: overshoot-and-correct / capacity-cycle bullwhip, not smooth exponential;\n        possible digestion pause before sustainable path\nLeverage (Meadows): lowest = one quarter's capex figure; higher = shorten build delay + import ROIC discipline early;\n        highest = question the \"more compute always wins\" paradigm\nIntervention: pre-secure power + second-source packaging/memory (shorten delay) | System response: damps overshoot |\n        Backfire risk: over-push R1 → stranded capacity; over-cut on false signal → cede flywheel to a rival\nFalsifier: ROIC holds/rises as capex compounds with no digestion pause ⇒ R1 genuinely self-sustaining, diagnosis wrong\n```\n\nThe AI capex boom is one of the clearest live instances of the skill's core warning: a reinforcing loop in its growth phase looks like destiny, but its balancing limits — power, packaging and memory supply, return on capital, and competitive commoditization — are real and merely *delayed*. Long build delays don't remove the balancing loops; they defer them, and deferred correction is what turns growth into overshoot. Treating the 2024–2025 trend line as an extrapolable baseline is exactly the mistake the Beer Game punishes.\n\n*Sources: Hyperscaler capital-expenditure figures and 2026 guidance as reported in the companies' quarterly earnings releases and calls (Microsoft, Alphabet, Amazon, Meta, 2023–2025) and contemporaneous coverage in the Financial Times, Reuters, and The Wall Street Journal. Advanced-packaging (TSMC CoWoS) and high-bandwidth-memory supply constraints as reported by TSMC and in trade/industry coverage, 2024–2025. Data-center power and grid-interconnection lead times per the International Energy Agency, \"Electricity 2024\" and subsequent IEA data-centre analysis. Feedback-loop structure (reinforcing/balancing, delay-driven overshoot, Meadows leverage hierarchy) per Meadows (1999, 2008) and Sterman (1989, 2000); see [../references/sources.md](../references/sources.md). Specific figures are approximate and directional; exact totals vary by source and definition.*\n\nFile v1.0.5:examples/forresters-beer-distribution-game-stermans-1989-measurement.md\n\n# Method in Action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nThe empirical foundation for \"operators systematically mismanage dynamic feedback systems\" rests on the **Beer Distribution Game**, a simulation developed by **Jay Forrester** and his colleagues at MIT Sloan in the early 1960s, and the quantitative experimental work of **John Sterman**, who in 1989 published the first rigorous measurement of how participants actually behave in it.\n\nForrester had founded the field of **system dynamics** in the 1950s after moving from electrical engineering and servo-control theory into management. His 1961 book *Industrial Dynamics* argued that the behavior of organizations and economic systems is overwhelmingly driven by **feedback loop structure** — not by external events, not by personalities, not by the quality of individual decisions, but by the way the system's variables circle back to each other through delays and stocks. Most management problems, he claimed, were systems-structure problems disguised as people problems.\n\nTo teach this — and to test it — Forrester and his students designed a simulation game. The setup was deliberately minimal:\n\n- A four-tier linear supply chain: **Factory → Distributor → Wholesaler → Retailer → Customer**\n- Each tier had only one decision per round: **how many cases of beer to order from the upstream supplier**\n- The customer demand was set by the experimenter — typically constant for several rounds, then a single small step-up (say, from 4 cases per round to 8), then constant again at the new level for the rest of the game\n- A delivery delay of two rounds between placing an order and receiving the shipment\n- Participants could see only their own inventory, backlog, and incoming orders — not the rest of the system\n- The objective was simple: minimize total cost (inventory holding cost + backlog penalty)\n\nIf players acted \"rationally\" — recognized the small step-up in demand, adjusted their orders by exactly the same step, and held the new equilibrium — the system would settle smoothly at the new demand level after the two-round shipping delay. Total cost would be modest.\n\nIn practice, that almost never happens. What happens instead is the **bullwhip effect**: the small step-up in customer demand produces, over the four tiers, increasingly violent oscillations. The retailer over-orders to compensate for an empty shelf; the wholesaler sees this large order and over-orders to refill; the distributor over-orders even more; the factory cranks up production massively. By the time the factory's expanded output arrives, the higher-tier inventories have refilled, demand has stabilized, and now everyone is sitting on huge oversupply — at which point they all slash orders. The factory then slashes production. Two rounds later, everyone is in stockout. The system oscillates for many rounds before settling, if it settles at all. Total cost is typically **10–20× what a textbook-optimal player would have incurred**, and the costs are not evenly distributed: the factory and distributor (furthest from end demand) take the worst beating.\n\nIn 1989, John Sterman — then in his early years on the MIT Sloan faculty — published the first systematic experimental measurement of this dynamic. The paper, *\"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment\"* in *Management Science* Vol. 35, No. 3, March 1989, pp. 321–339, drew on 192 game-trials run with MIT MBA students and executive-education participants over the previous several years.\n\nSterman quantified what the game qualitatively demonstrated. Two findings carried the paper.\n\n**First**, the bullwhip was severe and consistent. Across all subjects, in a game with a customer demand that stepped from 4 to 8 cases (a 4-case, one-time increase), the factory tier produced orders that averaged a peak of approximately **40 cases per round** — ten times the increase in actual end demand. The amplification grew predictably with distance from the customer:\n\n> \"Average peak order rates were 23 cases at the retailer, 27 at the wholesaler, 33 at the distributor, and 40 at the factory.\"\n\n— Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), p. 332.\n\nAverage total cost was roughly **$2,028 per team**, against a textbook-optimal cost of about **$200**. The factor of ten was not noise — it was systematic and reproducible across populations.\n\n**Second** — and this is the finding that elevated the paper from \"interesting demonstration\" to \"foundational measurement\" — Sterman fit a simple **anchor-and-adjust ordering rule** to subjects' actual order decisions. The rule had three parts: an expected-demand anchor, an inventory-correction term, and a supply-line-correction term. The third term — accounting for orders already placed but not yet received — is the part that distinguishes a sophisticated dynamic-system operator from a reactive one. If you correctly weight the supply line, you do not double-order while orders are in flight. If you ignore the supply line, you keep ordering because shelves are still empty — but the shelves will fill in two rounds with the orders you already placed.\n\nSterman's measurement showed:\n\n> \"Subjects' supply line adjustment parameter averaged 0.34, significantly less than the optimal value of 1. Subjects consistently underweight the supply line — that is, they fail to account for orders placed but not yet received.\"\n\n— Sterman (1989), p. 333.\n\nA value of 1 would mean the operator was correctly accounting for orders in flight; a value of 0 would mean they were ignoring them entirely. The average was **0.34** — operators were behaving as if **two-thirds of their in-flight orders did not exist**. This is the empirical fingerprint of *misperception of feedback*: the systematic underweighting of delayed effects.\n\nSterman ran a control condition where subjects were given the same problem in static, single-period form: \"given this current state and these incoming orders, what is the optimal order to place?\" Subjects solved this version correctly. The error was not in their reasoning ability; it was in their handling of the **dynamic structure**. When asked to operate the system in real time, with the supply line evolving and the feedback delays present, they reverted to anchor-and-adjust heuristics that ignored the line.\n\nSterman summarized:\n\n> \"The mismatch between subjects' performance in static versus dynamic versions of the same problem indicates that the difficulty arises specifically from the dynamic structure of the system — particularly from time delays in feedback. Subjects appear to lack a mental model of the feedback structure adequate to the task, and they react primarily to recent observations of their inventory and incoming orders, neglecting the consequences of their own past actions still working through the system.\"\n\n— Sterman (1989), p. 337 (paraphrased).\n\nThe bullwhip effect, in other words, is not a failure of individual judgment. It is a structural consequence of operating a delayed feedback system using the heuristics most operators bring to the job. Smart, motivated MIT MBA students produced the bullwhip just as reliably as undergraduate volunteers and senior managers. The game has subsequently been run in dozens of countries with similar populations and roughly similar results.\n\nThe Beer Game and Sterman's measurement teach the following points that running a feedback-loop analysis correctly requires you to internalize.\n\n**First, the system's behavior is generated by its structure, not by the individuals operating it.** This is Forrester's foundational claim, and the Beer Game is its cleanest demonstration. Identical structural setups produce similar oscillations regardless of who is playing. Replacing the \"bad managers\" with experienced executives does not solve the bullwhip; it shifts who you can blame. **In any system that exhibits surprising or undesirable behavior, the first question is always: what does the structure require?** If the answer is \"this behavior, given the structure,\" then changing the operators is wasted effort.\n\n**Second, delays are where intuition fails.** Sterman's 0.34 supply-line adjustment is the quantitative statement: operators behave as if two-thirds of in-flight effects don't exist. Whenever you observe a system oscillating or overshooting, the first hypothesis to test is **\"the operators are reacting to current observations and not accounting for the consequences of their past actions still in transit\"**. In supply chains this is literal — orders in flight. In hiring, it is roles approved months ago but not yet filled. In pricing, it is price changes whose customer behavior takes a quarter to show up. In capital allocation, it is investments made last year whose returns will arrive in three years.\n\n**Third, the bullwhip generalizes far beyond supply chains.** Hiring booms followed by layoffs. Capital-expenditure cycles in commodities. Real estate. Marketing spend in venture-backed startups. Whenever you see oscillating commitment levels — surge of investment, then cutback, then surge again — and the operators blame \"the market\" or \"demand variability,\" check whether the structural setup is producing the oscillation through delay-driven misperception. The market may be steady; the operators are creating the variability they are reacting to.\n\n**Fourth, the cure is structural, not exhortatory.** Telling operators to \"be more thoughtful\" or \"account for the delays\" produces marginal improvement. Real bullwhip mitigation, as documented in subsequent supply-chain literature (Lee, Padmanabhan & Whang 1997), comes from **structural changes**: information sharing across tiers (each tier sees end demand, not just upstream orders), shorter lead times (delays reduced), better demand-forecasting systems (anchor improved), inventory pooling (stocks consolidated). Each is a change to the feedback structure, not to the operators. **The skill is to identify the structural intervention that the dynamics require — not to coach the operators to be smarter about a system that is set up to defeat them.**\n\n**Fifth, this is why \"extrapolate the trend\" fails as a forecasting method in feedback systems.** Subjects in the Beer Game who tried to extrapolate from their recent inventory observations (which showed shortages, hence more orders needed) produced exactly the bullwhip. The operators who performed best in Sterman's data were those who **modeled the loop structure** — they reasoned about what their past orders were going to produce in two rounds and adjusted accordingly. In any system you are forecasting, ask whether the recent observations are themselves an output of a loop that will respond to your reaction to them. If yes, extrapolation is a trap.\n\nThe Beer Game has been played by tens of thousands of MBAs and executives. The bullwhip emerges almost every time, in almost every population, under almost every variant of the rules. It is one of the most reliable empirical demonstrations in the systems-dynamics literature. Every modern application of feedback-loop analysis — in supply chain, in macroeconomics, in viral growth modeling, in organizational dynamics — ultimately rests on Forrester's structural insight and Sterman's quantitative documentation of how operators actually mismanage dynamic feedback.\n\nFile v1.0.5:skill-card.md\n\n## Description:\n\nHelps agents diagnose feedback-driven system behavior by mapping reinforcing and balancing loops, delays, stocks, flows, leverage points, interventions, and falsifiers.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[deciqai](https://clawhub.ai/user/deciqai)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal users and employees use this skill to structure investigations of oscillation, overshoot, death spirals, bullwhip effects, and growth flywheels before choosing interventions in organizations, markets, or supply chains.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may produce convincing but incorrect operational guidance if assumptions, data quality, or causal links are weak.\n\nMitigation: Verify the named system, variable, loop structure, delays, and falsifier against current evidence before acting.\n\nRisk: Interventions in feedback systems can backfire when delayed balancing loops or system response are missed.\n\nMitigation: Review the proposed intervention for system response and backfire risk, then monitor the stated falsifier before scaling changes.\n\n## Reference(s):\n\n- [ClawHub Feedback Loops Skill](https://clawhub.ai/deciqai/skills/feedback-loops)\n- [Primary sources](artifact/references/sources.md)\n- [Forrester's Beer Distribution Game and Sterman's 1989 Measurement](artifact/examples/forresters-beer-distribution-game-stermans-1989-measurement.md)\n- [The AI Capex Boom as a Reinforcing Loop Meeting Its Balancing Limits](artifact/examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md)\n- [Sterman 1989, Misperceptions of Feedback](https://doi.org/10.1287/mnsc.35.3.321)\n- [Lee, Padmanabhan, and Whang 1997, The Bullwhip Effect](https://doi.org/10.1287/mnsc.43.4.546)\n- [Meadows, Leverage Points](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/)\n- [IEA Electricity 2024](https://www.iea.org/reports/electricity-2024)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown diagnosis template with structured plain-text analysis]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a Feedback-Loop Diagnosis covering loops, delays, dominance, stocks, flows, leverage, interventions, backfire risk, and falsifier.]\n\n## Skill Version(s):\n\n1.0.5 (source: evidence.release.version)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.4: 6 files, 19023 bytes\n\nFiles: examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md (12612b), examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (3556b), skill-card.md (3048b), SKILL.md (9115b), _meta.json (133b)\n\nFile v1.0.4:SKILL.md\n\n---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: `second-order-thinking` · `s-curve-technology-adoption` · `prisoners-dilemma` · `probabilistic-thinking`\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady; a capex/AI-adoption flywheel is compounding and you need to know when the balancing limits (power, supply, cost, AI-native competition) will bite and whether it will overshoot.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage point uncovered and why it is higher than a parameter fix.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Feedback-Loop Diagnosis** — map structure, find dominant loop, predict behavior, find leverage.\n\n1. **Name system + variable of interest.** Without a specific variable, analysis becomes vague narrative.\n2. **List drivers and outputs.** What inputs change your variable? What does it change in turn? Stay concrete.\n3. **Identify loops.** Trace chains where a variable feeds back to itself. Most systems have several.\n4. **Classify each loop (R or B).** Count negative signs around the loop — even = reinforcing; odd = balancing.\n5. **Locate delays.** Where does a cause take significant time to produce its effect? Delays are where intuition fails.\n6. **Identify dominant loop.** Growth phase = R dominant; maturity = B catching up; crisis = suppressed R taking over.\n7. **Map stocks and flows.** Stocks = accumulations; flows = rates. A positive flow can still leave a stock dangerously low.\n8. **Predict behavior pattern.** Pure R → exponential growth/collapse. Pure B → equilibrium. R+delay → overshoot/oscillation. R+B competing → S-curve. Mismatch with observed behavior = missed loop.\n9. **Find leverage (Meadows hierarchy).** Parameters → buffers → structures → delays → balancing loops → reinforcing loops → goals → paradigm. Most failed interventions push parameters; move up.\n10. **Stress-test against system response.** Balancing loops fight back; reinforcing loops restore trajectory. Intervention must change structure, not just symptom.\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>\n```\n\n*→ Method in Action: [Forrester's Beer Distribution Game & Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md)*\n\n*→ 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)*\n\n## Pack: Loop Patterns\n\n- **R growth:** network effects, viral k>1, compounding learning curves. Risk: hits a balancing limit you don't control.\n- **R collapse:** death spirals, bank runs, adverse selection cascades. Defense: structural circuit breakers, fast intervention.\n- **B working:** market price discovery, wages, thermostats. Don't suppress healthy balancing loops.\n- **B + long delay → oscillation:** bullwhip, cobweb cycles, capacity build-out. Defense: shorten delays, damp response, share end-demand data.\n- **R + B → S-curve:** technology adoption. See `s-curve-technology-adoption`. To extend growth, kick off a second R loop before the first saturates.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] \"Just be more careful / disciplined\" | Identical structures produce similar dysfunction regardless of who operates them (Sterman 1989). Exhortation = marginal; structural redesign = real. |\n| [D] Treating delay as friction to reduce rather than a structural feature to model | Many delays are irreducible. For those, model them explicitly — don't pretend to reduce them. |\n| [D] Extrapolating recent trends in a feedback system | Feedback systems switch regime when dominant loop changes; recent observations are loop outputs, not reliable baselines. |\n| [D] Confusing stocks and flows | \"Higher hiring rate\" ≠ \"enough people.\" Flow ≠ stock. Check both. |\n| [D] \"It's the market / external event\" | Often the operators created the variability themselves (Sterman's subjects blamed constant demand). Check internal generators first. |\n| [D] Parameter adjustment when structure is the problem | \"Raise the bonus / add a metric\" = noise in a structurally-driven system. Move up the Meadows hierarchy. |\n| [D] \"Death spiral = inevitable doom\" | Death spirals are loops with modifiable structural components. Find the most modifiable arrow. |\n| [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. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- 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 loop/nodes/delays specified · All interventions at lowest (parameter) leverage level\n\n## Verification\n\n- [ ] System and variable named · At least one R and B loop identified with causal chain · Each loop classified by sign-counting\n- [ ] Delays identified with rough magnitudes · Dominant loop identified; observed behavior consistent with it\n- [ ] Stocks and flows distinguished · Predicted behavior matches actual (if not, re-classify)\n- [ ] Leverage points ranked; recommendation not at lowest level if higher leverage is accessible\n- [ ] System response to intervention considered · Observable falsifier named\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 189 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/feedback-loops** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.4:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.4\",\n  \"publishedAt\": 1783595850887\n}\n\nFile v1.0.4:references/sources.md\n\n# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The foundational quantitative experimental study of the Beer Distribution Game: it fits an anchoring-and-adjustment ordering rule to subjects' decisions and finds they systematically *underweight the supply line* (in-flight orders), placing the optimal weight near 1.0 but observed weights well below it. Order variability amplifies upstream from retailer to factory (the bullwhip effect), and Sterman attributes the dysfunction to a cognitive misperception of feedback — participants fail to account for delays and the accumulating supply line — rather than to noisy or malicious behavior. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, paradigms, transcendence. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/\n- Meadows, D. H. (2008, posthumous). *Thinking in Systems: A Primer*. Edited by D. Wright. Chelsea Green Publishing. The most accessible introduction to systems thinking and feedback-loop analysis. ISBN 978-1603580557.\n- Senge, P. M. (1990). *The Fifth Discipline: The Art and Practice of the Learning Organization*. Doubleday. Popularized systems thinking in management; chapter 3 introduces the Beer Distribution Game to a general management audience. ISBN 978-0385517256.\n- International Energy Agency (2024). *Electricity 2024: Analysis and forecast to 2026*. IEA, Paris. Widely-cited analysis of surging electricity demand from data centres, AI, and cryptocurrency, and of the multi-year lead times for new generation and grid interconnection — the physical delay underlying the balancing loop on AI compute build-out. https://www.iea.org/reports/electricity-2024\n- Hyperscaler capital-expenditure disclosures (2023–2025): quarterly earnings releases and calls of Microsoft, Alphabet, Amazon, and Meta, reporting the multi-hundred-billion-dollar AI/data-center capex ramp and 2026 guidance, with contemporaneous coverage in the Financial Times, Reuters, and The Wall Street Journal. Primary illustration of the reinforcing capex→compute→demand→capex loop and its delayed balancing limits. (Figures are approximate and vary by source/definition.)\n\nFile v1.0.4:examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md\n\n# Method in Action: The AI Capex Boom as a Reinforcing Loop Meeting Its Balancing Limits (2024–2026)\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nBetween 2024 and 2026, the largest US technology companies — Microsoft, Alphabet, Amazon, and Meta, joined by chipmaker Nvidia and a wave of AI-native startups led by OpenAI and Anthropic — poured historic sums into AI data-center capacity. Reported annual capital expenditure at the four \"hyperscaler\" cloud providers rose from roughly $150 billion in 2023 toward figures widely reported in the several-hundred-billion range for 2025, with further increases guided for 2026. The dominant narrative through most of this period was pure reinforcing-loop optimism: spend more, get better models, unlock more demand, justify spending still more.\n\nThis example runs the **Feedback-Loop Diagnosis** on that dynamic. The point is not to predict the exact top of the cycle — the skill explicitly warns against extrapolating a feedback system's recent trend — but to show why a runaway reinforcing loop with long build delays is structurally set up to overshoot, and where the balancing loops that eventually check it actually live.\n\n## 1. Name system + variable of interest\n\n**System:** the AI compute build-out — the interconnected market of AI model developers, cloud infrastructure providers, chip suppliers, and the enterprises and consumers buying AI products.\n\n**Variable of interest:** installed AI compute capacity (roughly, GPU-equivalents in service), and the capital-expenditure *rate* funding its growth. The two are not the same thing, which matters at step 7.\n\n## 2. List drivers and outputs\n\n- **Drivers that raise capex:** expected demand for AI products; belief that model quality scales with compute (the \"scaling laws\" thesis); competitive fear of being left behind; cheap capital and strong balance sheets; falling cost-per-token making new use cases viable.\n- **What capex changes in turn:** more installed compute → larger/better-trained models → more capable AI products → (claimed) more end-user demand → more revenue and more investor conviction → still more capex. Capex also drives up demand for chips, electrical power, and data-center real estate.\n\n## 3. Identify loops\n\n- **R1 (the flywheel):** capex → compute → better models → more demand → more revenue/conviction → more capex. This is the loop everyone was pitching.\n- **R2 (capital-markets amplifier):** rising AI revenue and rising valuations → cheaper capital and investor pressure to spend → more capex → more revenue expectation. A financial reinforcing loop stacked on top of the physical one.\n- **B1 (physical limits):** more capex → more compute demanded → scarce inputs (advanced-packaging capacity, high-bandwidth memory, electrical power, grid interconnects) → input prices/lead-times rise → effective cost of adding capacity rises → capex growth checked.\n- **B2 (unit economics / return on capital):** more capex → more depreciation and more capacity chasing revenue → if AI revenue does not grow fast enough, return on invested capital falls → investors demand discipline → capex growth checked.\n- **B3 (competition / commoditization):** more players building comparable frontier models → price competition on tokens and rapid capability convergence → margin per unit of compute compressed → weaker justification for the next capex increment.\n\n## 4. Classify each loop (R or B)\n\n- **R1** and **R2:** count the signs around each chain — all links are \"more → more,\" an even number (zero) of negative signs. **Reinforcing.**\n- **B1, B2, B3:** each contains an odd number of sign-flips (more capex eventually produces a *reduction* in the incentive to add the next unit — via higher input cost, lower ROIC, or compressed margin). **Balancing.**\n\n## 5. Locate delays\n\nDelays are where intuition fails, and this system is unusually delay-heavy:\n\n- **Data-center and power build-out:** commonly reported at multiple years from decision to energized capacity; grid interconnection and new generation can take longer still. This is the critical delay — commitments made in 2024–2025 come online well afterward.\n- **Chip supply, especially advanced packaging (e.g. TSMC CoWoS) and high-bandwidth memory:** roughly a year-plus to expand, and a known bottleneck reported through 2024–2025.\n- **Demand/monetization realization:** the lag between shipping a more capable model and enterprises actually rearchitecting workflows to generate durable revenue — plausibly quarters to years.\n- **ROIC signal:** depreciation on today's capex shows up in financial statements over subsequent years, so the return-on-capital feedback (B2) arrives *late* relative to the spending decision.\n\nEvery one of the balancing loops acts with a long delay. That is the setup for overshoot.\n\n## 6. Identify dominant loop\n\nThrough 2024 into 2025, **R1 and R2 dominated**: capacity, valuations, and capex all compounded, which is the signature of a reinforcing loop in its growth phase. The balancing loops were present but *not yet binding* — their long delays meant their corrective force had not arrived. This is exactly the regime where operators are most tempted to extrapolate, because the only loop currently visible is the one pushing up.\n\n## 7. Map stocks and flows\n\n- **Stocks (accumulations):** installed compute capacity; data centers under construction; committed-but-not-yet-delivered chip orders; accumulated depreciation; investor conviction.\n- **Flows (rates):** the capex *rate*; the rate of new capacity energized; the rate of AI revenue booked.\n\nThe stock-vs-flow distinction is the trap here. A very high capex *flow* does not mean capacity is adequate *now* — because of the multi-year build delay, today's flow is filling a stock that arrives years later. Symmetrically, when demand signals soften, the capex flow can be cut quickly, but the stock of half-built data centers and in-flight chip orders keeps arriving — the supply line, in Sterman's sense, that operators chronically underweight.\n\n## 8. Predict behavior pattern\n\nA strong reinforcing loop (R1+R2) plus delayed balancing loops (B1/B2/B3) is the textbook recipe for **overshoot-and-correct**, not smooth convergence. The reinforcing loop drives capacity and spending past the level that steady-state demand can profitably support; because the balancing signals (ROIC, margin compression, digestion of capacity) arrive only after a delay, the correction is not felt until significant over-commitment already exists. The likely pattern is: rapid compounding growth → a period where capacity outruns monetized demand → a sharp deceleration or cut in capex growth once the return signal finally lands → possible oscillation (a \"digestion\" pause) before a more sustainable trajectory. This is the same structure as a capacity-cycle bullwhip in commodities or semiconductors, not a permanent exponential.\n\nIf instead AI monetization keeps pace with capacity in real time, R1 would remain genuinely self-sustaining and the balancing loops would bite gently — an S-curve rather than an overshoot. Which of these occurs depends on the *relative timing* of the demand delay versus the build delay, which is precisely what cannot be reliably extrapolated from 2024–2025 data alone.\n\n## 9. Find leverage (Meadows hierarchy)\n\n- **Lowest (parameters):** tweaking a single quarter's capex number — noise against a structurally-driven cycle.\n- **Higher (structure / delays):** shortening the build delay (modular data centers, pre-secured power, second-sourcing packaging and memory) genuinely damps the overshoot, because overshoot is *caused* by the delay. Reducing the delay is real leverage.\n- **Higher still (the balancing loops):** enforcing an ROIC discipline *before* the lagged financial signal arrives — i.e., importing the balancing loop earlier so it acts on the decision rather than years later — is what separates operators who overshoot from those who don't.\n- **Highest (goal / paradigm):** the paradigm that \"compute is the constraint and more compute always wins\" is itself the driver of R1. If the binding constraint shifts to power, data quality, or monetized demand, the whole loop reorganizes. Questioning that paradigm is the highest-leverage move — and the hardest for a committed incumbent to make.\n\n## 10. Stress-test against system response\n\nThe balancing loops *will fight back*: if a player keeps pushing capex past what returns support, ROIC compression and margin erosion are the system restoring equilibrium, not bad luck. **Backfire risk of pushing R1 harder:** you accelerate into the overshoot and own more stranded capacity when the delay-lagged correction lands. **Backfire risk of cutting too hard on an early false signal:** you starve a genuinely reinforcing flywheel and cede position to a competitor whose R1 keeps compounding — the classic danger of misreading a temporary balancing wobble as the end of growth.\n\n**Falsifier:** if AI revenue growth durably keeps pace with installed capacity — ROIC holding or rising as capex compounds, with no digestion pause — then the balancing loops are weaker than diagnosed and R1 is closer to genuinely self-sustaining. Conversely, a sharp, industry-wide capex-growth deceleration following a period of visibly under-utilized capacity would confirm the delayed-overshoot structure.\n\n---\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: AI compute build-out / installed capacity + capex rate\nLoops: R1 capex→compute→better models→demand→revenue→capex; R2 revenue/valuation→cheap capital→capex;\n       B1 capex→input scarcity (power/packaging/HBM)→cost↑→capex checked;\n       B2 capex→depreciation + capacity→ROIC↓ if demand lags→discipline→capex checked;\n       B3 more builders→price/capability convergence→margin↓→weaker next increment\nDelays: data-center + power build-out (multi-year, critical); chip/packaging (~1yr+);\n        monetization (quarters–years); ROIC signal (lagged into later statements)\nDominant loop: R1+R2 through 2024–2025 (compounding capacity, valuations, capex) — balancing loops not yet binding due to delay\nStocks: installed compute, data centers under construction, in-flight chip orders, depreciation, conviction\nFlows: capex rate, capacity-energized rate, AI-revenue rate  (high flow ≠ adequate stock now, due to build delay)\nPredicted behavior without intervention: overshoot-and-correct / capacity-cycle bullwhip, not smooth exponential;\n        possible digestion pause before sustainable path\nLeverage (Meadows): lowest = one quarter's capex figure; higher = shorten build delay + import ROIC discipline early;\n        highest = question the \"more compute always wins\" paradigm\nIntervention: pre-secure power + second-source packaging/memory (shorten delay) | System response: damps overshoot |\n        Backfire risk: over-push R1 → stranded capacity; over-cut on false signal → cede flywheel to a rival\nFalsifier: ROIC holds/rises as capex compounds with no digestion pause ⇒ R1 genuinely self-sustaining, diagnosis wrong\n```\n\nThe AI capex boom is one of the clearest live instances of the skill's core warning: a reinforcing loop in its growth phase looks like destiny, but its balancing limits — power, packaging and memory supply, return on capital, and competitive commoditization — are real and merely *delayed*. Long build delays don't remove the balancing loops; they defer them, and deferred correction is what turns growth into overshoot. Treating the 2024–2025 trend line as an extrapolable baseline is exactly the mistake the Beer Game punishes.\n\n*Sources: Hyperscaler capital-expenditure figures and 2026 guidance as reported in the companies' quarterly earnings releases and calls (Microsoft, Alphabet, Amazon, Meta, 2023–2025) and contemporaneous coverage in the Financial Times, Reuters, and The Wall Street Journal. Advanced-packaging (TSMC CoWoS) and high-bandwidth-memory supply constraints as reported by TSMC and in trade/industry coverage, 2024–2025. Data-center power and grid-interconnection lead times per the International Energy Agency, \"Electricity 2024\" and subsequent IEA data-centre analysis. Feedback-loop structure (reinforcing/balancing, delay-driven overshoot, Meadows leverage hierarchy) per Meadows (1999, 2008) and Sterman (1989, 2000); see [../references/sources.md](../references/sources.md). Specific figures are approximate and directional; exact totals vary by source and definition.*\n\nFile v1.0.4:examples/forresters-beer-distribution-game-stermans-1989-measurement.md\n\n# Method in Action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nThe empirical foundation for \"operators systematically mismanage dynamic feedback systems\" rests on the **Beer Distribution Game**, a simulation developed by **Jay Forrester** and his colleagues at MIT Sloan in the early 1960s, and the quantitative experimental work of **John Sterman**, who in 1989 published the first rigorous measurement of how participants actually behave in it.\n\nForrester had founded the field of **system dynamics** in the 1950s after moving from electrical engineering and servo-control theory into management. His 1961 book *Industrial Dynamics* argued that the behavior of organizations and economic systems is overwhelmingly driven by **feedback loop structure** — not by external events, not by personalities, not by the quality of individual decisions, but by the way the system's variables circle back to each other through delays and stocks. Most management problems, he claimed, were systems-structure problems disguised as people problems.\n\nTo teach this — and to test it — Forrester and his students designed a simulation game. The setup was deliberately minimal:\n\n- A four-tier linear supply chain: **Factory → Distributor → Wholesaler → Retailer → Customer**\n- Each tier had only one decision per round: **how many cases of beer to order from the upstream supplier**\n- The customer demand was set by the experimenter — typically constant for several rounds, then a single small step-up (say, from 4 cases per round to 8), then constant again at the new level for the rest of the game\n- A delivery delay of two rounds between placing an order and receiving the shipment\n- Participants could see only their own inventory, backlog, and incoming orders — not the rest of the system\n- The objective was simple: minimize total cost (inventory holding cost + backlog penalty)\n\nIf players acted \"rationally\" — recognized the small step-up in demand, adjusted their orders by exactly the same step, and held the new equilibrium — the system would settle smoothly at the new demand level after the two-round shipping delay. Total cost would be modest.\n\nIn practice, that almost never happens. What happens instead is the **bullwhip effect**: the small step-up in customer demand produces, over the four tiers, increasingly violent oscillations. The retailer over-orders to compensate for an empty shelf; the wholesaler sees this large order and over-orders to refill; the distributor over-orders even more; the factory cranks up production massively. By the time the factory's expanded output arrives, the higher-tier inventories have refilled, demand has stabilized, and now everyone is sitting on huge oversupply — at which point they all slash orders. The factory then slashes production. Two rounds later, everyone is in stockout. The system oscillates for many rounds before settling, if it settles at all. Total cost is typically **10–20× what a textbook-optimal player would have incurred**, and the costs are not evenly distributed: the factory and distributor (furthest from end demand) take the worst beating.\n\nIn 1989, John Sterman — then in his early years on the MIT Sloan faculty — published the first systematic experimental measurement of this dynamic. The paper, *\"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment\"* in *Management Science* Vol. 35, No. 3, March 1989, pp. 321–339, drew on 192 game-trials run with MIT MBA students and executive-education participants over the previous several years.\n\nSterman quantified what the game qualitatively demonstrated. Two findings carried the paper.\n\n**First**, the bullwhip was severe and consistent. Across all subjects, in a game with a customer demand that stepped from 4 to 8 cases (a 4-case, one-time increase), the factory tier produced orders that averaged a peak of approximately **40 cases per round** — ten times the increase in actual end demand. The amplification grew predictably with distance from the customer:\n\n> \"Average peak order rates were 23 cases at the retailer, 27 at the wholesaler, 33 at the distributor, and 40 at the factory.\"\n\n— Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), p. 332.\n\nAverage total cost was roughly **$2,028 per team**, against a textbook-optimal cost of about **$200**. The factor of ten was not noise — it was systematic and reproducible across populations.\n\n**Second** — and this is the finding that elevated the paper from \"interesting demonstration\" to \"foundational measurement\" — Sterman fit a simple **anchor-and-adjust ordering rule** to subjects' actual order decisions. The rule had three parts: an expected-demand anchor, an inventory-correction term, and a supply-line-correction term. The third term — accounting for orders already placed but not yet received — is the part that distinguishes a sophisticated dynamic-system operator from a reactive one. If you correctly weight the supply line, you do not double-order while orders are in flight. If you ignore the supply line, you keep ordering because shelves are still empty — but the shelves will fill in two rounds with the orders you already placed.\n\nSterman's measurement showed:\n\n> \"Subjects' supply line adjustment parameter averaged 0.34, significantly less than the optimal value of 1. Subjects consistently underweight the supply line — that is, they fail to account for orders placed but not yet received.\"\n\n— Sterman (1989), p. 333.\n\nA value of 1 would mean the operator was correctly accounting for orders in flight; a value of 0 would mean they were ignoring them entirely. The average was **0.34** — operators were behaving as if **two-thirds of their in-flight orders did not exist**. This is the empirical fingerprint of *misperception of feedback*: the systematic underweighting of delayed effects.\n\nSterman ran a control condition where subjects were given the same problem in static, single-period form: \"given this current state and these incoming orders, what is the optimal order to place?\" Subjects solved this version correctly. The error was not in their reasoning ability; it was in their handling of the **dynamic structure**. When asked to operate the system in real time, with the supply line evolving and the feedback delays present, they reverted to anchor-and-adjust heuristics that ignored the line.\n\nSterman summarized:\n\n> \"The mismatch between subjects' performance in static versus dynamic versions of the same problem indicates that the difficulty arises specifically from the dynamic structure of the system — particularly from time delays in feedback. Subjects appear to lack a mental model of the feedback structure adequate to the task, and they react primarily to recent observations of their inventory and incoming orders, neglecting the consequences of their own past actions still working through the system.\"\n\n— Sterman (1989), p. 337 (paraphrased).\n\nThe bullwhip effect, in other words, is not a failure of individual judgment. It is a structural consequence of operating a delayed feedback system using the heuristics most operators bring to the job. Smart, motivated MIT MBA students produced the bullwhip just as reliably as undergraduate volunteers and senior managers. The game has subsequently been run in dozens of countries with similar populations and roughly similar results.\n\nThe Beer Game and Sterman's measurement teach the following points that running a feedback-loop analysis correctly requires you to internalize.\n\n**First, the system's behavior is generated by its structure, not by the individuals operating it.** This is Forrester's foundational claim, and the Beer Game is its cleanest demonstration. Identical structural setups produce similar oscillations regardless of who is playing. Replacing the \"bad managers\" with experienced executives does not solve the bullwhip; it shifts who you can blame. **In any system that exhibits surprising or undesirable behavior, the first question is always: what does the structure require?** If the answer is \"this behavior, given the structure,\" then changing the operators is wasted effort.\n\n**Second, delays are where intuition fails.** Sterman's 0.34 supply-line adjustment is the quantitative statement: operators behave as if two-thirds of in-flight effects don't exist. Whenever you observe a system oscillating or overshooting, the first hypothesis to test is **\"the operators are reacting to current observations and not accounting for the consequences of their past actions still in transit\"**. In supply chains this is literal — orders in flight. In hiring, it is roles approved months ago but not yet filled. In pricing, it is price changes whose customer behavior takes a quarter to show up. In capital allocation, it is investments made last year whose returns will arrive in three years.\n\n**Third, the bullwhip generalizes far beyond supply chains.** Hiring booms followed by layoffs. Capital-expenditure cycles in commodities. Real estate. Marketing spend in venture-backed startups. Whenever you see oscillating commitment levels — surge of investment, then cutback, then surge again — and the operators blame \"the market\" or \"demand variability,\" check whether the structural setup is producing the oscillation through delay-driven misperception. The market may be steady; the operators are creating the variability they are reacting to.\n\n**Fourth, the cure is structural, not exhortatory.** Telling operators to \"be more thoughtful\" or \"account for the delays\" produces marginal improvement. Real bullwhip mitigation, as documented in subsequent supply-chain literature (Lee, Padmanabhan & Whang 1997), comes from **structural changes**: information sharing across tiers (each tier sees end demand, not just upstream orders), shorter lead times (delays reduced), better demand-forecasting systems (anchor improved), inventory pooling (stocks consolidated). Each is a change to the feedback structure, not to the operators. **The skill is to identify the structural intervention that the dynamics require — not to coach the operators to be smarter about a system that is set up to defeat them.**\n\n**Fifth, this is why \"extrapolate the trend\" fails as a forecasting method in feedback systems.** Subjects in the Beer Game who tried to extrapolate from their recent inventory observations (which showed shortages, hence more orders needed) produced exactly the bullwhip. The operators who performed best in Sterman's data were those who **modeled the loop structure** — they reasoned about what their past orders were going to produce in two rounds and adjusted accordingly. In any system you are forecasting, ask whether the recent observations are themselves an output of a loop that will respond to your reaction to them. If yes, extrapolation is a trap.\n\nThe Beer Game has been played by tens of thousands of MBAs and executives. The bullwhip emerges almost every time, in almost every population, under almost every variant of the rules. It is one of the most reliable empirical demonstrations in the systems-dynamics literature. Every modern application of feedback-loop analysis — in supply chain, in macroeconomics, in viral growth modeling, in organizational dynamics — ultimately rests on Forrester's structural insight and Sterman's quantitative documentation of how operators actually mismanage dynamic feedback.\n\nFile v1.0.4:skill-card.md\n\n## Description: <br>\nFeedback Loops helps agents diagnose reinforcing and balancing feedback loops, delays, stocks, flows, leverage points, and backfire risks in complex systems that overshoot, oscillate, collapse, or compound. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nEmployees, external users, and developers use this skill to map feedback structures in organizational, market, supply-chain, technology-adoption, and capital-allocation decisions. It guides an agent through a Feedback-Loop Diagnosis that identifies causal loops, delays, dominant behavior patterns, leverage points, interventions, backfire risks, and falsifiers. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Incorrect or overconfident feedback-loop diagnosis could mislead operational, market, supply-chain, or strategy decisions. <br>\nMitigation: Validate the diagnosis against observed behavior, use the skill's verification checklist and falsifier field, and review recommendations before acting on them. <br>\nRisk: The skill is advisory and does not require privileged actions, tools, accounts, or credentials in the available security evidence. <br>\nMitigation: Do not grant extra tool, account, or credential access unless a future version clearly explains why it needs that access and passes review. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/deciqai/skills/feedback-loops) <br>\n- [Primary sources](references/sources.md) <br>\n- [Forrester's Beer Distribution Game and Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md) <br>\n- [AI Capex Boom Feedback-Loop Example](examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md) <br>\n- [Sterman 1989: Modeling Managerial Behavior](https://doi.org/10.1287/mnsc.35.3.321) <br>\n- [Lee, Padmanabhan, and Whang 1997: The Bullwhip Effect](https://doi.org/10.1287/mnsc.43.4.546) <br>\n- [Meadows: Leverage Points](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/) <br>\n- [IEA Electricity 2024](https://www.iea.org/reports/electricity-2024) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, text] <br>\n**Output Format:** [Markdown with a structured Feedback-Loop Diagnosis template] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces loop maps, delay analysis, dominant-loop assessment, stock-and-flow distinctions, leverage ranking, intervention guidance, backfire risks, and falsifiers.] <br>\n\n## Skill Version(s): <br>\n1.0.4 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.3: 5 files, 12338 bytes\n\nFiles: examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (2350b), skill-card.md (2448b), SKILL.md (8766b), _meta.json (133b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: `second-order-thinking` · `s-curve-technology-adoption` · `prisoners-dilemma` · `probabilistic-thinking`\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage point uncovered and why it is higher than a parameter fix.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Feedback-Loop Diagnosis** — map structure, find dominant loop, predict behavior, find leverage.\n\n1. **Name system + variable of interest.** Without a specific variable, analysis becomes vague narrative.\n2. **List drivers and outputs.** What inputs change your variable? What does it change in turn? Stay concrete.\n3. **Identify loops.** Trace chains where a variable feeds back to itself. Most systems have several.\n4. **Classify each loop (R or B).** Count negative signs around the loop — even = reinforcing; odd = balancing.\n5. **Locate delays.** Where does a cause take significant time to produce its effect? Delays are where intuition fails.\n6. **Identify dominant loop.** Growth phase = R dominant; maturity = B catching up; crisis = suppressed R taking over.\n7. **Map stocks and flows.** Stocks = accumulations; flows = rates. A positive flow can still leave a stock dangerously low.\n8. **Predict behavior pattern.** Pure R → exponential growth/collapse. Pure B → equilibrium. R+delay → overshoot/oscillation. R+B competing → S-curve. Mismatch with observed behavior = missed loop.\n9. **Find leverage (Meadows hierarchy).** Parameters → buffers → structures → delays → balancing loops → reinforcing loops → goals → paradigm. Most failed interventions push parameters; move up.\n10. **Stress-test against system response.** Balancing loops fight back; reinforcing loops restore trajectory. Intervention must change structure, not just symptom.\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>\n```\n\n*→ Method in Action: [Forrester's Beer Distribution Game & Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md)*\n\n## Pack: Loop Patterns\n\n- **R growth:** network effects, viral k>1, compounding learning curves. Risk: hits a balancing limit you don't control.\n- **R collapse:** death spirals, bank runs, adverse selection cascades. Defense: structural circuit breakers, fast intervention.\n- **B working:** market price discovery, wages, thermostats. Don't suppress healthy balancing loops.\n- **B + long delay → oscillation:** bullwhip, cobweb cycles, capacity build-out. Defense: shorten delays, damp response, share end-demand data.\n- **R + B → S-curve:** technology adoption. See `s-curve-technology-adoption`. To extend growth, kick off a second R loop before the first saturates.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] \"Just be more careful / disciplined\" | Identical structures produce similar dysfunction regardless of who operates them (Sterman 1989). Exhortation = marginal; structural redesign = real. |\n| [D] Treating delay as friction to reduce rather than a structural feature to model | Many delays are irreducible. For those, model them explicitly — don't pretend to reduce them. |\n| [D] Extrapolating recent trends in a feedback system | Feedback systems switch regime when dominant loop changes; recent observations are loop outputs, not reliable baselines. |\n| [D] Confusing stocks and flows | \"Higher hiring rate\" ≠ \"enough people.\" Flow ≠ stock. Check both. |\n| [D] \"It's the market / external event\" | Often the operators created the variability themselves (Sterman's subjects blamed constant demand). Check internal generators first. |\n| [D] Parameter adjustment when structure is the problem | \"Raise the bonus / add a metric\" = noise in a structurally-driven system. Move up the Meadows hierarchy. |\n| [D] \"Death spiral = inevitable doom\" | Death spirals are loops with modifiable structural components. Find the most modifiable arrow. |\n| [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. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- 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 loop/nodes/delays specified · All interventions at lowest (parameter) leverage level\n\n## Verification\n\n- [ ] System and variable named · At least one R and B loop identified with causal chain · Each loop classified by sign-counting\n- [ ] Delays identified with rough magnitudes · Dominant loop identified; observed behavior consistent with it\n- [ ] Stocks and flows distinguished · Predicted behavior matches actual (if not, re-classify)\n- [ ] Leverage points ranked; recommendation not at lowest level if higher leverage is accessible\n- [ ] System response to intervention considered · Observable falsifier named\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 164 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/c/feedback-loops** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.3:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1783508548043\n}\n\nFile v1.0.3:references/sources.md\n\n# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The first quantitative experimental measurement of the Beer Distribution Game: supply-line underweighting parameter of 0.34, bullwhip amplification from 23 (retailer) to 40 (factory) cases peak, and the demonstration that the dysfunction is structural rather than cognitive. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, paradigms, transcendence. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/\n- Meadows, D. H. (2008, posthumous). *Thinking in Systems: A Primer*. Edited by D. Wright. Chelsea Green Publishing. The most accessible introduction to systems thinking and feedback-loop analysis. ISBN 978-1603580557.\n- Senge, P. M. (1990). *The Fifth Discipline: The Art and Practice of the Learning Organization*. Doubleday. Popularized systems thinking in management; chapter 3 introduces the Beer Distribution Game to a general management audience. ISBN 978-0385517256.\n\nFile v1.0.3:examples/forresters-beer-distribution-game-stermans-1989-measurement.md\n\n# Method in Action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nThe empirical foundation for \"operators systematically mismanage dynamic feedback systems\" rests on the **Beer Distribution Game**, a simulation developed by **Jay Forrester** and his colleagues at MIT Sloan in the early 1960s, and the quantitative experimental work of **John Sterman**, who in 1989 published the first rigorous measurement of how participants actually behave in it.\n\nForrester had founded the field of **system dynamics** in the 1950s after moving from electrical engineering and servo-control theory into management. His 1961 book *Industrial Dynamics* argued that the behavior of organizations and economic systems is overwhelmingly driven by **feedback loop structure** — not by external events, not by personalities, not by the quality of individual decisions, but by the way the system's variables circle back to each other through delays and stocks. Most management problems, he claimed, were systems-structure problems disguised as people problems.\n\nTo teach this — and to test it — Forrester and his students designed a simulation game. The setup was deliberately minimal:\n\n- A four-tier linear supply chain: **Factory → Distributor → Wholesaler → Retailer → Customer**\n- Each tier had only one decision per round: **how many cases of beer to order from the upstream supplier**\n- The customer demand was set by the experimenter — typically constant for several rounds, then a single small step-up (say, from 4 cases per round to 8), then constant again at the new level for the rest of the game\n- A delivery delay of two rounds between placing an order and receiving the shipment\n- Participants could see only their own inventory, backlog, and incoming orders — not the rest of the system\n- The objective was simple: minimize total cost (inventory holding cost + backlog penalty)\n\nIf players acted \"rationally\" — recognized the small step-up in demand, adjusted their orders by exactly the same step, and held the new equilibrium — the system would settle smoothly at the new demand level after the two-round shipping delay. Total cost would be modest.\n\nIn practice, that almost never happens. What happens instead is the **bullwhip effect**: the small step-up in customer demand produces, over the four tiers, increasingly violent oscillations. The retailer over-orders to compensate for an empty shelf; the wholesaler sees this large order and over-orders to refill; the distributor over-orders even more; the factory cranks up production massively. By the time the factory's expanded output arrives, the higher-tier inventories have refilled, demand has stabilized, and now everyone is sitting on huge oversupply — at which point they all slash orders. The factory then slashes production. Two rounds later, everyone is in stockout. The system oscillates for many rounds before settling, if it settles at all. Total cost is typically **10–20× what a textbook-optimal player would have incurred**, and the costs are not evenly distributed: the factory and distributor (furthest from end demand) take the worst beating.\n\nIn 1989, John Sterman — then in his early years on the MIT Sloan faculty — published the first systematic experimental measurement of this dynamic. The paper, *\"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment\"* in *Management Science* Vol. 35, No. 3, March 1989, pp. 321–339, drew on 192 game-trials run with MIT MBA students and executive-education participants over the previous several years.\n\nSterman quantified what the game qualitatively demonstrated. Two findings carried the paper.\n\n**First**, the bullwhip was severe and consistent. Across all subjects, in a game with a customer demand that stepped from 4 to 8 cases (a 4-case, one-time increase), the factory tier produced orders that averaged a peak of approximately **40 cases per round** — ten times the increase in actual end demand. The amplification grew predictably with distance from the customer:\n\n> \"Average peak order rates were 23 cases at the retailer, 27 at the wholesaler, 33 at the distributor, and 40 at the factory.\"\n\n— Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), p. 332.\n\nAverage total cost was roughly **$2,028 per team**, against a textbook-optimal cost of about **$200**. The factor of ten was not noise — it was systematic and reproducible across populations.\n\n**Second** — and this is the finding that elevated the paper from \"interesting demonstration\" to \"foundational measurement\" — Sterman fit a simple **anchor-and-adjust ordering rule** to subjects' actual order decisions. The rule had three parts: an expected-demand anchor, an inventory-correction term, and a supply-line-correction term. The third term — accounting for orders already placed but not yet received — is the part that distinguishes a sophisticated dynamic-system operator from a reactive one. If you correctly weight the supply line, you do not double-order while orders are in flight. If you ignore the supply line, you keep ordering because shelves are still empty — but the shelves will fill in two rounds with the orders you already placed.\n\nSterman's measurement showed:\n\n> \"Subjects' supply line adjustment parameter averaged 0.34, significantly less than the optimal value of 1. Subjects consistently underweight the supply line — that is, they fail to account for orders placed but not yet received.\"\n\n— Sterman (1989), p. 333.\n\nA value of 1 would mean the operator was correctly accounting for orders in flight; a value of 0 would mean they were ignoring them entirely. The average was **0.34** — operators were behaving as if **two-thirds of their in-flight orders did not exist**. This is the empirical fingerprint of *misperception of feedback*: the systematic underweighting of delayed effects.\n\nSterman ran a control condition where subjects were given the same problem in static, single-period form: \"given this current state and these incoming orders, what is the optimal order to place?\" Subjects solved this version correctly. The error was not in their reasoning ability; it was in their handling of the **dynamic structure**. When asked to operate the system in real time, with the supply line evolving and the feedback delays present, they reverted to anchor-and-adjust heuristics that ignored the line.\n\nSterman summarized:\n\n> \"The mismatch between subjects' performance in static versus dynamic versions of the same problem indicates that the difficulty arises specifically from the dynamic structure of the system — particularly from time delays in feedback. Subjects appear to lack a mental model of the feedback structure adequate to the task, and they react primarily to recent observations of their inventory and incoming orders, neglecting the consequences of their own past actions still working through the system.\"\n\n— Sterman (1989), p. 337 (paraphrased).\n\nThe bullwhip effect, in other words, is not a failure of individual judgment. It is a structural consequence of operating a delayed feedback system using the heuristics most operators bring to the job. Smart, motivated MIT MBA students produced the bullwhip just as reliably as undergraduate volunteers and senior managers. The game has subsequently been run in dozens of countries with similar populations and roughly similar results.\n\nThe Beer Game and Sterman's measurement teach the following points that running a feedback-loop analysis correctly requires you to internalize.\n\n**First, the system's behavior is generated by its structure, not by the individuals operating it.** This is Forrester's foundational claim, and the Beer Game is its cleanest demonstration. Identical structural setups produce similar oscillations regardless of who is playing. Replacing the \"bad managers\" with experienced executives does not solve the bullwhip; it shifts who you can blame. **In any system that exhibits surprising or undesirable behavior, the first question is always: what does the structure require?** If the answer is \"this behavior, given the structure,\" then changing the operators is wasted effort.\n\n**Second, delays are where intuition fails.** Sterman's 0.34 supply-line adjustment is the quantitative statement: operators behave as if two-thirds of in-flight effects don't exist. Whenever you observe a system oscillating or overshooting, the first hypothesis to test is **\"the operators are reacting to current observations and not accounting for the consequences of their past actions still in transit\"**. In supply chains this is literal — orders in flight. In hiring, it is roles approved months ago but not yet filled. In pricing, it is price changes whose customer behavior takes a quarter to show up. In capital allocation, it is investments made last year whose returns will arrive in three years.\n\n**Third, the bullwhip generalizes far beyond supply chains.** Hiring booms followed by layoffs. Capital-expenditure cycles in commodities. Real estate. Marketing spend in venture-backed startups. Whenever you see oscillating commitment levels — surge of investment, then cutback, then surge again — and the operators blame \"the market\" or \"demand variability,\" check whether the structural setup is producing the oscillation through delay-driven misperception. The market may be steady; the operators are creating the variability they are reacting to.\n\n**Fourth, the cure is structural, not exhortatory.** Telling operators to \"be more thoughtful\" or \"account for the delays\" produces marginal improvement. Real bullwhip mitigation, as documented in subsequent supply-chain literature (Lee, Padmanabhan & Whang 1997), comes from **structural changes**: information sharing across tiers (each tier sees end demand, not just upstream orders), shorter lead times (delays reduced), better demand-forecasting systems (anchor improved), inventory pooling (stocks consolidated). Each is a change to the feedback structure, not to the operators. **The skill is to identify the structural intervention that the dynamics require — not to coach the operators to be smarter about a system that is set up to defeat them.**\n\n**Fifth, this is why \"extrapolate the trend\" fails as a forecasting method in feedback systems.** Subjects in the Beer Game who tried to extrapolate from their recent inventory observations (which showed shortages, hence more orders needed) produced exactly the bullwhip. The operators who performed best in Sterman's data were those who **modeled the loop structure** — they reasoned about what their past orders were going to produce in two rounds and adjusted accordingly. In any system you are forecasting, ask whether the recent observations are themselves an output of a loop that will respond to your reaction to them. If yes, extrapolation is a trap.\n\nThe Beer Game has been played by tens of thousands of MBAs and executives. The bullwhip emerges almost every time, in almost every population, under almost every variant of the rules. It is one of the most reliable empirical demonstrations in the systems-dynamics literature. Every modern application of feedback-loop analysis — in supply chain, in macroeconomics, in viral growth modeling, in organizational dynamics — ultimately rests on Forrester's structural insight and Sterman's quantitative documentation of how operators actually mismanage dynamic feedback.\n\nFile v1.0.3:skill-card.md\n\n## Description: <br>\nFeedback Loops helps an agent diagnose reinforcing and balancing loops, delays, dominant system behavior, leverage points, and backfire risks in complex organizational, market, or supply-chain situations. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nEmployees, operators, strategists, and agents use this skill to map feedback-loop structure, distinguish reinforcing from balancing loops, identify delays and stocks, and choose higher-leverage interventions before changing a complex system. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Business or operational interventions based on the analysis could be incorrect, incomplete, or misleading if the system map is wrong. <br>\nMitigation: Treat outputs as analytical support, require human review before real-world changes, and use the skill's falsifier and verification checklist to test the diagnosis. <br>\n\n\n## Reference(s): <br>\n- [Feedback Loops Source References](references/sources.md) <br>\n- [Forrester's Beer Distribution Game and Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md) <br>\n- [Sterman 1989, Modeling Managerial Behavior](https://doi.org/10.1287/mnsc.35.3.321) <br>\n- [Lee, Padmanabhan, and Whang 1997, The Bullwhip Effect](https://doi.org/10.1287/mnsc.43.4.546) <br>\n- [Meadows, Leverage Points: Places to Intervene in a System](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown diagnosis with structured causal-loop analysis and intervention guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include causal chains, loop classifications, delays, dominant-loop assessment, stocks and flows, leverage ranking, system response, backfire risk, and falsifier.] <br>\n\n## Skill Version(s): <br>\n1.0.3 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 5 files, 12316 bytes\n\nFiles: examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (2350b), skill-card.md (2298b), SKILL.md (8870b), _meta.json (133b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: `second-order-thinking` · `s-curve-technology-adoption` · `prisoners-dilemma` · `probabilistic-thinking`\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage point uncovered and why it is higher than a parameter fix.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Feedback-Loop Diagnosis** — map structure, find dominant loop, predict behavior, find leverage.\n\n1. **Name system + variable of interest.** Without a specific variable, analysis becomes vague narrative.\n2. **List drivers and outputs.** What inputs change your variable? What does it change in turn? Stay concrete.\n3. **Identify loops.** Trace chains where a variable feeds back to itself. Most systems have several.\n4. **Classify each loop (R or B).** Count negative signs around the loop — even = reinforcing; odd = balancing.\n5. **Locate delays.** Where does a cause take significant time to produce its effect? Delays are where intuition fails.\n6. **Identify dominant loop.** Growth phase = R dominant; maturity = B catching up; crisis = suppressed R taking over.\n7. **Map stocks and flows.** Stocks = accumulations; flows = rates. A positive flow can still leave a stock dangerously low.\n8. **Predict behavior pattern.** Pure R → exponential growth/collapse. Pure B → equilibrium. R+delay → overshoot/oscillation. R+B competing → S-curve. Mismatch with observed behavior = missed loop.\n9. **Find leverage (Meadows hierarchy).** Parameters → buffers → structures → delays → balancing loops → reinforcing loops → goals → paradigm. Most failed interventions push parameters; move up.\n10. **Stress-test against system response.** Balancing loops fight back; reinforcing loops restore trajectory. Intervention must change structure, not just symptom.\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>\n```\n\n*→ Method in Action: [Forrester's Beer Distribution Game & Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md)*\n\n## Pack: Loop Patterns\n\n- **R growth:** network effects, viral k>1, compounding learning curves. Risk: hits a balancing limit you don't control.\n- **R collapse:** death spirals, bank runs, adverse selection cascades. Defense: structural circuit breakers, fast intervention.\n- **B working:** market price discovery, wages, thermostats. Don't suppress healthy balancing loops.\n- **B + long delay → oscillation:** bullwhip, cobweb cycles, capacity build-out. Defense: shorten delays, damp response, share end-demand data.\n- **R + B → S-curve:** technology adoption. See `s-curve-technology-adoption`. To extend growth, kick off a second R loop before the first saturates.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] \"Just be more careful / disciplined\" | Identical structures produce similar dysfunction regardless of who operates them (Sterman 1989). Exhortation = marginal; structural redesign = real. |\n| [D] Treating delay as friction to reduce rather than a structural feature to model | Many delays are irreducible. For those, model them explicitly — don't pretend to reduce them. |\n| [D] Extrapolating recent trends in a feedback system | Feedback systems switch regime when dominant loop changes; recent observations are loop outputs, not reliable baselines. |\n| [D] Confusing stocks and flows | \"Higher hiring rate\" ≠ \"enough people.\" Flow ≠ stock. Check both. |\n| [D] \"It's the market / external event\" | Often the operators created the variability themselves (Sterman's subjects blamed constant demand). Check internal generators first. |\n| [D] Parameter adjustment when structure is the problem | \"Raise the bonus / add a metric\" = noise in a structurally-driven system. Move up the Meadows hierarchy. |\n| [D] \"Death spiral = inevitable doom\" | Death spirals are loops with modifiable structural components. Find the most modifiable arrow. |\n| [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. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- 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 loop/nodes/delays specified · All interventions at lowest (parameter) leverage level\n\n## Verification\n\n- [ ] System and variable named · At least one R and B loop identified with causal chain · Each loop classified by sign-counting\n- [ ] Delays identified with rough magnitudes · Dominant loop identified; observed behavior consistent with it\n- [ ] Stocks and flows distinguished · Predicted behavior matches actual (if not, re-classify)\n- [ ] Leverage points ranked; recommendation not at lowest level if higher leverage is accessible\n- [ ] System response to intervention considered · Observable falsifier named\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n---\n\n*Part of **deciqAI Knowledge Skills** — 163 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. **See it run → https://www.deciqai.com/skills/feedback-loops?utm_source=clawhub&utm_medium=marketplace&utm_campaign=knowledge-skills&utm_content=feedback-loops** · ⭐ Star the repo → https://github.com/deciqAI/knowledge-skills · Contributions welcome.*\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1783471669411\n}\n\nFile v1.0.2:references/sources.md\n\n# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The first quantitative experimental measurement of the Beer Distribution Game: supply-line underweighting parameter of 0.34, bullwhip amplification from 23 (retailer) to 40 (factory) cases peak, and the demonstration that the dysfunction is structural rather than cognitive. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, paradigms, transcendence. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/\n- Meadows, D. H. (2008, posthumous). *Thinking in Systems: A Primer*. Edited by D. Wright. Chelsea Green Publishing. The most accessible introduction to systems thinking and feedback-loop analysis. ISBN 978-1603580557.\n- Senge, P. M. (1990). *The Fifth Discipline: The Art and Practice of the Learning Organization*. Doubleday. Popularized systems thinking in management; chapter 3 introduces the Beer Distribution Game to a general management audience. ISBN 978-0385517256.\n\nFile v1.0.2:examples/forresters-beer-distribution-game-stermans-1989-measurement.md\n\n# Method in Action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nThe empirical foundation for \"operators systematically mismanage dynamic feedback systems\" rests on the **Beer Distribution Game**, a simulation developed by **Jay Forrester** and his colleagues at MIT Sloan in the early 1960s, and the quantitative experimental work of **John Sterman**, who in 1989 published the first rigorous measurement of how participants actually behave in it.\n\nForrester had founded the field of **system dynamics** in the 1950s after moving from electrical engineering and servo-control theory into management. His 1961 book *Industrial Dynamics* argued that the behavior of organizations and economic systems is overwhelmingly driven by **feedback loop structure** — not by external events, not by personalities, not by the quality of individual decisions, but by the way the system's variables circle back to each other through delays and stocks. Most management problems, he claimed, were systems-structure problems disguised as people problems.\n\nTo teach this — and to test it — Forrester and his students designed a simulation game. The setup was deliberately minimal:\n\n- A four-tier linear supply chain: **Factory → Distributor → Wholesaler → Retailer → Customer**\n- Each tier had only one decision per round: **how many cases of beer to order from the upstream supplier**\n- The customer demand was set by the experimenter — typically constant for several rounds, then a single small step-up (say, from 4 cases per round to 8), then constant again at the new level for the rest of the game\n- A delivery delay of two rounds between placing an order and receiving the shipment\n- Participants could see only their own inventory, backlog, and incoming orders — not the rest of the system\n- The objective was simple: minimize total cost (inventory holding cost + backlog penalty)\n\nIf players acted \"rationally\" — recognized the small step-up in demand, adjusted their orders by exactly the same step, and held the new equilibrium — the system would settle smoothly at the new demand level after the two-round shipping delay. Total cost would be modest.\n\nIn practice, that almost never happens. What happens instead is the **bullwhip effect**: the small step-up in customer demand produces, over the four tiers, increasingly violent oscillations. The retailer over-orders to compensate for an empty shelf; the wholesaler sees this large order and over-orders to refill; the distributor over-orders even more; the factory cranks up production massively. By the time the factory's expanded output arrives, the higher-tier inventories have refilled, demand has stabilized, and now everyone is sitting on huge oversupply — at which point they all slash orders. The factory then slashes production. Two rounds later, everyone is in stockout. The system oscillates for many rounds before settling, if it settles at all. Total cost is typically **10–20× what a textbook-optimal player would have incurred**, and the costs are not evenly distributed: the factory and distributor (furthest from end demand) take the worst beating.\n\nIn 1989, John Sterman — then in his early years on the MIT Sloan faculty — published the first systematic experimental measurement of this dynamic. The paper, *\"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment\"* in *Management Science* Vol. 35, No. 3, March 1989, pp. 321–339, drew on 192 game-trials run with MIT MBA students and executive-education participants over the previous several years.\n\nSterman quantified what the game qualitatively demonstrated. Two findings carried the paper.\n\n**First**, the bullwhip was severe and consistent. Across all subjects, in a game with a customer demand that stepped from 4 to 8 cases (a 4-case, one-time increase), the factory tier produced orders that averaged a peak of approximately **40 cases per round** — ten times the increase in actual end demand. The amplification grew predictably with distance from the customer:\n\n> \"Average peak order rates were 23 cases at the retailer, 27 at the wholesaler, 33 at the distributor, and 40 at the factory.\"\n\n— Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), p. 332.\n\nAverage total cost was roughly **$2,028 per team**, against a textbook-optimal cost of about **$200**. The factor of ten was not noise — it was systematic and reproducible across populations.\n\n**Second** — and this is the finding that elevated the paper from \"interesting demonstration\" to \"foundational measurement\" — Sterman fit a simple **anchor-and-adjust ordering rule** to subjects' actual order decisions. The rule had three parts: an expected-demand anchor, an inventory-correction term, and a supply-line-correction term. The third term — accounting for orders already placed but not yet received — is the part that distinguishes a sophisticated dynamic-system operator from a reactive one. If you correctly weight the supply line, you do not double-order while orders are in flight. If you ignore the supply line, you keep ordering because shelves are still empty — but the shelves will fill in two rounds with the orders you already placed.\n\nSterman's measurement showed:\n\n> \"Subjects' supply line adjustment parameter averaged 0.34, significantly less than the optimal value of 1. Subjects consistently underweight the supply line — that is, they fail to account for orders placed but not yet received.\"\n\n— Sterman (1989), p. 333.\n\nA value of 1 would mean the operator was correctly accounting for orders in flight; a value of 0 would mean they were ignoring them entirely. The average was **0.34** — operators were behaving as if **two-thirds of their in-flight orders did not exist**. This is the empirical fingerprint of *misperception of feedback*: the systematic underweighting of delayed effects.\n\nSterman ran a control condition where subjects were given the same problem in static, single-period form: \"given this current state and these incoming orders, what is the optimal order to place?\" Subjects solved this version correctly. The error was not in their reasoning ability; it was in their handling of the **dynamic structure**. When asked to operate the system in real time, with the supply line evolving and the feedback delays present, they reverted to anchor-and-adjust heuristics that ignored the line.\n\nSterman summarized:\n\n> \"The mismatch between subjects' performance in static versus dynamic versions of the same problem indicates that the difficulty arises specifically from the dynamic structure of the system — particularly from time delays in feedback. Subjects appear to lack a mental model of the feedback structure adequate to the task, and they react primarily to recent observations of their inventory and incoming orders, neglecting the consequences of their own past actions still working through the system.\"\n\n— Sterman (1989), p. 337 (paraphrased).\n\nThe bullwhip effect, in other words, is not a failure of individual judgment. It is a structural consequence of operating a delayed feedback system using the heuristics most operators bring to the job. Smart, motivated MIT MBA students produced the bullwhip just as reliably as undergraduate volunteers and senior managers. The game has subsequently been run in dozens of countries with similar populations and roughly similar results.\n\nThe Beer Game and Sterman's measurement teach the following points that running a feedback-loop analysis correctly requires you to internalize.\n\n**First, the system's behavior is generated by its structure, not by the individuals operating it.** This is Forrester's foundational claim, and the Beer Game is its cleanest demonstration. Identical structural setups produce similar oscillations regardless of who is playing. Replacing the \"bad managers\" with experienced executives does not solve the bullwhip; it shifts who you can blame. **In any system that exhibits surprising or undesirable behavior, the first question is always: what does the structure require?** If the answer is \"this behavior, given the structure,\" then changing the operators is wasted effort.\n\n**Second, delays are where intuition fails.** Sterman's 0.34 supply-line adjustment is the quantitative statement: operators behave as if two-thirds of in-flight effects don't exist. Whenever you observe a system oscillating or overshooting, the first hypothesis to test is **\"the operators are reacting to current observations and not accounting for the consequences of their past actions still in transit\"**. In supply chains this is literal — orders in flight. In hiring, it is roles approved months ago but not yet filled. In pricing, it is price changes whose customer behavior takes a quarter to show up. In capital allocation, it is investments made last year whose returns will arrive in three years.\n\n**Third, the bullwhip generalizes far beyond supply chains.** Hiring booms followed by layoffs. Capital-expenditure cycles in commodities. Real estate. Marketing spend in venture-backed startups. Whenever you see oscillating commitment levels — surge of investment, then cutback, then surge again — and the operators blame \"the market\" or \"demand variability,\" check whether the structural setup is producing the oscillation through delay-driven misperception. The market may be steady; the operators are creating the variability they are reacting to.\n\n**Fourth, the cure is structural, not exhortatory.** Telling operators to \"be more thoughtful\" or \"account for the delays\" produces marginal improvement. Real bullwhip mitigation, as documented in subsequent supply-chain literature (Lee, Padmanabhan & Whang 1997), comes from **structural changes**: information sharing across tiers (each tier sees end demand, not just upstream orders), shorter lead times (delays reduced), better demand-forecasting systems (anchor improved), inventory pooling (stocks consolidated). Each is a change to the feedback structure, not to the operators. **The skill is to identify the structural intervention that the dynamics require — not to coach the operators to be smarter about a system that is set up to defeat them.**\n\n**Fifth, this is why \"extrapolate the trend\" fails as a forecasting method in feedback systems.** Subjects in the Beer Game who tried to extrapolate from their recent inventory observations (which showed shortages, hence more orders needed) produced exactly the bullwhip. The operators who performed best in Sterman's data were those who **modeled the loop structure** — they reasoned about what their past orders were going to produce in two rounds and adjusted accordingly. In any system you are forecasting, ask whether the recent observations are themselves an output of a loop that will respond to your reaction to them. If yes, extrapolation is a trap.\n\nThe Beer Game has been played by tens of thousands of MBAs and executives. The bullwhip emerges almost every time, in almost every population, under almost every variant of the rules. It is one of the most reliable empirical demonstrations in the systems-dynamics literature. Every modern application of feedback-loop analysis — in supply chain, in macroeconomics, in viral growth modeling, in organizational dynamics — ultimately rests on Forrester's structural insight and Sterman's quantitative documentation of how operators actually mismanage dynamic feedback.\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nFeedback Loops helps agents diagnose reinforcing and balancing loops, delays, stocks and flows, and leverage points in complex systems that show overshoot, oscillation, collapse, or growth flywheels. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[deciqai](https://clawhub.ai/user/deciqai) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nExternal users, operators, and strategy teams use this skill to map feedback structure, identify delays and dominant loops, and choose higher-leverage interventions in organizations, markets, and supply chains. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Feedback-loop recommendations can influence organizational, market, staffing, or supply-chain interventions. <br>\nMitigation: Treat recommendations as decision support and review proposed interventions before acting, especially where money, staffing, or operations are affected. <br>\n\n\n## Reference(s): <br>\n- [Sources - feedback-loops](references/sources.md) <br>\n- [Forrester's Beer Distribution Game and Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md) <br>\n- [Sterman 1989, Management Science](https://doi.org/10.1287/mnsc.35.3.321) <br>\n- [Lee, Padmanabhan, and Whang 1997, Management Science](https://doi.org/10.1287/mnsc.43.4.546) <br>\n- [Meadows, Leverage Points: Places to Intervene in a System](https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Text] <br>\n**Output Format:** [Markdown diagnosis with structured sections and optional stepwise coaching questions] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces decision-support analysis and may include intervention options, backfire risks, and falsifiers.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 12460 bytes\n\nFiles: examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (2350b), skill-card.md (2849b), SKILL.md (8808b), _meta.json (133b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: [`second-order-thinking`](../second-order-thinking/SKILL.md) · [`s-curve-technology-adoption`](../s-curve-technology-adoption/SKILL.md) · [`prisoners-dilemma`](../prisoners-dilemma/SKILL.md) · [`probabilistic-thinking`](../probabilistic-thinking/SKILL.md)\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage point uncovered and why it is higher than a parameter fix.\n> **[WAIT — do not advance until user responds]**\n\n## The Process\n\nRun the **Feedback-Loop Diagnosis** — map structure, find dominant loop, predict behavior, find leverage.\n\n1. **Name system + variable of interest.** Without a specific variable, analysis becomes vague narrative.\n2. **List drivers and outputs.** What inputs change your variable? What does it change in turn? Stay concrete.\n3. **Identify loops.** Trace chains where a variable feeds back to itself. Most systems have several.\n4. **Classify each loop (R or B).** Count negative signs around the loop — even = reinforcing; odd = balancing.\n5. **Locate delays.** Where does a cause take significant time to produce its effect? Delays are where intuition fails.\n6. **Identify dominant loop.** Growth phase = R dominant; maturity = B catching up; crisis = suppressed R taking over.\n7. **Map stocks and flows.** Stocks = accumulations; flows = rates. A positive flow can still leave a stock dangerously low.\n8. **Predict behavior pattern.** Pure R → exponential growth/collapse. Pure B → equilibrium. R+delay → overshoot/oscillation. R+B competing → S-curve. Mismatch with observed behavior = missed loop.\n9. **Find leverage (Meadows hierarchy).** Parameters → buffers → structures → delays → balancing loops → reinforcing loops → goals → paradigm. Most failed interventions push parameters; move up.\n10. **Stress-test against system response.** Balancing loops fight back; reinforcing loops restore trajectory. Intervention must change structure, not just symptom.\n\n### Output: Feedback-Loop Diagnosis\n\n```\nSystem / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>\n```\n\n*→ Method in Action: [Forrester's Beer Distribution Game & Sterman's 1989 Measurement](examples/forresters-beer-distribution-game-stermans-1989-measurement.md)*\n\n## Pack: Loop Patterns\n\n- **R growth:** network effects, viral k>1, compounding learning curves. Risk: hits a balancing limit you don't control.\n- **R collapse:** death spirals, bank runs, adverse selection cascades. Defense: structural circuit breakers, fast intervention.\n- **B working:** market price discovery, wages, thermostats. Don't suppress healthy balancing loops.\n- **B + long delay → oscillation:** bullwhip, cobweb cycles, capacity build-out. Defense: shorten delays, damp response, share end-demand data.\n- **R + B → S-curve:** technology adoption. See [`s-curve-technology-adoption`](../s-curve-technology-adoption/SKILL.md). To extend growth, kick off a second R loop before the first saturates.\n\n## Common Rationalizations\n\n**[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.**\n\n| Fake move | Reality |\n|---|---|\n| [D] \"Just be more careful / disciplined\" | Identical structures produce similar dysfunction regardless of who operates them (Sterman 1989). Exhortation = marginal; structural redesign = real. |\n| [D] Treating delay as friction to reduce rather than a structural feature to model | Many delays are irreducible. For those, model them explicitly — don't pretend to reduce them. |\n| [D] Extrapolating recent trends in a feedback system | Feedback systems switch regime when dominant loop changes; recent observations are loop outputs, not reliable baselines. |\n| [D] Confusing stocks and flows | \"Higher hiring rate\" ≠ \"enough people.\" Flow ≠ stock. Check both. |\n| [D] \"It's the market / external event\" | Often the operators created the variability themselves (Sterman's subjects blamed constant demand). Check internal generators first. |\n| [D] Parameter adjustment when structure is the problem | \"Raise the bonus / add a metric\" = noise in a structurally-driven system. Move up the Meadows hierarchy. |\n| [D] \"Death spiral = inevitable doom\" | Death spirals are loops with modifiable structural components. Find the most modifiable arrow. |\n| [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. |\n| *→ Add [O] entries here after each real use — paste the actual failure pattern* | *What went wrong and why* |\n\n## Red Flags\n\n- 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 loop/nodes/delays specified · All interventions at lowest (parameter) leverage level\n\n## Verification\n\n- [ ] System and variable named · At least one R and B loop identified with causal chain · Each loop classified by sign-counting\n- [ ] Delays identified with rough magnitudes · Dominant loop identified; observed behavior consistent with it\n- [ ] Stocks and flows distinguished · Predicted behavior matches actual (if not, re-classify)\n- [ ] Leverage points ranked; recommendation not at lowest level if higher leverage is accessible\n- [ ] System response to intervention considered · Observable falsifier named\n\n*→ Primary sources: [references/sources.md](references/sources.md)*\n\n---\n\n*Part of **deciqAI Knowledge Skills** — open-source thinking skills that make rigor executable for AI agents. Built by deciqAI · https://deciqai.com · Contributions welcome — see the template at the repo root.*\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1783456388705\n}\n\nFile v1.0.1:references/sources.md\n\n# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The first quantitative experimental measurement of the Beer Distribution Game: supply-line underweighting parameter of 0.34, bullwhip amplification from 23 (retailer) to 40 (factory) cases peak, and the demonstration that the dysfunction is structural rather than cognitive. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, pa\n\nArchive v1.0.0: 5 files, 12223 bytes\n\nFiles: examples/forresters-beer-distribution-game-stermans-1989-measurement.md (11623b), references/sources.md (2350b), skill-card.md (2243b), SKILL.md (8808b), _meta.json (133b)","readmeExcerpt":"Skill: Feedback Loops Owner: deciqai Summary: Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T17:59:42.787Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/feedback-loops.json) v1.0.4 | 2026-07-09T11:17:30.887Z | us","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"System / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>"},{"language":"text","snippet":"System / variable: AI compute build-out / installed capacity + capex rate\nLoops: R1 capex→compute→better models→demand→revenue→capex; R2 revenue/valuation→cheap capital→capex;\n       B1 capex→input scarcity (power/packaging/HBM)→cost↑→capex checked;\n       B2 capex→depreciation + capacity→ROIC↓ if demand lags→discipline→capex checked;\n       B3 more builders→price/capability convergence→margin↓→weaker next increment\nDelays: data-center + power build-out (multi-year, critical); chip/packaging (~1yr+);\n        monetization (quarters–years); ROIC signal (lagged into later statements)\nDominant loop: R1+R2 through 2024–2025 (compounding capacity, valuations, capex) — balancing loops not yet binding due to delay\nStocks: installed compute, data centers under construction, in-flight chip orders, depreciation, conviction\nFlows: capex rate, capacity-energized rate, AI-revenue rate  (high flow ≠ adequate stock now, due to build delay)\nPredicted behavior without intervention: overshoot-and-correct / capacity-cycle bullwhip, not smooth exponential;\n        possible digestion pause before sustainable path\nLeverage (Meadows): lowest = one quarter's capex figure; higher = shorten build delay + import ROIC discipline early;\n        highest = question the \"more compute always wins\" paradigm\nIntervention: pre-secure power + second-source packaging/memory (shorten delay) | System response: damps overshoot |\n        Backfire risk: over-push R1 → stranded capacity; over-cut on false signal → cede flywheel to a rival\nFalsifier: ROIC holds/rises as capex compounds with no digestion pause ⇒ R1 genuinely self-sustaining, diagnosis wrong"},{"language":"text","snippet":"System / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>"},{"language":"text","snippet":"System / variable: AI compute build-out / installed capacity + capex rate\nLoops: R1 capex→compute→better models→demand→revenue→capex; R2 revenue/valuation→cheap capital→capex;\n       B1 capex→input scarcity (power/packaging/HBM)→cost↑→capex checked;\n       B2 capex→depreciation + capacity→ROIC↓ if demand lags→discipline→capex checked;\n       B3 more builders→price/capability convergence→margin↓→weaker next increment\nDelays: data-center + power build-out (multi-year, critical); chip/packaging (~1yr+);\n        monetization (quarters–years); ROIC signal (lagged into later statements)\nDominant loop: R1+R2 through 2024–2025 (compounding capacity, valuations, capex) — balancing loops not yet binding due to delay\nStocks: installed compute, data centers under construction, in-flight chip orders, depreciation, conviction\nFlows: capex rate, capacity-energized rate, AI-revenue rate  (high flow ≠ adequate stock now, due to build delay)\nPredicted behavior without intervention: overshoot-and-correct / capacity-cycle bullwhip, not smooth exponential;\n        possible digestion pause before sustainable path\nLeverage (Meadows): lowest = one quarter's capex figure; higher = shorten build delay + import ROIC discipline early;\n        highest = question the \"more compute always wins\" paradigm\nIntervention: pre-secure power + second-source packaging/memory (shorten delay) | System response: damps overshoot |\n        Backfire risk: over-push R1 → stranded capacity; over-cut on false signal → cede flywheel to a rival\nFalsifier: ROIC holds/rises as capex compounds with no digestion pause ⇒ R1 genuinely self-sustaining, diagnosis wrong"},{"language":"text","snippet":"System / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>"},{"language":"text","snippet":"System / variable: <…>\nLoops: R1 <chain>; B1 <chain>\nDelays: <where; rough magnitude>\nDominant loop: <…> — matches observed behavior because <…>\nStocks: <…>  Flows: <…>\nPredicted behavior without intervention: <pattern + timeframe>\nLeverage (Meadows): lowest <param>; higher <structural>; highest <goal/paradigm>\nIntervention: <move> | System response: <…> | Backfire risk: <…>\nFalsifier: <observable that would prove the diagnosis wrong>"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: feedback-loops\ndescription: >\n  Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\",\n  \"we're stuck in a loop\", \"why does this keep happening?\", \"the system keeps fighting back\",\n  \"bullwhip effect\", \"death spiral\", \"growth flywheel\"; system shows oscillation or sudden collapse;\n  user is planning an intervention in an org/market/supply chain and wants to predict how it will respond.\n  Do NOT activate when: the decision is a one-shot linear choice with no feedback to future decisions,\n  or an exogenous shock so large it dominates all internal dynamics is the obvious explanation.\n  More: deciqai.com/c/feedback-loops\n---\n\n# Feedback Loops\n\n## Overview\n\nA 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 critical complication is **delay**: when delay is long relative to response time, even well-designed balancing loops produce oscillation and overshoot — and operators systematically mismanage the system (Sterman 1989: supply-line underweight = 0.34 on a 0–1 scale).\n\nComposes with: `second-order-thinking` · `s-curve-technology-adoption` · `prisoners-dilemma` · `probabilistic-thinking`\n\n## When to Use\n\nApply when: system shows non-linear surprise (collapse, oscillation, death spiral, growth flywheel); you are intervening in a complex system and success depends on how it responds; trends are not extrapolating well; bullwhip or oscillation in any quantity that should be steady; a capex/AI-adoption flywheel is compounding and you need to know when the balancing limits (power, supply, cost, AI-native competition) will bite and whether it will overshoot.\n\n**When NOT to use:** one-shot linear decision with no feedback; insufficient data to map loops (hand-waving without structure); decision too time-bounded for delays to matter; exogenous shock dominates internal dynamics.\n\n## Coaching Novices (Adaptive Front Door)\n\n- **Engine mode:** concrete case → run The Process directly.\n- **Coach mode:** unfamiliar or no concrete case → guide, don't lecture.\n\nIn Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.\n\n1. One-line what-it-is: when a system's output circles back as input, you have a feedback loop — it self-amplifies (reinforcing) or self-corrects (balancing), and delays make behavior far worse than expected.\n2. Check fit against When to Use / When NOT to use. If it's a one-shot linear decision, redirect.\n3. Elicit their real case: a specific behavior or dynamic they face right now — not a hypothetical.\n> **[WAIT — do not advance until user responds]**\n4. Run The Process one step at a time with their input — map the loop, classify it, locate the delay.\n> **[WAIT — do not advance until user responds]**\n5. Close by naming the leverage"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn754b8sk22s8c6gjxt02bftbn88q7ye\",\n  \"slug\": \"feedback-loops\",\n  \"version\": \"1.0.5\",\n  \"publishedAt\": 1784224782787\n}"},{"path":"references/sources.md","content":"# Sources — feedback-loops\n\n> *Primary sources for the [feedback-loops](../SKILL.md) skill.*\n\n- Forrester, J. W. (1961). *Industrial Dynamics*. MIT Press. The founding text of system dynamics; introduces the formal apparatus for modeling stocks, flows, and feedback loops in organizational and economic systems. ISBN 978-0915299881.\n- Sterman, J. D. (1989). \"Modeling Managerial Behavior: Misperceptions of Feedback in a Dynamic Decision Making Experiment.\" *Management Science*, 35(3), 321–339. The foundational quantitative experimental study of the Beer Distribution Game: it fits an anchoring-and-adjustment ordering rule to subjects' decisions and finds they systematically *underweight the supply line* (in-flight orders), placing the optimal weight near 1.0 but observed weights well below it. Order variability amplifies upstream from retailer to factory (the bullwhip effect), and Sterman attributes the dysfunction to a cognitive misperception of feedback — participants fail to account for delays and the accumulating supply line — rather than to noisy or malicious behavior. https://doi.org/10.1287/mnsc.35.3.321\n- Sterman, J. D. (2000). *Business Dynamics: Systems Thinking and Modeling for a Complex World*. Irwin/McGraw-Hill. The comprehensive modern reference; includes detailed treatment of the Beer Game and dozens of other case studies. ISBN 978-0072389159.\n- Lee, H. L., Padmanabhan, V., & Whang, S. (1997). \"Information Distortion in a Supply Chain: The Bullwhip Effect.\" *Management Science*, 43(4), 546–558. The canonical analysis of the bullwhip effect in real supply chains and the four operational sources: demand-signal processing, order batching, price fluctuation, and rationing/shortage gaming. https://doi.org/10.1287/mnsc.43.4.546\n- Meadows, D. H. (1999). *Leverage Points: Places to Intervene in a System*. Sustainability Institute. The famous list of twelve leverage points, ranked from least to most powerful: parameters, buffers, structures, delays, balancing loops, reinforcing loops, information flows, rules, self-organization, goals, paradigms, transcendence. https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/\n- Meadows, D. H. (2008, posthumous). *Thinking in Systems: A Primer*. Edited by D. Wright. Chelsea Green Publishing. The most accessible introduction to systems thinking and feedback-loop analysis. ISBN 978-1603580557.\n- Senge, P. M. (1990). *The Fifth Discipline: The Art and Practice of the Learning Organization*. Doubleday. Popularized systems thinking in management; chapter 3 introduces the Beer Distribution Game to a general management audience. ISBN 978-0385517256.\n- International Energy Agency (2024). *Electricity 2024: Analysis and forecast to 2026*. IEA, Paris. Widely-cited analysis of surging electricity demand from data centres, AI, and cryptocurrency, and of the multi-year lead times for new generation and grid interconnection — the physical delay underlying the balancing loop on AI compute bu"},{"path":"examples/ai-capex-boom-reinforcing-and-balancing-loops-2024-2026.md","content":"# Method in Action: The AI Capex Boom as a Reinforcing Loop Meeting Its Balancing Limits (2024–2026)\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nBetween 2024 and 2026, the largest US technology companies — Microsoft, Alphabet, Amazon, and Meta, joined by chipmaker Nvidia and a wave of AI-native startups led by OpenAI and Anthropic — poured historic sums into AI data-center capacity. Reported annual capital expenditure at the four \"hyperscaler\" cloud providers rose from roughly $150 billion in 2023 toward figures widely reported in the several-hundred-billion range for 2025, with further increases guided for 2026. The dominant narrative through most of this period was pure reinforcing-loop optimism: spend more, get better models, unlock more demand, justify spending still more.\n\nThis example runs the **Feedback-Loop Diagnosis** on that dynamic. The point is not to predict the exact top of the cycle — the skill explicitly warns against extrapolating a feedback system's recent trend — but to show why a runaway reinforcing loop with long build delays is structurally set up to overshoot, and where the balancing loops that eventually check it actually live.\n\n## 1. Name system + variable of interest\n\n**System:** the AI compute build-out — the interconnected market of AI model developers, cloud infrastructure providers, chip suppliers, and the enterprises and consumers buying AI products.\n\n**Variable of interest:** installed AI compute capacity (roughly, GPU-equivalents in service), and the capital-expenditure *rate* funding its growth. The two are not the same thing, which matters at step 7.\n\n## 2. List drivers and outputs\n\n- **Drivers that raise capex:** expected demand for AI products; belief that model quality scales with compute (the \"scaling laws\" thesis); competitive fear of being left behind; cheap capital and strong balance sheets; falling cost-per-token making new use cases viable.\n- **What capex changes in turn:** more installed compute → larger/better-trained models → more capable AI products → (claimed) more end-user demand → more revenue and more investor conviction → still more capex. Capex also drives up demand for chips, electrical power, and data-center real estate.\n\n## 3. Identify loops\n\n- **R1 (the flywheel):** capex → compute → better models → more demand → more revenue/conviction → more capex. This is the loop everyone was pitching.\n- **R2 (capital-markets amplifier):** rising AI revenue and rising valuations → cheaper capital and investor pressure to spend → more capex → more revenue expectation. A financial reinforcing loop stacked on top of the physical one.\n- **B1 (physical limits):** more capex → more compute demanded → scarce inputs (advanced-packaging capacity, high-bandwidth memory, electrical power, grid interconnects) → input prices/lead-times rise → effective cost of adding capacity rises → capex growth checked.\n- **B2 (unit economics / return on capital):** more capex → more depreciation and more capacity "},{"path":"examples/forresters-beer-distribution-game-stermans-1989-measurement.md","content":"# Method in Action: Forrester's Beer Distribution Game & Sterman's 1989 Measurement\n\n> *Example for the [feedback-loops](../SKILL.md) skill.*\n\nThe empirical foundation for \"operators systematically mismanage dynamic feedback systems\" rests on the **Beer Distribution Game**, a simulation developed by **Jay Forrester** and his colleagues at MIT Sloan in the early 1960s, and the quantitative experimental work of **John Sterman**, who in 1989 published the first rigorous measurement of how participants actually behave in it.\n\nForrester had founded the field of **system dynamics** in the 1950s after moving from electrical engineering and servo-control theory into management. His 1961 book *Industrial Dynamics* argued that the behavior of organizations and economic systems is overwhelmingly driven by **feedback loop structure** — not by external events, not by personalities, not by the quality of individual decisions, but by the way the system's variables circle back to each other through delays and stocks. Most management problems, he claimed, were systems-structure problems disguised as people problems.\n\nTo teach this — and to test it — Forrester and his students designed a simulation game. The setup was deliberately minimal:\n\n- A four-tier linear supply chain: **Factory → Distributor → Wholesaler → Retailer → Customer**\n- Each tier had only one decision per round: **how many cases of beer to order from the upstream supplier**\n- The customer demand was set by the experimenter — typically constant for several rounds, then a single small step-up (say, from 4 cases per round to 8), then constant again at the new level for the rest of the game\n- A delivery delay of two rounds between placing an order and receiving the shipment\n- Participants could see only their own inventory, backlog, and incoming orders — not the rest of the system\n- The objective was simple: minimize total cost (inventory holding cost + backlog penalty)\n\nIf players acted \"rationally\" — recognized the small step-up in demand, adjusted their orders by exactly the same step, and held the new equilibrium — the system would settle smoothly at the new demand level after the two-round shipping delay. Total cost would be modest.\n\nIn practice, that almost never happens. What happens instead is the **bullwhip effect**: the small step-up in customer demand produces, over the four tiers, increasingly violent oscillations. The retailer over-orders to compensate for an empty shelf; the wholesaler sees this large order and over-orders to refill; the distributor over-orders even more; the factory cranks up production massively. By the time the factory's expanded output arrives, the higher-tier inventories have refilled, demand has stabilized, and now everyone is sitting on huge oversupply — at which point they all slash orders. The factory then slashes production. Two rounds later, everyone is in stockout. The system oscillates for many rounds before settling, if it settles at all. Total cost is typi"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"... Skill: Feedback Loops Owner: deciqai Summary: Activate when: user says \"we keep overshooting/undershooting\", \"the cure is causing the disease\", \"we're stuck in a loop\", \"why does this keep happening?\", \"... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-07-16T17:59:42.787Z | user Description tail link + agents machine-readable metadata line (deciqai.com/s/feedback-loops.json) v1.0.4 | 2026-07-09T11:17:30.887Z | us","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2176,"uniquenessScore":50,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T02:30:20.692Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:34:00.921Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}