Systemsthinking

Customization

Before executing, check for user customizations at: ~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/SystemsThinking/

If this directory exists, load and apply any PREFERENCES.md, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

MANDATORY: Voice Notification (REQUIRED BEFORE ANY ACTION)

You MUST send this notification BEFORE doing anything else when this skill is invoked.

1. Send voice notification:

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the SystemsThinking skill to ACTION"}' \
     > /dev/null 2>&1 &

2. Output text notification:

   Running the **WorkflowName** workflow in the **SystemsThinking** skill to ACTION...

This is not optional. Execute this curl command immediately upon skill invocation.

---

SystemsThinking Skill

Structured analysis of complex systems — the tools that reveal why the same problem keeps coming back and where a small change produces a large result. Grounded in Donella Meadows, Peter Senge, Jay Forrester, Russell Ackoff, and the Santa Fe Institute tradition.

Systems thinking is the difference between treating symptoms (patch the bug) and fixing structure (change the feedback loop that keeps producing the bug). Most "debug it harder" attempts fail because they operate at the event layer; the real cause lives 3-4 layers below, in the structure that generates events.

Core Concept

A system is a set of elements interconnected in a way that produces a characteristic behavior over time. Change the elements, often nothing happens. Change the interconnections or the purpose, and behavior shifts dramatically.

Five axioms this skill operates on:

1. Behavior is generated by structure. If the same outcome keeps happening, the cause is structural, not a series of unrelated incidents. 2. Events are visible; structure is not. Most analysis stops at events. Systems thinking walks down. 3. Feedback loops are the basic unit. Every persistent pattern is one of a small number of loop archetypes. 4. High-leverage interventions are usually counterintuitive. The obvious fix often makes the problem worse (policy resistance, shifting the burden, fixes that fail). 5. You can't optimize a part of a system — you can only improve the system. Local optimization often degrades global performance.

Use / Win

When to use:

• Recurring problems — the same kind of bug, incident, deadline slip, or conflict keeps appearing. Event-level fixes are not working.
• Unintended consequences — a "fix" produced a new problem, or made the original worse.
• System design — before committing to an architecture, product strategy, organization structure, or policy.
• Debugging systemic issues — distributed-system flakiness, performance cliffs, reliability decay, tech-debt accretion.
• Strategy — understanding where competition, demand, adoption, or resistance actually comes from.
• Policy, incentives, organization design — any environment where human behavior is an input.
• Before a large intervention — run the causal loop first; intended effects are rarely the only effects.

What you win:

• Structural causes instead of blame-the-nearest-event. The real lever is almost never where the symptom appeared.
• Archetype recognition — most organizational and technical pathologies match one of ~10 patterns. Naming the pattern unlocks the canonical intervention.
• Leverage-point identification — Meadows' 12 leverage points, ordered. Parameters are low leverage; paradigms are highest. Knowing where to push is the whole game.
• Unintended-consequence preview — causal loops let you simulate second- and third-order effects before shipping the change.
• Durable fixes — structural changes don't regress the way symptom patches do.

Default mental model: At Extended+ effort on anything with recurring behavior, organizational dynamics, or cross-component coupling, systems thinking is not optional enrichment — it's how you find the fix that sticks.

Workflow Routing

Route to the appropriate workflow based on the request.

Quick Reference

• 5 workflows — Iceberg, CausalLoop, FindArchetype, FindLeverage, ConceptMap
• Iceberg layers (top to bottom): Events → Patterns → Structures → Mental Models
• Feedback loop types: Reinforcing (R) — amplifying / exponential; Balancing (B) — goal-seeking / stabilizing
• Archetype count: ~10 canonical patterns (Senge, Braun)
• Leverage points: 12 levels, from parameters (weakest) to paradigm transcendence (strongest) — Meadows

Context files (loaded on demand):

• Foundation.md — Meadows, Senge, Forrester, Ackoff, Capra; canonical definitions
• Archetypes.md — the 10 systems archetypes with structure, recognition signs, canonical intervention
• LeveragePoints.md — Meadows' 12 leverage points with worked examples

Integration

Depends on: nothing — standalone analytical skill.

Works well with:

• RootCauseAnalysis — RCA is event-layer and pattern-layer; SystemsThinking continues down to structure and mental models. Pair them for deep incident analysis.
• FirstPrinciples — decompose to axioms, then use SystemsThinking to see how axioms interconnect.
• IterativeDepth — rotates lenses; SystemsThinking is the structural lens.
• BeCreative / Ideate — generate intervention candidates after identifying the leverage point.
• Art — render causal loop diagrams, iceberg diagrams, concept maps.

Examples

Example 1: Recurring incidents

User: "we keep getting paged for the same class of timeout"
→ Iceberg workflow
→ Events: 6 pages in 3 weeks
→ Patterns: all during deploy windows, all touching payments service
→ Structure: auto-scaler cold-start latency > health-check timeout during deploys
→ Mental model: "deploys are safe if tests pass" — but health checks aren't in the test path
→ Fix is structural, not another retry

Example 2: Strategy

User: "why does adding engineers slow us down past team size 12?"
→ FindArchetype workflow
→ Match: "Limits to Growth" archetype
→ Reinforcing loop: more engineers → more output → more hiring
→ Balancing loop: team size → coordination cost → per-engineer output ↓
→ Canonical intervention: attack the balancing loop (coordination mechanism), not the reinforcing one (stop hiring)

Example 3: Unintended consequences preview

User: "we're about to add a rate limit to stop abuse"
→ CausalLoop workflow
→ Build CLD of users, abusers, support load, legitimate traffic
→ Surface: balancing loop (rate limit ↓ abuse), reinforcing loop (rate limit → legit users retry → total load ↑)
→ Recommend: rate-limit per-identity with reputation scoring, not per-IP

Best Practices

1. Always walk the iceberg before intervening. Even if you end up fixing at the event layer, knowing the structural cause tells you whether your fix is durable. 2. Draw the loops. Causal loops are almost always clearer on paper than in prose. Use the Art skill for rendering. 3. Name the archetype. If the behavior matches a known archetype, the canonical intervention is documented — don't reinvent it. 4. Leverage-point order matters. Parameters (taxes, quotas, settings) are low leverage; structures and rules are middle; paradigms are highest. Prefer higher where the cost allows. 5. Second-order effects are not optional. Any non-trivial intervention should be simulated through at least one round of its own feedback loop before shipping.

Gotchas

• Systems thinking is descriptive, not prescriptive. It reveals structure; it does not tell you what to build. Use it with BeCreative or FirstPrinciples to generate interventions.
• Don't mistake a list for a system. A system has feedback. If you can't draw at least one loop, you have a list of components, not a system.
• Blaming the model is the mistake. When a loop says something uncomfortable ("incentives are the cause"), the reaction is often to reject the model. Sit with it.
• Delay is underrated. Many systemic failures come from delays (between action and feedback). Capture delays explicitly on your diagram.
• Soft variables count. "Trust," "morale," "perceived safety" are as real as latency numbers in systems work. Don't drop them because they're hard to measure.

---

Attribution: Frameworks drawn from Donella Meadows (Thinking in Systems, 2008; "Places to Intervene in a System," 1999), Peter Senge (The Fifth Discipline, 1990), Jay Forrester (Industrial Dynamics, 1961), Russell Ackoff (Systems Thinking for Curious Managers), Fritjof Capra (The Web of Life), and the System Dynamics Society tradition.

Execution Log

After completing any workflow, append a single JSONL entry:

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"SystemsThinking","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/PAI/MEMORY/SKILLS/execution.jsonl

SystemsThinking — Archetypes Reference

The ten canonical systems archetypes (Senge, Goodman, Kiefer, Kemeny, codified in The Fifth Discipline, 1990; expanded by Braun, 2002). Each archetype is a template — recognizing the template suggests the intervention.

Structure-first: every archetype is defined by its feedback-loop shape, not by its surface symptoms. Two different archetypes can have similar-looking symptoms but different generating structures.

---

1. Fixes That Fail

Loop structure: B (symptom fix) + R with delay (unintended consequence).

Behavior: Quick fix relieves symptom short-term. Delayed side effects worsen the underlying problem. More fixes required. Side effects compound.

Recognition: "We keep fixing this and it keeps coming back bigger." Each fix requires more force than the last. Energy spent on remediation rather than prevention.

Example 1 — Manufacturing: Antibiotics for viral respiratory infections. Symptom relief (real). No pathogen addressed (fix fails underlying problem). Repeated prescribing selects for antibiotic resistance (unintended consequence).

Example 2 — Software: Adding timeouts to flaky distributed calls. Short-term: calls complete. Long-term: timeouts mask real latency; services drift to worse performance; eventually total outage.

Example 3 — Business: Cutting engineering headcount to hit Q4 margins → reduces short-term burn → increases engineering bottleneck → product velocity drops → revenue falls → need deeper cuts.

Canonical intervention:

• Surface and accept the delay explicitly. Ask "what are the second-order effects of this fix in 6 months?" before implementing.
• Find a fundamental solution that doesn't trigger the consequence.
• Accept short-term pain to stop the cycle.
• If a quick fix is unavoidable, explicitly time-box it and commit to a fundamental solution on a deadline.

---

2. Shifting the Burden

Loop structure: Two balancing loops (symptomatic B + fundamental B) + one reinforcing loop where the symptomatic solution atrophies the fundamental capability.

Behavior: Symptomatic solution is fast and feels effective. It atrophies the fundamental solution capability. The more successful the symptomatic solution, the less capable the system becomes of addressing root causes. Eventually the system is entirely dependent on the symptomatic fix.

Recognition: "We'll do it properly once we get through this crisis." The crisis never ends. "The hack became the system." "Only Alice knows how to run it."

Example 1 — Medical: Opioids for chronic pain. Fast symptomatic relief. Atrophies patient's investment in physical therapy, behavioral change (fundamental). Dependency develops.

Example 2 — Software: Technical ops team firefighting production incidents. Symptomatic: on-call engineers fix issues manually. Fundamental: proper observability, automated remediation, root-cause engineering. The more symptomatic succeeds (fires put out), the less organizational pressure to invest in fundamental. On-call burns out; system becomes fragile.

Example 3 — Business: Consultants hired to solve what should be internal capability. Over time, internal capability atrophies. Consultant dependency increases. Cost increases. Internal capability never develops.

Canonical intervention:

• Sunset dates on symptomatic solutions.
• Explicit investment in fundamental capability even while symptomatic fix is in place.
• Measure the atrophy explicitly — track whether fundamental capacity is growing or shrinking.

---

3. Limits to Growth (a.k.a. Limits to Success)

Loop structure: R (growth engine) + B (limiting constraint, often delayed).

Behavior: System grows initially, then growth slows as limiting constraint activates. If actors push harder (trying to maintain growth by pushing on the growth engine), growth continues briefly then collapses.

Recognition: "We used to 10x. Now we barely 1.5x. Nothing we try helps." "We just need to push harder and growth will come back."

Example 1 — Startup: Growth hitting hiring capacity (see Workflows/CausalLoop.md worked example). Each new hire costs more in coordination than they contribute in output once past size 12-15.

Example 2 — Sales: Sales team pushing harder as growth slows — not realizing the constraint is delivery capacity. More sales = more delivery failures = reputation damage = harder to sell.

Example 3 — Product: SaaS product growth hitting infrastructure limits; team velocity hitting cognitive load limits.

Canonical intervention:

• The leverage is never on the reinforcing loop. It is on the limiting constraint.
• Identify the limit (balancing loop) before it activates.
• Attack the limit directly — change the constraint, raise the ceiling.
• Pushing harder on the growth engine always makes the eventual collision with the limit more severe.

---

4. Tragedy of the Commons

Loop structure: Each actor has R (individual gain from shared resource) + B (resource degradation from total use). Actors experience own gain immediately but share degradation cost collectively.

Behavior: Rational individual actors over-exploit shared resource until it collapses. No actor is irrational. The system structure produces the outcome regardless of intentions.

Recognition: Shared resource (staging environment, shared service, common infrastructure). Each team optimizes locally; resource degrades for all. "Nobody owns it." "Everyone is extracting too much but no one wants to go first in cutting back."

Example 1 — Environmental: Overfishing. Groundwater depletion.

Example 2 — Software: Shared engineering resources in large organizations (everyone requests more compute from the shared cluster; no one individually restrains use). Open-source maintainer burnout (everyone consumes, few contribute back). Shared test database (each dev writes data; nobody cleans up; tests get slower).

Example 3 — Ops: Shared QA environment in a software organization. Each team schedules tests when needed. Total test runs exceed capacity. Queue grows. Feedback slows. Everyone's velocity drops — but no one team individually caused it.

Canonical intervention:

• Privatize the commons (each actor manages own resource). Partition, quota, per-team instance.
• Visibility into shared resource consumption + governance (usage limits, taxation, quotas, pricing).
• Assign ownership with budget and authority.

---

5. Escalation

Loop structure: Two reinforcing loops, each driven by one actor's position relative to the other's.

Behavior: Actor A's actions perceived as threatening by Actor B. B responds. A perceives B's response as escalation. A escalates further. Loop accelerates.

Recognition: "Both sides are doing more, nobody is winning." "We're just responding to what they did."

Example 1 — Competition: Arms races. Pricing wars. Vendor lock-in negotiation spirals.

Example 2 — Software: Feature parity races with a competitor — each adding features to match the other, neither driven by user need, both making their products bloated. Alerting system bloat — every postmortem adds alerts; alert fatigue increases; incidents missed; postmortems add more alerts.

Example 3 — HR: Salary ratchet between two companies competing for the same talent pool.

Canonical intervention:

• Unilateral de-escalation (break the symmetry; one side absorbs a round without responding, with explicit signaling).
• Reframe the goal (compete on a different axis).
• Find a higher-order cooperation (both sides benefit from stopping).
• Recognition that the loop is operating — naming it publicly changes behavior.

---

6. Success to the Successful

Loop structure: Two reinforcing loops sharing a finite resource, competing.

Behavior: Initial small advantages compound into structural dominance. The winner wins bigger over time. The loser's resource atrophy is self-confirming.

Recognition: "The rich get richer" operating as a structural feature, not an accident. "Team A has 3 PMs and Team B has none, even though Team B is more strategic."

Example 1 — Finance: Capital markets (returns attract capital, larger capital base earns larger returns). Network effects (larger network more valuable, attracts more users).

Example 2 — Organizational: Teams with good reputations get allocated the interesting projects, develop more skill, get better reputations. Teams with poor reputations get the maintenance work, further eroding reputation.

Example 3 — Products: Two products sharing an engineering team. Product A ships fast, gets more engineers, ships faster. Product B starves despite strategic importance.

Canonical intervention:

• Change allocation from competitive (winner takes more) to independent (each gets what it needs).
• Explicit portfolio policy; rotation requirements; resource floor.
• Measure absolute value, not relative — prevent relative comparison from determining allocation.
• External regulations (antitrust) are attempts to break this loop at scale.

---

7. Drifting Goals (a.k.a. Eroding Goals)

Loop structure: Two balancing loops — one improving performance, one reducing the goal.

Behavior: Goal is set. Reality falls short. Instead of closing the gap, the goal is lowered. Repeated indefinitely, "quality" or "standard" drifts downward. The path of least resistance is always lowering the goal.

Recognition: "We've had to be realistic about what's achievable" — repeated over years. "We used to care about X, but we've learned to be realistic."

Example 1 — Software: Customer response time SLAs. Target was 2 hours. Consistently missing. Quietly raised to 4 hours. Missing that. Raised to 8 hours. Customer churn begins — the degradation was invisible inside the loop.

Example 2 — Software quality: Team sets defect-per-release target of 10. Release ships with 25. Instead of fixing process (hard), team reclassifies 15 as "known issues" (easy). Next release targets 25. Standards drift downward indefinitely.

Example 3 — Ops: Test suite runtime used to be 2 min; drifted to 20 min; now nobody tests locally.

Canonical intervention:

• Anchor goals to external reference points (industry benchmark, competitor, first-principles calculation).
• Make drift visible — dashboard the historical goal line; show the erosion.
• Build capacity to close the gap rather than lower the goal.
• Separate the goal-revision process from the performance process.
• Require explicit approval for goal changes at a level above those affected by the gap.

---

8. Growth and Underinvestment

Loop structure: R (growth) + B (limiting constraint) + second B (capacity investment that could expand the limit, but only if investment is made).

Behavior: Growth is strong, approaches limits. If investment in capacity is made, limits recede, growth continues. If investment is not made (because limits haven't fully activated yet, or because short-term costs are visible while long-term benefits are not), limits bite hard. Growth stalls. Investment no longer feels justified.

Recognition: "We'll invest in capacity after we see the growth sustain." Onboarding is overwhelmed; support queue always behind.

Example 1 — Infrastructure: Cloud infrastructure scaling decisions. Team that doesn't expand capacity until performance degrades. By the time it degrades, investment timeline (hiring, training, provisioning) is 6-12 months.

Example 2 — Support: Customer support team stays flat as user base 5x's. Response times crater. Churn rises. Growth stalls. "No need for more support, growth is flat."

Example 3 — Talent: Talent pipeline investment. Technical platform investment as product grows.

Canonical intervention:

• Invest in capacity before it is needed, using leading indicators of the limiting constraint rather than lagging indicators of its activation.
• Measure capacity as a leading indicator, not a lagging one.
• Accept that capacity investment must exceed current load.
• Investment triggers tied to forward-looking metrics, not lagging performance metrics.

---

9. Accidental Adversaries

Loop structure: Two parties who should cooperate have hidden reinforcing loops working against each other.

Behavior: Two parties with aligned goals end up working against each other. Each party's local fix creates friction for the other. Communication collapses into blame.

Recognition: "Infra and product used to work together. Now each protects its own territory."

Example 1 — Org: Platform team optimizes for stability (rejects risky launches); product team optimizes for velocity (works around platform). Each action makes the other's job harder.

Example 2 — Platform/ecosystem: Platform adds features to compete with developer apps (captures more value). Developers lose revenue, trust platform less, invest less in ecosystem. Platform loses ecosystem richness. Platform doubles down on first-party features. Spiral.

Canonical intervention:

• Surface the hidden dependency.
• Make shared goal explicit and measurable.
• Create a shared scoreboard where both succeed or fail together.
• Explicit interfaces and contracts replace informal cooperation.

---

10. Policy Resistance

Loop structure: A policy / intervention is resisted by the system — multiple actors adjust behavior to neutralize it. Net effect: little or no change, often with negative side effects.

Behavior: Intervention had no measurable effect. Unintended workarounds appeared. Metric is gamed.

Recognition: "We added the control; nothing changed; people just routed around it." Goodhart's Law in action.

Example 1 — Software: Code review policy to reduce bugs. Developers add LGTM without reading. Bug rate unchanged.

Example 2 — Public policy: Speed cameras cause drivers to accelerate between them. Performance management systems produce metric-gaming rather than performance improvement.

Example 3 — Product: Rate limit to stop abuse creates workarounds (sign up 100 accounts, distribute load) rather than stopping abuse.

Canonical intervention:

• Understand who is resisting and why (their incentives).
• Align with the resistors' incentives rather than fighting them.
• Change the goal, not the control.
• Redesign the measurement so it captures the true quality, not a proxy.

---

Recognition Guide

Attribution

Systems archetypes: Peter Senge, The Fifth Discipline (1990); Senge, Goodman, Kiefer, Kemeny codification. William Braun, The System Archetypes (MIT CTL, 2002). Original case studies: System Dynamics Society; Pegasus Communications.

SystemsThinking — Foundation

Canonical reference on the theorists and frameworks behind this skill. Load on demand when depth is needed beyond the workflows.

The Four Layers — Iceberg Model

The Iceberg Model holds that observable events are the tip of a much larger causal structure. Most of visible reality — incidents, crises, data points — are surface manifestations of patterns, which are produced by structural arrangements, which are themselves anchored in mental models. Interventions at the event level are the least powerful. Interventions at the mental model level are the most durable.

The model maps almost directly onto Meadows' leverage point hierarchy: events correspond to parameters (LP 12), patterns expose feedback loops (LP 6-8), structures encode rules and goals (LP 3-5), and mental models are paradigms (LP 1-2).

Level 1 — Events (above the waterline)

• What: A single observable incident. A server outage. A product launch failure. A policy reversal.
• Reactive posture: firefighting, symptom relief, press releases.
• Diagnostic questions: What happened? When? To whom?
• Common mistake: Treating events as causes rather than outputs. Every event is downstream of structure.

Level 2 — Patterns (just below surface)

• What: Trends over time. Recurring behaviors. Seasonal cycles. Escalating curves. The same argument repeated at every quarterly review.
• Adaptive posture: trend analysis, anticipation, early warning systems.
• Diagnostic questions: Have we been here before? What does the time-series show? Where is this heading if nothing changes?
• Common mistake: Pattern-matching to the wrong archetype. Seeing a reinforcing loop where a balancing loop with delay is actually producing oscillation.

Level 3 — Structures (mid-depth)

• What: The causal architecture producing patterns. Feedback loops, information flows, incentive systems, physical constraints, decision rules, org hierarchies, resource allocation formulas.
• Generative posture: redesign, restructuring, new feedback mechanisms.
• Diagnostic questions: What feedback loops are operating? Who gets what information when? What incentives are encoded? What delay exists between action and consequence?
• Common mistake: Focusing exclusively on formal structures (org charts, written policies) and ignoring informal structures (who actually talks to whom, what gets rewarded regardless of policy).

Level 4 — Mental Models (deepest)

• What: The shared assumptions, worldviews, beliefs, and values that people use to construct the structures that produce the patterns that generate the events. "Growth is always good." "Markets self-correct." "Hierarchy produces accountability." These are rarely articulated.
• Transformative posture: surfacing assumptions, dialogue, paradigm shifts.
• Diagnostic questions: What would you have to believe for this structure to make sense? What assumptions are so obvious nobody questions them? Who benefits from the current mental model?
• Common mistake: Attempting to change mental models through argument and logic alone. Mental models shift when people experience anomalies that the old model cannot explain, or when they see new models working in practice.

Feedback Loop Theory

Balancing Feedback Loop (B)

A closed causal chain containing an odd number of negative arrows. Goal-seeking. Always pushes toward a target state (explicit or implicit) and resists deviation from that target. The regulatory mechanism of systems — thermostats, immune responses, market clearing mechanisms, homeostatic physiology.

Behavior signature: If undisturbed, approaches equilibrium asymptotically. If a delay exists in the loop, oscillates around equilibrium. If multiple delays, can produce sustained oscillation or instability.

Critical insight: every balancing loop has an implicit or explicit goal. The loop behavior is generated by the gap between goal and current state. Change the goal, change the loop behavior.

Reinforcing Feedback Loop (R)

A closed causal chain containing an even number of negative arrows (including zero). Amplifies whatever is happening. Produces compound growth or compound collapse. Uncontrolled reinforcing loops are the mechanism of exponential growth and of runaway failures.

Behavior signature: Accelerating change in one direction (up or down) until a balancing loop activates or an external limit is reached.

Stock and Flow Notation (Forrester)

CLDs show qualitative structure. Stock-and-flow diagrams add quantitative precision.

• Stock: Accumulated quantity at a point in time. Rectangle. Bank balance, population, inventory, trust. Changes only through flows. Stocks create inertia and memory.
• Inflow: Rate adding to stock. Pipe with valve pointing into rectangle. Births, sales, hiring rate.
• Outflow: Rate draining stock. Pipe with valve pointing out of rectangle. Deaths, refunds, attrition.
• Auxiliary variables: Intermediate calculations affecting flows.
• Constants: Fixed parameters, usually calibrated from data.

Key rule: Stocks cannot change instantaneously. This is why systems have inertia. You cannot instantly hire 500 engineers, immediately reduce CO2 concentration, or overnight rebuild customer trust.

Unintended Consequences Patterns

Policy Resistance

The tendency for system interventions to be defeated by the system's response to the intervention. The system pushes back. From Sterman (Business Dynamics, 2000): "Policy resistance arises from complex system dynamics, leading to unintended consequences of interventions."

Mechanism: Any intervention in a system with feedback changes the system's behavior, which changes the conditions that motivated the intervention. Actors in the system respond to the intervention in ways that partially or fully offset it.

Classic examples:

• Rent control reduces housing costs in the short term, decreases housing supply in the long term, worsening the affordability problem.
• Speed limits enforced through cameras cause drivers to accelerate between cameras.
• Performance management systems produce gaming of the metrics rather than improvement of the underlying performance.

Pattern: The more precisely you target a metric in a complex system, the more the rest of the system reorganizes to maintain the metric while undermining the underlying goal. Goodhart's Law is policy resistance operating at the measurement level.

Accidental Adversaries

Two parties whose actions are individually rational and well-intentioned, but whose second-order effects on each other create a mutually damaging reinforcing loop neither intended.

Mechanism: Party A's actions have unintended side effects on Party B. B responds to protect itself. B's response has unintended side effects on A. A responds. Both become adversaries despite shared interests.

Example: Platform and third-party developers. Platform adds features to compete with developer apps. Developers lose revenue, trust platform less, invest less in the ecosystem. Platform loses ecosystem richness, making it less attractive. Platform doubles down on first-party features. Ecosystem further degrades. Both lose.

Intervention: Map the complete causal structure including second-order effects. Establish explicit communication about unintended impacts before they activate defensive responses.

Fixes That Fail (cognitive)

Research by Sterman (1989) shows that even trained managers systematically underestimate the effects of delays in feedback systems when managing simulated systems. The implication: humans are cognitively biased toward fixes that fail. Systems thinking is the countermeasure.

Key Practitioners

Donella Meadows (1941-2001)

• Limits to Growth (1972, co-authored with Dennis Meadows, Jørgen Randers, William Behrens)
• Thinking in Systems (2008, posthumous)
• "Leverage Points: Places to Intervene in a System" (1999, Whole Earth) — freely available at donellameadows.org

Her framing of stocks, flows, feedback loops, and leverage points is the canonical quantitative foundation for modern systems thinking. The leverage points essay is the single most cited systems thinking document.

Peter Senge

• The Fifth Discipline (1990)
• The Fifth Discipline Fieldbook (1994, with others)

Synthesized system dynamics from Forrester with organizational learning theory. Introduced the "five disciplines" framework and codified (with Goodman, Kiefer, and Kemeny) the systems archetypes as a practical vocabulary for organizational analysis. Remains the entry point for most organizational systems thinking practitioners.

Jay Forrester (1918-2016)

• Industrial Dynamics (1961)
• Urban Dynamics (1969)
• World Dynamics (1971)

Invented system dynamics and the stock-and-flow notation at MIT. Founded the System Dynamics Society. His core claim: counterintuitive behavior of complex systems is not mysterious — it is the predictable output of feedback loop structure. Modern tool chain: Vensim, Stella (direct descendants of his Dynamo simulation language).

Russell Ackoff (1919-2009)

• Redesigning the Future (1974)
• Re-Creating the Corporation (1999)
• Systems Thinking for Curious Managers (2010)

Introduced the concept of the "mess" — an interconnected system of problems that cannot be solved by decomposing them into parts. His core distinction: problems can be solved, messes must be dissolved (by redesigning the system that generates them). Interactive planning (idealized redesign) is his methodology. F-Laws are his 100+ distilled observations on organizational dysfunction.

Fritjof Capra

• The Tao of Physics (1975)
• The Web of Life (1996)
• The Systems View of Life (2014, with Pier Luigi Luisi)

Bridges systems thinking, ecology, and living systems theory. His contribution: all living systems are networks of autopoietic (self-producing) components; understanding them requires relational thinking, not reductionist decomposition. Less quantitative than Forrester/Meadows but influential in framing systems thinking as a philosophy of science, not just a modeling technique.

Joseph Novak

• Learning How to Learn (1984, with D. Bob Gowin)
• Learning, Creating, and Using Knowledge (1998)

Developed concept mapping as a knowledge representation technique grounded in David Ausubel's cognitive learning theory. Tool: CmapTools (free, ihmc.us/cmaptools).

John Sterman

• Business Dynamics: Systems Thinking and Modeling for a Complex World (McGraw-Hill, 2000)

The modern comprehensive reference for system dynamics practice. Sterman's (1989) behavioral research on managerial decision-making in dynamic systems is the foundation for understanding why humans are systematically bad at reasoning about feedback and delay.

When Systems Thinking is the Wrong Tool

• The problem is genuinely complicated rather than complex. A complicated problem (e.g., "our database query is slow") has a knowable cause-effect chain. Decompose it, analyze the parts, fix the bottleneck. No feedback loops needed.
• Speed is the only constraint. In acute crisis, the firefighting response (event-level) is correct. Systems analysis during an outage is malpractice. Fix first, analyze after.
• The Cynefin domain is Simple (Clear). Best practices exist, cause-effect is obvious, and applying the practice is sufficient. Overthinking simple domains with systems models wastes time.
• Stakeholders cannot agree on system boundaries. A CLD built on contested variable definitions is worse than no CLD — it provides false precision while obscuring the real disagreement.
• The organization lacks the capacity to act on structural interventions. If mental model and structural changes are not politically possible, identifying them as leverage points produces frustration, not change. Sometimes the achievable intervention is a parameter (LP 12), and that is the correct choice given constraints.

Source Reference

• Meadows, D. (1997/1999). "Leverage Points: Places to Intervene in a System." Donella Meadows Project. donellameadows.org
• Meadows, D. (2008). Thinking in Systems. Chelsea Green Publishing.
• Senge, P. (1990). The Fifth Discipline. Doubleday.
• Braun, W. (2002). "The System Archetypes." MIT CTL. ctl.mit.edu
• Novak, J. & Cañas, A. (2008). "The Theory Underlying Concept Maps." IHMC. cmap.ihmc.us
• Forrester, J. (1961). Industrial Dynamics. MIT Press.
• Sterman, J. (2000). Business Dynamics. McGraw-Hill.
• Ackoff, R. (1999). Re-Creating the Corporation. Oxford University Press.
• Capra, F. (1996). The Web of Life. Anchor Books.

SystemsThinking — Meadows' 12 Leverage Points (Reference)

Donella Meadows, "Leverage Points: Places to Intervene in a System," Whole Earth 1999; expanded in Thinking in Systems (2008). Ordered from least leverage (12) to most (1). Reversed from how most people instinctively attack a problem — which is why most interventions fail.

Counterintuitive point: Meadows explicitly noted that people fight hardest over LP 12 (parameters) and ignore LP 1-3 (paradigms, goals, self-organization). The most powerful leverage points are the least visible and the most resisted when threatened.

---

12. Constants, Parameters, Numbers

What: Subsidies, taxes, standards, capacity limits, retry counts, SLA thresholds, minimum wage, quota sizes.

Meadows: "They rarely change behavior."

Why weakest: Parameters rarely change system structure. They shift where equilibrium sits but don't change the generating dynamics. Politicians love them because they're visible; systems mostly ignore them.

When actually useful: When the parameter is a threshold that triggers a structural effect (e.g., a rate limit that changes resource contention dynamics, or a capacity number that's small enough to force queue formation).

Example — software: Changing a timeout from 5s to 10s. Won't change the underlying latency distribution; just shifts where failure surfaces.

---

11. Buffers — The Size of Stabilizing Stocks

What: Inventory, cash reserves, queue depths, cache sizes, team slack, battery capacity.

Why moderate: Buffers stabilize but don't change generating dynamics. Too large = expensive, slow to respond. Too small = fragile.

When useful: When a buffer is too small to absorb normal variation, fixing size is genuinely structural. Also: strategically-placed buffers (between stages of a pipeline) can decouple failure modes.

Example — software: Increasing a Kafka topic's retention. Absorbs spikes; doesn't fix producer/consumer imbalance but prevents it from being fatal.

---

10. Structure of Material Stocks and Flows

What: Physical topology — pipelines, networks, road layouts, org charts, service graphs, population age structure.

Why moderate: Changing physical structure has real effect but is often extremely expensive and slow. You usually can't change it without rebuilding.

When useful: Architecture decisions, re-orgs, platform migrations. When you can change the structure, do so deliberately — the structure you pick will generate behavior for years.

Example — software: Monolith → microservices (or reverse). Structural change, massive impact, massive cost. Rarely the right leverage point within an existing system.

---

9. Lengths of Delays, Relative to Rates of Change

What: Perception delays, decision delays, action delays, feedback delays.

Why strong: Delays cause oscillation, overshoot, and surprise. Reducing the feedback delay can fix behavior that no parameter change fixes.

When useful: Any system with oscillation or overshoot — deploy pipelines that swing between "deploying everything" and "deploying nothing"; alerting that oscillates between noisy and silent; supply chain with bullwhip effect.

Example — software: p99 monitoring on a 5-minute rolling window vs. 1-hour. The shorter window lets you respond before the incident escalates.

Example — management: Quarterly performance reviews vs. weekly 1:1s. The delay between behavior and feedback determines what behavior the system produces.

---

8. Strength of Negative (Balancing) Feedback Loops

What: The corrective force relative to the disturbance it corrects.

Why strong: Weak negative loops produce underdamped oscillation or loss of control. Strong ones stabilize.

When useful: Scaling incidents, runaway dynamics, quality decay — look for the balancing loop and ask "why isn't it strong enough?"

Example — markets: Market price signals are a balancing loop. When they're weakened (information asymmetry, externalities), the system loses its self-correcting capacity.

Example — software: Autoscaler with slow reaction time. Reinforcing loop of traffic growth overwhelms it. Strengthen the balancing loop: faster scale-up, more predictive, lower trigger threshold.

---

7. Gain Around Driving Positive (Reinforcing) Feedback Loops

What: The speed and strength of self-amplifying loops.

Why strong: Reinforcing loops drive exponential change. Slowing runaway reinforcing loops (poverty traps, wealth concentration, viral spread, technical debt accretion) is more powerful than strengthening corrective mechanisms.

When useful: Growth dynamics, tech debt, alert fatigue, learning cycles. Attack the gain directly rather than fight downstream.

Example — software: Onboarding speed determines how fast new hires contribute, which determines how fast they mentor the next hires. Strengthen this R loop and team velocity compounds.

Example — social: Viral content spread, wealth concentration, addiction dynamics.

---

6. Structure of Information Flows — Who Has Access to Information

What: Dashboards, feedback channels, transparency, visibility.

Why strong: Behavior changes when information becomes visible to the people whose behavior matters. The structure is the same; the information flow is different.

Meadows' famous example: Moving an electric meter from the basement to the hallway reduced household energy consumption by 30%. No policy, no incentive, no rule change — just visible information.

Another Meadows example: The Toxics Release Inventory made industrial pollution public — reduction followed without regulation.

When useful: When actors would make different decisions if they could see what they can't currently see. Very common.

Example — software: Showing engineers their own code's production error rate (not just the team average). Behavior changes without any policy or incentive change.

Example — ops: Runbooks with success rates. Failure modes published. Status pages.

---

5. Rules of the System — Incentives, Punishments, Constraints

What: Written rules, laws, contracts, policies, norms.

Why strong: Rules shape all downstream behavior. Change the rule and the whole game changes. Meadows: "Power over the rules is real power."

When useful: When behavior is rational given current rules. The rule is the generator.

Example — software: A "no code merged without two approvals" rule changes the entire PR review dynamic. Leverage is at the rule, not at individual reviews.

Caveat: Rules face policy resistance (archetype 10). Actors game them. Rules need to align with underlying incentives or they fail.

---

4. Power to Add, Change, Evolve, or Self-Organize System Structure

What: The system's capacity to reshape itself — evolution, learning, adaptation, restructuring.

Why very strong: A self-organizing system is resilient because it can change its own rules in response to conditions.

When useful: Platforms, marketplaces, organizations that need to adapt faster than central control can plan.

Example — software: A team that can restructure itself (shift ownership, split services, change rituals) without leadership approval. Adapts to load much faster than one that can't.

Example — biological: Evolution. Immune system adaptation. Any system that genetically encodes adaptive capacity.

Destroying this capacity (eliminating diversity, concentrating power, locking in structure) eliminates the system's ability to adapt. This is often done "for efficiency" and produces brittleness.

---

3. Goals of the System

What: What the system is for — the purpose it's optimized toward.

Why very strong: The goal determines which of the lower-leverage points matter and how they're used. Change the goal and the whole system realigns.

Critical: Not what actors say the goal is — what the system actually optimizes for. Infer from where resources flow, what metrics are watched, what behaviors are rewarded.

When useful: When the system is optimizing for the wrong thing — maximizing feature velocity when the real need is user trust; maximizing uptime when the real need is experimentation.

Meadows: Reagan shifted US governance goals in a specific direction and "swung hundreds of thousands of people in new directions." Goal changes propagate through all subordinate structures.

Example — software: Changing a team's goal from "feature ship rate" to "user-reported quality." Everything below (rules, information flows, parameters) realigns.

---

2. Mindset or Paradigm Out of Which the System Arises

What: The shared assumptions, beliefs, worldviews so fundamental they are invisible. "Nature is a resource to be used." "GDP growth is progress." "Hierarchy is accountability." "Software teams should ship fast."

Why extremely strong: Paradigms produce goals, rules, information structures, and stocks. Change the paradigm and you change everything below it. The whole system is regenerated.

When useful: Rarely immediate, always durable. Long-term transformations — shifts from "software as a product" to "software as a service"; from "move fast break things" to "move fast with stable infrastructure."

Example: The DevOps paradigm shift (dev and ops are one) vs. the prior paradigm (dev writes, ops runs). Changed the goals, rules, structures, and information flows of software engineering.

Example: "Security is the security team's job" → "Security is everyone's job." Paradigm shift, cascades into structure, information flow, hiring, training, and rules.

---

1. Power to Transcend Paradigms

What: The capacity to hold paradigms loosely, to recognize that no paradigm is "true," only more or less useful for a purpose.

Why most powerful: A practitioner who can step outside any paradigm can choose the right one for the situation rather than being trapped in one.

Meadows: "It is in this space of mastery over paradigms that people throw off addictions, live in deliberately chosen ways, and step off the edge of the world into entirely new ways of being."

When useful: Crises, strategic pivots, fundamental re-imagining. Rarely applicable to routine problems.

Example — software: Recognizing that "the cloud" is a paradigm, not reality. For some workloads, on-prem is correct. For some, serverless. For some, bare metal. The practitioner who holds "cloud is default" loosely picks better.

Example — business: Operating in a startup paradigm when growth mode, and a stability paradigm when scaling — knowing which paradigm fits the phase.

---

Applied Selection

Rule of thumb: Prefer the highest Meadows level that is feasible within the time and political budget. Don't waste cycles on parameter changes when a rule change is feasible.

Bundle strategy: A low-level tactical intervention (buy time) plus a high-level structural one (change the generator) is often optimal. The tactical patches; the structural fixes.

Resistance increases with leverage. LP 2-3 interventions face the most resistance because they threaten existing power and belief structures. Plan for the fight; don't be surprised by it.

Second-order effects scale with leverage. An LP 12 change rarely has surprises. An LP 3 change reshapes the downstream system. An LP 2 change reshapes everything. Always run a CausalLoop analysis for LP ≤ 5 interventions before committing.

Attribution

Donella Meadows, "Leverage Points: Places to Intervene in a System." Whole Earth (1999). Full text: donellameadows.org. Expanded in Meadows, Thinking in Systems (Chelsea Green, 2008). The 12-point list is canonical; minor ordering variations appear across sources, but the overall ranking is stable.

CausalLoop Workflow — SystemsThinking

Purpose

Build a Causal Loop Diagram (CLD) of the system in question — variables connected by arrows labeled with polarity, organized into reinforcing (R) and balancing (B) loops. The CLD makes the generators of behavior visible in a way prose cannot.

CLDs are the working language of system dynamics (Forrester, Meadows, Senge). They let you simulate second- and third-order effects before committing to an intervention.

Invocation

Invoked for:

• Mapping the dynamics behind a recurring behavior (usually after Iceberg finds a structural generator)
• Previewing unintended consequences of a planned intervention
• Explaining why a counterintuitive dynamic occurs (growth stalls, quality decays, "fixes" fail)
• Any problem where multiple variables interact with delays

Notation

  A  ──(+)──▶  B        A increases → B increases (same direction)
                         A decreases → B decreases

  A  ──(−)──▶  B        A increases → B decreases (opposite direction)
                         A decreases → B increases

  A  ═══(+/−)═══▶  B    Same as above but with a DELAY (drawn thicker or with ||)


  Loop labels:
  (R) Reinforcing — same-direction cycle, amplifies change, exponential
  (B) Balancing — opposite-direction cycle, goal-seeking, stabilizes

Polarity test for arrows:

• Change A. Does B change in the same direction? → (+)
• Change A. Does B change in the opposite direction? → (−)

Loop-type test (count the minus signs):

• Even number (including 0) of (−) arrows in the loop → Reinforcing (R)
• Odd number of (−) arrows in the loop → Balancing (B)

Execution

Step 1: State the Question

Every CLD is built to answer a specific question. Without the question, the diagram sprawls.

QUESTION: [Specific question the CLD should answer]

Examples:

• "Why does our release velocity plateau past a certain team size?"
• "What happens if we double the rate limit?"
• "Why does tech debt accelerate even though we pay some down each quarter?"

Step 2: Identify Variables

List 5-15 variables — quantities that can increase or decrease over time.

Variables must be:

• Nouns or noun phrases, not verbs ("Team size" not "Hiring")
• Directional (can go up or down)
• Observable or inferable

Include "soft" variables. Trust, morale, perceived urgency, customer satisfaction all matter. Drop them only if they genuinely don't influence the dynamics — not because they're hard to measure.

Fewer, high-quality variables beat exhaustive lists. Start with the 5-7 that matter most; add as needed.

Step 3: Draw the Arrows

For each pair of variables, ask: does a change in A directly cause a change in B?

• Direct causation only — no "A correlates with B"; no "A causes C causes B" as a single arrow (draw it through C)
• Polarity — assign (+) or (−)
• Delay — mark with ═══ or || if the effect takes significantly longer than the rhythm of the system

Sanity check each arrow — can you describe the mechanism in one sentence? If not, the arrow is probably wrong.

Step 4: Identify Loops

Trace cycles that return to their starting variable. For each loop:

1. Count the (−) arrows 2. Label R if even, B if odd 3. Give it a short, descriptive name ("Success-to-success," "Coordination tax," "Capacity drift")

Every loop has a name. Un-named loops are untracked. The name captures the dynamic, not the variables.

Step 5: Interpret the Dynamics

For each loop, answer:

• Reinforcing: What does this loop amplify? Toward what limit?
• Balancing: Toward what goal does this loop pull? What sets the goal?
• Delay: Where are the delays, and what behavior do they produce (oscillation, overshoot, slow response)?

Identify dominant loops — which loops are driving behavior right now? Which will dominate as variables change?

Many real-world behaviors flip: reinforcing loop dominates early (growth), balancing loop dominates later (limits). This is the "limits to growth" archetype.

Step 6: Stress-Test Interventions

Before recommending a change, simulate it on the CLD:

PROPOSED INTERVENTION: [change to a variable, a flow, or a loop]

Trace the effect:
- Directly affected variable: [X goes up/down by how much]
- First-order downstream: [what changes next, via which arrows]
- Second-order: [loops now pull differently, what behavior emerges]
- Third-order: [after delays complete, what's the new equilibrium]

Unintended consequences: [which balancing loop resists? which reinforcing loop accelerates?]
Side effects: [variables changed that weren't targeted]

Every non-trivial intervention triggers at least one balancing loop. If you can't find it, you haven't looked hard enough.

Step 7: Output

🔄 CAUSAL LOOP DIAGRAM: [topic]

QUESTION: [what this CLD answers]

VARIABLES:
- [var1], [var2], [var3], ...

ARROWS (source → target, polarity, delay?):
- [A] →(+) [B]
- [B] →(−) [C] (delay)
- ...

LOOPS:
- R1 "Success-to-success": A → B → C → A (reinforcing)
  Dynamic: amplifies early wins, accelerates until limit
- B1 "Coordination tax": A → D → E → A (balancing)
  Dynamic: opposes growth, scales with team size

DOMINANT LOOP: [which is driving behavior now]
EMERGING DOMINANT LOOP: [which will dominate as system grows]

INTERVENTION ANALYSIS:
- Proposed: [X]
- Intended effect: [Y]
- Unintended: [which loop pushes back]
- Recommended: [attack the balancing loop directly, or accept tradeoff]

Worked Example — Team Growth Paradox

QUESTION: Why does engineering velocity plateau past team size 12-15?

VARIABLES:
- Team size
- Output (features shipped/week)
- Hiring budget
- Pending features backlog
- Coordination cost per engineer
- Per-engineer output
- Onboarding load

ARROWS:
- Team size →(+) Total output
- Total output →(+) Revenue/success
- Revenue →(+) Hiring budget
- Hiring budget →(+) Team size  (delay: hiring pipeline)
- Pending features →(+) Hiring budget
- Team size →(+) Coordination cost per engineer
- Coordination cost →(−) Per-engineer output
- Per-engineer output →(+) Total output
- Team size →(+) Onboarding load
- Onboarding load →(−) Per-engineer output (delay: ramp-up period)

LOOPS:
- R1 "Success → hiring → output": Team size → Total output → Revenue → Hiring budget → Team size (reinforcing; drives growth)
- B1 "Coordination tax": Team size → Coordination cost → Per-engineer output → Total output → (pulls back against R1 via less hiring demand pressure)
- B2 "Onboarding drag": Team size → Onboarding load → Per-engineer output → Total output (balancing, delayed)

DOMINANT LOOP: R1 dominant early; B1 and B2 dominant once team > 12.

INTERVENTION ANALYSIS:
- Proposed: hire more engineers to ship more features.
- Intended: Total output ↑
- Unintended: Coordination cost ↑ faster than Total output; at some point Total output flat-lines or declines (policy resistance)
- Recommended: Don't attack R1 (slowing hiring just slows the dynamic). Attack B1 directly: invest in coordination mechanisms (async docs, modular architecture, team topology) that break the "team size → coordination cost" arrow.

This is Meadows' "Limits to Growth" archetype — see FindArchetype workflow for the canonical intervention template.

CLD Conventions

• Horizontal layout when possible; feedback loops naturally form ovals
• Reinforcing loops often drawn with circular arrow symbol ↻ in center with "R"
• Balancing loops often drawn with "=" or scales symbol with "B"
• Delays drawn with double lines on the arrow ═══ or ||
• Exogenous variables (outside the model) drawn without incoming arrows, in a distinct color/shape
• Stocks (accumulations) vs Flows (rates) — advanced stock-and-flow notation; use when the CLD underdetermines behavior

Rendering via Art Skill

To render a CLD as an actual diagram:

# Use Art skill with Mermaid or diagram rendering
Skill("Art", "Mermaid flowchart showing causal loop diagram with R1 and B1 loops, variables: [list], arrows with polarity: [list]")

Common Mistakes

• Too many variables. A 20-variable CLD is illegible. Start with 5-7; add only if the loops don't reproduce observed behavior.
• Correlation drawn as causation. Every arrow needs a mechanism. "They move together" isn't enough.
• Missing delays. Most "surprise" dynamics come from unacknowledged delays. When behavior oscillates or overshoots, look for a delay you didn't mark.
• Drawing only reinforcing loops. Real systems always have balancing loops somewhere. If your CLD has none, you've missed something.
• Static snapshot, not dynamic. The CLD is a generator of behavior over time, not a state diagram.
• Confusing event causation with structural causation. "The deploy caused the outage" is event-level; the CLD should show why the deploy process causes outages repeatedly.

Integration

• Feeds FindLeverage — once the CLD is drawn, Meadows' leverage points apply (which variable, arrow, loop, or boundary gives the most leverage).
• Feeds FindArchetype — many CLDs match a named archetype; if so, use the canonical intervention.
• Called from Iceberg when Layer 3 structure is a feedback loop.
• Renderable via Art — Mermaid / diagram output.

Attribution

Causal Loop Diagrams: Jay Forrester (Industrial Dynamics, 1961), Dennis Meadows et al. (Limits to Growth, 1972), Peter Senge (The Fifth Discipline, 1990). Modern reference: John Sterman, Business Dynamics (2000).

ConceptMap Workflow — SystemsThinking

Purpose

Build a concept map — a visual network of entities and their labeled relationships — to understand a domain's structure. Unlike causal loop diagrams (which model dynamics), concept maps model relationships and semantics. Use them when you're trying to understand "what are the things, and how are they connected?"

Concept maps come from Joseph Novak's work on meaningful learning (Cornell, 1972). The key invariant: every link is a labeled proposition, not just an arrow.

Invocation

• "Concept map"
• "Map the entities"
• "Relationship map"
• "Novak-style mapping"
• Early-stage domain exploration, onboarding docs, architecture overviews, knowledge capture

Not for: dynamic behavior (use CausalLoop), incident causation (use RootCauseAnalysis), hierarchical decomposition (use an outline or tree).

The Structure

[CONCEPT A]  ──"contains"──▶  [CONCEPT B]
    │
    │"interacts with"
    ▼
[CONCEPT C]  ──"depends on"──▶  [CONCEPT D]

Components:

• Concepts — nodes, usually nouns or noun phrases, enclosed in boxes
• Links — labeled edges, describing the relationship between concepts
• Propositions — concept + link + concept reads as a short statement: "Concept A contains Concept B"
• Cross-links — links between concepts in different parts of the map, revealing non-obvious connections (these are often the most valuable insights)
• Hierarchy — most general concepts at top, specifics at bottom (not strictly required but helpful)

Execution

Step 1: Define the Focus Question

Every concept map answers a question. Without the question, the map becomes a disorganized bag of concepts.

FOCUS QUESTION: [Specific question the map should answer]

Good examples:

• "How does authentication flow through our platform?"
• "What are the components of the PAI Algorithm, and how do they relate?"
• "What does H3 consist of, and how do the pieces depend on each other?"

Bad examples:

• "What is authentication?" (too broad)
• "Show me the auth architecture" (not a question)

Step 2: List Key Concepts

Extract 10-30 concepts from the domain. Order by generality — most general first, most specific last.

Concepts should be:

• Nouns or noun phrases — "User session," "JWT token," "OAuth provider"
• At roughly similar levels of abstraction — don't mix "cloud computing" with "HTTP header"
• Concrete enough to have relationships — "good architecture" is too vague to map

Step 3: Draft the Hierarchy

Arrange concepts from general (top) to specific (bottom). This is the conceptual hierarchy — it gives the map spatial structure.

If no hierarchy emerges, that's a signal: either the concepts are all at the same level (flat map, no hierarchy needed), or you're missing organizing concepts (add them).

Step 4: Draw Labeled Links

For each pair of related concepts, draw a link labeled with the relationship. Common link types:

"contains", "has", "is a", "is part of"
"uses", "depends on", "requires"
"produces", "creates", "results in"
"triggers", "responds to", "listens for"
"reads from", "writes to"
"authenticates", "authorizes", "validates"
"owns", "manages", "monitors"
"extends", "overrides", "implements"
"precedes", "follows", "parallels"

Every link must form a valid proposition when read concept-link-concept. If "User session [uses] JWT token" is true, the link is valid.

Step 5: Find Cross-Links

Cross-links connect concepts in different regions of the map — relationships that aren't obvious from the hierarchy.

Cross-links are the highest-value output of concept mapping. They reveal non-obvious relationships, hidden dependencies, and unexpected interactions.

Example cross-link in a software architecture map: between "database connection pool" (bottom of data layer) and "request timeout policy" (middle of application layer). The cross-link "feeds back into" reveals that pool exhaustion affects timeout behavior — non-obvious unless the map is drawn.

Step 6: Review for Completeness

Check:

• Focus question answered? Walk through the map trying to answer the focus question aloud.
• Propositions make sense? Read each link triplet; they should form grammatically valid statements.
• No orphan concepts? Every concept should have at least one link. Orphans suggest missing relationships.
• Cross-links present? If none, you may be missing the valuable non-obvious connections.
• Appropriate granularity? 10-30 concepts for most maps. Under 5 is too thin; over 50 is unreadable.

Step 7: Render

Concept maps benefit enormously from visual rendering. Use the Art skill:

Skill("Art", "Mermaid concept map with focus question [Q], concepts: [list], labeled links: [list], cross-links: [list]")

Mermaid or graphviz both work. Mermaid renders inline in most editors; graphviz produces higher-quality static images.

Output

📊 CONCEPT MAP: [topic]

FOCUS QUESTION: [...]

CONCEPTS (general → specific):
- [C1], [C2], ..., [Cn]

HIERARCHY:
  [C1]
    ├─ [C2]
    │   └─ [C5]
    └─ [C3]
        └─ [C6]

PROPOSITIONS (concept → [link] → concept):
- [C1] → [contains] → [C2]
- [C2] → [uses] → [C5]
- ...

CROSS-LINKS:
- [C5] → [feeds back into] → [C3] — reveals non-obvious dependency
- [C6] → [validates through] → [C2] — hidden validation path

KEY INSIGHTS:
- [Insight from cross-link 1]
- [Insight from cross-link 2]

Worked Example — PAI Algorithm Subsystems

FOCUS QUESTION: What are the subsystems of the PAI Algorithm, and how do they interact?

CONCEPTS (general → specific):
- Algorithm (root)
- Phases, ISC Quality System, ISA, Capabilities
- OBSERVE, THINK, PLAN, BUILD, EXECUTE, VERIFY, LEARN
- FeedbackMemoryConsult, Advisor, LiveProbe, ConflictSurfacing
- IterativeDepth, ApertureOscillation, FirstPrinciples, Council, RedTeam, Science, SystemsThinking, RootCauseAnalysis

PROPOSITIONS:
- Algorithm → [has phases] → {OBSERVE, THINK, ..., LEARN}
- Algorithm → [uses] → ISA
- Algorithm → [enforces] → ISC Quality System
- OBSERVE → [selects] → Capabilities
- Capabilities → [include thinking skills] → {IterativeDepth, FirstPrinciples, ..., SystemsThinking, RootCauseAnalysis}
- THINK → [invokes] → Thinking skills
- VERIFY → [enforces] → Verification Doctrine
- Verification Doctrine → [includes] → {LiveProbe, Advisor, ConflictSurfacing}
- PLAN → [begins with] → FeedbackMemoryConsult
- LEARN → [writes to] → Knowledge Archive

CROSS-LINKS:
- ISC Quality System → [gates exit of] → OBSERVE  (governance cross-link)
- Advisor → [re-invoked by] → ConflictSurfacing (recursion cross-link)
- LEARN → [informs future] → OBSERVE (next-session cross-link)

INSIGHTS:
- The Algorithm is not linear — OBSERVE and LEARN are connected across sessions via Knowledge Archive.
- The Verification Doctrine has an internal loop (ConflictSurfacing re-invokes Advisor), which is a first-order structural protection against motivated reasoning.
- Thinking capabilities are selected in OBSERVE but invoked in THINK — separation of concerns.

Common Mistakes

• Unlabeled arrows. An unlabeled arrow is just "somehow related." The label is the entire value.
• Too many concepts. Over 30-50 and the map is unreadable. Split into sub-maps by region.
• Mixed abstraction levels. "System" and "semicolon" in the same map is confusing. Keep concepts roughly homogeneous in scale.
• Missing cross-links. The hierarchy is the scaffolding; cross-links are the insight. A map without cross-links usually missed the interesting relationships.
• Trying to show causation. If arrows mean "causes," you want a CausalLoop diagram, not a concept map.
• Concepts that are verbs. "Running," "processing," "deploying" are activities, not concepts. Re-noun them: "Deployment," "Processing step."

When to Use vs. Other Diagrams

Integration

• Feeds Iceberg — Layer 3 (structure) often benefits from a concept map of the actors and relationships
• Feeds CausalLoop — concepts and relationships from the map inform variables and arrows
• Pairs with Knowledge skill — concept maps make excellent Knowledge Archive entries
• Rendered via Art skill — Mermaid, Graphviz, or d2

Attribution

Joseph D. Novak, concept map methodology developed at Cornell University (1972), building on David Ausubel's theory of meaningful learning. Canonical reference: Learning How to Learn (Novak & Gowin, 1984). Modern software: CmapTools (IHMC), Miro, d2, Mermaid.

FindArchetype Workflow — SystemsThinking

Purpose

Match the observed system behavior to one of the ~10 canonical systems archetypes. Archetypes are the recurring structural patterns that Senge and others codified: once you recognize the archetype, the canonical intervention is already documented. You don't have to reinvent it.

This is the fastest, highest-leverage systems-thinking workflow when the pattern is common — which it usually is.

Invocation

• "Systems archetype"
• "Fixes that fail," "shifting the burden," "tragedy of the commons," "limits to growth," "escalation" (user naming an archetype)
• "Why does this keep happening?" combined with clear recurring pattern
• After CausalLoop, to check whether the loop structure matches a known archetype

The Archetypes

1. Fixes That Fail (a.k.a. Fixes That Backfire)

Structure: Problem → Quick fix → Problem relieved (short term) → Unintended consequence → Problem worsens (long term).

Classic signs:

• A fix worked initially but the problem returned larger
• Each fix requires more force than the last
• Energy is spent on remediation rather than prevention

Recognition: "We keep fixing this and it keeps coming back bigger."

Canonical intervention:

• Identify the unintended consequence of the fix
• Find a fundamental solution that doesn't trigger the consequence
• Accept short-term pain to stop the cycle
• If a quick fix is unavoidable, explicitly time-box it and commit to a fundamental solution on a deadline

Example: Adding timeouts to flaky distributed calls. Short-term: calls complete. Long-term: timeouts mask real latency, services drift to worse performance, eventually total outage. Fix: address actual latency cause (often a database or an upstream bottleneck), not the symptom.

---

2. Shifting the Burden

Structure: A problem can be solved by a symptomatic solution (fast, shallow) OR a fundamental solution (slow, deep). The symptomatic solution creates dependency, atrophies the capacity for fundamental solutions, and eventually the fundamental solution becomes impossible.

Classic signs:

• Heavy reliance on a workaround
• Team loses the skill to do it "the right way"
• The burden shifts from problem-solver to problem-depender

Recognition: "The hack became the system." "Only Alice knows how to run it."

Canonical intervention:

• Deliberately invest in the fundamental solution even though the symptomatic one is cheaper short-term
• Put the symptomatic solution on a sunset timer
• Measure the atrophy explicitly — track whether the fundamental capacity is growing or shrinking

Example: Relying on one senior engineer to diagnose production incidents. Short-term: fast resolution. Long-term: team never learns diagnosis, the senior engineer burns out, the team is now incapable. Fix: enforce rotation and documentation even when it slows resolution.

---

3. Limits to Growth (a.k.a. Limits to Success)

Structure: A reinforcing loop of growth hits a balancing loop of limits. Growth slows or reverses as the limit activates.

Classic signs:

• Early growth was exponential
• Growth is now linear, flat, or declining
• The thing that worked initially no longer works
• Doing more of what worked makes it worse

Recognition: "We used to 10x. Now we barely 1.5x. Nothing we try helps."

Canonical intervention:

• Don't push harder on the reinforcing loop (it's exhausted)
• Identify the limit (balancing loop)
• Attack the limit directly — change the constraint, raise the ceiling
• Often requires structural change, not more effort

Example: Adding engineers past team size 12-15 (see CausalLoop.md worked example). Fix: attack coordination cost, not hiring throttle.

---

4. Tragedy of the Commons

Structure: A shared resource is used individually rationally, but collectively destroyed. Each actor's gain is local; the cost is distributed.

Classic signs:

• Shared resource (staging environment, shared service, common infrastructure, database)
• Each team optimizes locally; resource degrades for all
• "Nobody owns it" / "It's always broken"

Recognition: "Staging is a wasteland." "The shared cache is always full." "Everyone blames everyone else."

Canonical intervention:

• Make the commons non-shared (partition, quota, per-team instance)
• Or: make individual use visible and collectively managed (observability + governance)
• Or: assign ownership with budget and authority
• Or: price the commons (charge-back, resource budgets)

Example: A shared test database. Each dev writes data; nobody cleans up; tests get slower; everyone blames "the test database." Fix: ephemeral per-branch databases, or named owner + automated cleanup.

---

5. Escalation

Structure: Two actors respond to each other's threats or investments. Each escalation triggers a larger counter-escalation. Driven by mutual reinforcing loops.

Classic signs:

• Arms race dynamics
• Feature wars with a competitor
• Alerting escalation (more alerts → alert fatigue → more alerts to "make sure you see it")
• Price wars

Recognition: "Both sides are doing more, nobody is winning."

Canonical intervention:

• Unilateral de-escalation (break the symmetry)
• Reframe the goal (compete on a different axis)
• Find a higher-order cooperation (both sides benefit from stopping)

Example: Alerting system bloat — every postmortem adds alerts; alert fatigue increases; incidents missed; postmortems add more alerts. Fix: alert-budget with forced decommission; alert quality metric.

---

6. Success to the Successful

Structure: Two actors compete for a limited resource. Whoever gets more early wins more future allocations. The gap widens.

Classic signs:

• A team / product / feature that got initial attention gets disproportionate ongoing attention
• "The rich get richer, the poor get poorer" dynamic
• Neglected areas decay and receive even less

Recognition: "Feature A has 3 PMs and Feature B has none, even though Feature B is more strategic."

Canonical intervention:

• Change allocation from competitive (winner takes more) to independent (each gets what it needs)
• Explicit re-balancing events (budget reallocations, leadership attention shifts)
• Measure absolute value, not relative — prevent relative comparison from determining allocation

Example: Two products sharing an engineering team. Product A ships fast, gets more engineers, ships faster; Product B starves despite strategic importance. Fix: allocate by strategic value, not velocity.

---

7. Drifting Goals (a.k.a. Eroding Goals)

Structure: A goal is set. Reality falls short. Instead of closing the gap, the goal is lowered. Repeated indefinitely, "quality" or "standard" drifts downward.

Classic signs:

• SLAs are met because SLAs keep dropping
• "Normal" performance is worse than it used to be
• Nobody remembers when quality was the current definition

Recognition: "Our standard used to be 99.9%. Then 99.5%. Now nobody talks about it."

Canonical intervention:

• Anchor the goal externally (industry benchmark, competitor, first-principles calculation)
• Make drift visible — dashboard the historical goal line, show the erosion
• Build capacity to close the gap rather than lower the goal

Example: Test suite runtime used to be 2 min; drifted to 20 min; now nobody tests locally. Fix: hard target ("CI must be <5min by Q3") and invest structurally.

---

8. Growth and Underinvestment

Structure: Growth creates demand. Demand exceeds capacity. Investment in capacity lags (due to delays or perceived cost). Customers leave; growth stalls. Investment no longer feels justified.

Classic signs:

• Onboarding is overwhelmed
• Support queue is always behind
• Capacity was "just about to be added" for quarters
• Growth slowed and now there's "no need to invest"

Recognition: "We grew too fast to support, now we're slow because we're not supporting well."

Canonical intervention:

• Invest in capacity during growth, not after
• Measure capacity as a leading indicator, not a lagging one
• Accept that capacity investment must exceed current load

Example: Customer support team stays flat as user base 5x's. Response times crater. Churn rises. Growth stalls. "No need for more support, growth is flat." Fix: hire capacity proactively; measure support saturation, not ticket count.

---

9. Accidental Adversaries

Structure: Two parties who should cooperate (allies, partners, teammates) end up working against each other due to hidden feedback loops. Each party's local fix creates friction for the other.

Classic signs:

• Two teams / departments / partners with aligned goals, but friction
• Each is defensively protecting its own workflow
• Communication has collapsed into blame

Recognition: "Infra and product used to work together. Now each protects its own territory."

Canonical intervention:

• Surface the hidden dependency
• Make the shared goal explicit and measurable
• Create a shared scoreboard where both succeed or fail together
• Explicit interfaces and contracts replace informal cooperation

Example: Platform team optimizes for stability (rejects risky launches); product team optimizes for velocity (works around platform). Each action makes the other's job harder. Fix: shared launch readiness review with both goals counted.

---

10. Policy Resistance

Structure: A policy or intervention is resisted by the system — multiple actors adjust their behavior to neutralize it. Net effect: little or no change, often with negative side effects.

Classic signs:

• Intervention had no measurable effect
• Unintended workarounds appeared
• "Gaming" the metric

Recognition: "We added the control; nothing changed; people just routed around it."

Canonical intervention:

• Understand who is resisting and why (their incentives)
• Align with the resistors' incentives rather than fighting them
• Change the goal, not the control

Example: Code review policy to reduce bugs. Developers add LGTM without reading. Bug rate unchanged. Fix: measure review depth (time spent, comments added); make code complexity visible to reviewers.

---

Execution

Step 1: Describe the Behavior

In 2-4 sentences, state the behavior you're trying to explain:

• What's happening
• Over what time period
• Who is involved
• What has been tried

Step 2: Check Against Each Archetype

Walk the list above. For each archetype, ask: "Does this shape match?"

For borderline cases, look at the mechanism — not just the surface symptoms. Two different archetypes can have similar visible symptoms but different structures.

Step 3: If a Match — Apply the Canonical Intervention

ARCHETYPE MATCH: [name]
EVIDENCE: [why the structure matches]
CANONICAL INTERVENTION: [from the archetype documentation]
ADAPTATION: [how this applies to the specific situation]

Step 4: If No Match — Fall Back to CausalLoop

If no archetype matches, build a CLD from scratch (CausalLoop.md). The behavior may be a composite of two archetypes, or a novel structure.

Step 5: Confirm Fit — Negative Test

Check that the intervention makes sense:

• Does it address the underlying loop, not just a symptom?
• Does it account for delays?
• Have others tried it in similar situations?

If you can't find any record of the canonical intervention helping similar situations, you may have misidentified the archetype.

Output

🧩 ARCHETYPE MATCH: [name]

BEHAVIOR DESCRIPTION:
[What is happening, 2-4 sentences]

WHY THIS ARCHETYPE:
- Signature: [structural signature that matches]
- Evidence: [observable pattern]
- Dynamic: [reinforcing + balancing loops involved]

CANONICAL INTERVENTION:
[From archetype documentation]

ADAPTATION TO CONTEXT:
- First move: [specific action]
- Measure of success: [how you'll know it's working]
- Timeline: [when to re-evaluate]

RISK: [which other archetype could be mimicked — second-order check]

Common Mistakes

• Seeing archetypes everywhere. Not every recurring problem is an archetype. If the match is forced, fall back to CausalLoop.
• Naming the archetype but not applying the intervention. The point is the canonical fix, not the label.
• Ignoring the delay structure. Delays are integral to most archetypes. If the timing doesn't match, the archetype probably doesn't either.
• Skipping the CLD check. Archetypes are CLD templates. Draw your specific CLD and verify it maps to the archetype's CLD, not just in words.

Integration

• Entry point from Iceberg (Layer 3 structure resembles an archetype)
• Entry point from CausalLoop (drawn CLD resembles an archetype template)
• Exit to FindLeverage for intervention prioritization
• Reference: ../Archetypes.md for full archetype structures with CLD templates

Attribution

Systems archetypes: Peter Senge, The Fifth Discipline (1990); William Braun, The System Archetypes (2002). Original case studies: System Dynamics Society; Pegasus Communications.

FindLeverage Workflow — SystemsThinking

Purpose

Apply Donella Meadows' 12 Leverage Points to a system to find where a small change produces a large, durable effect. Most interventions target weak leverage points (parameters, buffers) where effort is high and returns are low. Meadows' insight: leverage increases dramatically as you move up the list, but so does resistance.

This is the workflow to run after you have a CLD (CausalLoop.md) or archetype identification (FindArchetype.md) and are choosing where to intervene.

Invocation

• "Leverage point"
• "Where should we intervene?"
• "Highest-leverage change"
• After CausalLoop — the CLD shows the structure; this workflow tells you what to push on
• After FindArchetype — the archetype suggests a category of intervention; this workflow ranks options

The 12 Leverage Points (Meadows 1999)

Ordered from least leverage (12) to most (1). Reversed from how you'd instinctively attack a problem.

12. Constants, Parameters, Numbers

What: Subsidies, taxes, standards, capacity limits, retry counts, SLA thresholds.

Why weakest: Parameters rarely change system behavior. Politicians love them because they're visible; systems ignore them unless they cross a structural threshold.

When useful: When the parameter is the threshold that triggers a structural effect (e.g., a rate limit that actually changes resource contention dynamics).

Example in software: Changing a timeout from 5s to 10s. Won't change the underlying latency distribution; just shifts where the failure surfaces.

---

11. Buffers — The Size of Stabilizing Stocks

What: Inventory, cash reserves, queue depths, cache sizes, team slack.

Why weak: Buffers stabilize but don't change the generating dynamics. Too large = expensive and slow to respond; too small = fragile.

When useful: When a buffer is too small to absorb normal variation, fixing the size is genuinely structural.

Example in software: Increasing a Kafka topic's retention. Absorbs spikes; doesn't fix the producer/consumer imbalance.

---

10. Stock-and-Flow Structures — Physical Systems and Their Nodes

What: The actual topology — pipelines, networks, road layouts, org charts, service graphs.

Why moderate: Changing physical structure has real effect but is often extremely expensive. Also: you usually can't change it without rebuilding.

When useful: Architecture decisions, re-orgs, platform migrations. When you can change the structure, do so deliberately — the structure you pick will generate behavior for years.

Example in software: Monolith → microservices (or back). Structural change, massive impact, massive cost. Rarely the right leverage point within an existing system.

---

9. Delays — Lengths of Time Relative to Rates of Change

What: Perception delays, decision delays, action delays, feedback delays.

Why strong: Delays cause oscillation, overshoot, and surprise. Reducing the feedback delay can fix behavior that no parameter change fixes.

When useful: Any system with oscillation or overshoot — deploy pipelines that swing between "deploying everything" and "deploying nothing," alerting that oscillates between noisy and silent.

Example in software: p99 monitoring on a 5-minute rolling window vs. 1-hour. The shorter window lets you respond before the incident escalates.

---

8. Balancing Feedback Loops — Strength Relative to the Impact They Try to Correct

What: The correcting loops — negative feedback, goal-seeking.

Why strong: Weak balancing loops let the system overshoot. Strong ones stabilize. Many failures come from balancing loops that aren't strong enough for the perturbation.

When useful: Scaling incidents, runaway dynamics, quality decay — look for the balancing loop and ask "why isn't it strong enough?"

Example in software: Autoscaler with a slow reaction time. Reinforcing loop of traffic growth overwhelms it. Strengthen the balancing loop: faster scale-up, more predictive, lower trigger threshold.

---

7. Reinforcing Feedback Loops — Strength of the Gain

What: The amplifying loops — positive feedback, vicious/virtuous cycles.

Why strong (and dangerous): Reinforcing loops drive exponential change. Strengthen a good one (adoption, learning), weaken a bad one (debt accretion, runaway costs).

When useful: Growth dynamics, tech debt, alert fatigue, learning cycles.

Example in software: Onboarding speed determines how fast new hires contribute, which determines how fast they mentor the next hires. Strengthen this R loop and team velocity compounds.

---

6. Information Flows — Who Has Access to Information

What: Dashboards, feedback channels, transparency, visibility.

Why strong: Behavior changes when information becomes visible to the people whose behavior matters. The structure is the same; the information flow is different.

When useful: When actors would make different decisions if they could see what they can't currently see. Very common.

Example in software: Showing engineers their own code's production error rate (not just the team average). Behavior changes without any policy or incentive change.

---

5. Rules of the System — Incentives, Punishments, Constraints

What: Written rules, laws, contracts, policies, norms.

Why strong: Rules shape all downstream behavior. Change the rule and the whole game changes.

When useful: When behavior is rational given current rules. The rule is the generator.

Example in software: A "no code merged without two approvals" rule. Changes the entire PR review dynamic. Leverage is at the rule, not at individual reviews.

Caveat: Rules face policy resistance (archetype 10). Actors will game them. Rules need to align with underlying incentives or they fail.

---

4. Self-Organization — Power to Add, Change, or Evolve System Structure

What: The system's ability to reshape itself — evolution, learning, adaptation, restructuring.

Why very strong: A self-organizing system is resilient because it can change its own rules in response to conditions.

When useful: Platforms, marketplaces, organizations that need to adapt faster than central control can plan.

Example in software: A team that can restructure itself (shift ownership, split services, change rituals) without leadership approval. Adapts to load much faster than one that can't.

---

3. Goals of the System

What: What the system is for — the purpose it's optimized toward.

Why very strong: The goal determines which of the lower-leverage points matter and how they're used. Change the goal and the whole system realigns.

When useful: When the system is optimizing for the wrong thing — maximizing feature velocity when the real need is user trust; maximizing uptime when the real need is experimentation.

Example in software: Changing a team's goal from "feature ship rate" to "user-reported quality." Everything below (rules, information flows, parameters) realigns.

---

2. Paradigm — The Mindset from Which the System Arises

What: The shared beliefs, assumptions, and worldview that generate the system's goals, rules, and structure.

Why extremely strong: Change the paradigm and you change everything below it. The whole system is regenerated.

When useful: Rarely immediate, always durable. Long-term transformations — shifts from "software as a product" to "software as a service," from "move fast break things" to "move fast with stable infrastructure."

Example in software: The DevOps paradigm shift (dev and ops are one) vs. the prior paradigm (dev writes, ops runs). Changed the goals, rules, structures, and information flows of software engineering.

---

1. Transcending Paradigms

What: The capacity to hold paradigms loosely, to recognize that no paradigm is "true," only more or less useful for a purpose.

Why most powerful: A practitioner who can step outside any paradigm can choose the right one for the situation rather than being trapped in one.

When useful: Crises, strategic pivots, fundamental re-imagining. Rarely applicable to routine problems.

Example in software: Recognizing that "the cloud" is a paradigm, not reality. For some workloads, on-prem is correct. For some, serverless. For some, bare metal. The practitioner who holds "cloud is default" loosely picks better.

---

Execution

Step 1: Establish the System and Goal

SYSTEM: [what you're trying to change]
CURRENT GOAL (implicit or explicit): [what is the system optimizing for now?]
DESIRED BEHAVIOR: [what you want instead]

Often the current goal is implicit — inferred from where resources flow, what metrics are watched, what behaviors are rewarded. Make it explicit. Many interventions fail because they don't realize they're fighting the actual goal.

Step 2: Map the Candidate Interventions to Leverage Points

For each intervention under consideration, identify which level of Meadows' list it targets:

CANDIDATES:
- [Intervention A]: Level [N] — [why]
- [Intervention B]: Level [N] — [why]
- [Intervention C]: Level [N] — [why]

Usually there will be 3-6 candidates. Many will cluster at the bottom (parameters, buffers) because those are the easiest to propose.

Step 3: Rank by Effective Leverage

Effective leverage = Meadows leverage × feasibility — the theoretical leverage of the level times your ability to actually execute.

A Level 2 (paradigm) intervention you can't make is zero effective leverage. A Level 12 (parameter) that you can actually push is non-zero effective leverage.

RANKING:
| Candidate | Meadows level | Feasibility (H/M/L) | Effective leverage |
|-----------|---------------|---------------------|---------------------|
| A         | 5 (Rules)     | M                   | High                 |
| B         | 12 (Parameter)| H                   | Low                  |
| C         | 3 (Goal)      | L (political)       | Medium (if achievable)|

Step 4: Pick the Highest Feasible Leverage

Rule of thumb: Prefer the highest Meadows level that is feasible within the time and political budget. Don't waste cycles on parameter changes when a rule change is feasible.

Also: bundle a low-level tactical intervention with a high-level structural one. The low-level one buys time; the high-level one changes the generator.

Step 5: Name Second-Order Effects

Every leverage-point push has second-order effects. At higher levels, these are larger.

INTERVENTION: [chosen]
LEVEL: [N]

INTENDED: [primary effect]
SECOND-ORDER:
- [Other variables that will shift]
- [Which loops are now stronger/weaker]
- [Which archetypes might activate]
THIRD-ORDER:
- [Behavioral adaptations]
- [Possible policy resistance]

Output

🎯 LEVERAGE POINT ANALYSIS: [system]

SYSTEM GOAL (implicit): [...]
DESIRED BEHAVIOR: [...]

CANDIDATE INTERVENTIONS:
- [A]: Level [N]
- [B]: Level [N]
- [C]: Level [N]

HIGHEST FEASIBLE LEVERAGE: [Chosen intervention]
- Meadows level: [N]
- Why feasible: [context]
- Why highest: [why the higher levels are not feasible right now]

BUNDLED LOW-LEVEL TACTICAL INTERVENTION: [if any, to buy time]

EXPECTED EFFECTS:
- First-order: [...]
- Second-order: [...]
- Third-order: [...]

RESISTANCE TO EXPECT:
- Policy resistance from: [who, why]
- Paradigm clash: [if Level 2 or 3, what belief is threatened]

MEASURE OF SUCCESS: [how you'll know the leverage worked]
TIMELINE: [when you'll re-evaluate]

Worked Example

SYSTEM: Our team's code review process.

CURRENT GOAL (implicit): "Maintain PR throughput." Metric: PR merge rate per week.
DESIRED BEHAVIOR: Same merge rate, but with higher defect detection.

CANDIDATES:
- [A] Require 2 reviewers instead of 1 → Level 5 (rules). Medium feasibility (political cost).
- [B] Change PR template to require "risk level" self-tag → Level 6 (information flow). High feasibility.
- [C] Change team goal from "PR merge rate" to "defects caught per PR" → Level 3 (goal). Low feasibility (requires leadership + metrics revamp).
- [D] Add a static analyzer to catch common defects → Level 12 (parameter/buffer). High feasibility.

EFFECTIVE LEVERAGE RANKING:
1. [C] Level 3 × L feasibility = M — if achievable, transformative
2. [A] Level 5 × M = M
3. [B] Level 6 × H = M
4. [D] Level 12 × H = L (weak leverage despite easy)

HIGHEST FEASIBLE: [B] — information flow (risk self-tag). Almost as much effective leverage as [A] or [C] at far lower cost.

BUNDLED TACTICAL: [D] — static analyzer, to catch the mechanical defects while the cultural shift from [B] propagates.

EXPECTED:
- First-order: Reviewers see "risk: high" and spend more time on those PRs.
- Second-order: Self-tagging calibrates over time as people learn what "high risk" means.
- Third-order: Team language shifts; "risk" becomes a shared vocabulary.

RESISTANCE: People will self-tag everything "low" to avoid scrutiny. Mitigation: make distribution visible ("team is self-tagging 95% low — is that accurate?").

MEASURE: Defects-escaped-per-PR, tracked before and after; distribution of risk tags.
TIMELINE: Re-evaluate in 8 weeks.

Common Mistakes

• Proposing only level 11-12 interventions. Most interventions people propose are the lowest leverage. Always generate candidates at multiple levels.
• Confusing "hard to do" with "high leverage." A Level 2 intervention you cannot execute has zero effective leverage.
• Ignoring second-order effects. Higher leverage = larger unintended consequences. Run them through CausalLoop before committing.
• Skipping the goal analysis. If you're fighting the system's implicit goal, no amount of lower-level intervention will hold.
• "Just change the culture." Culture (Level 2) is real but isn't a single action. Culture-layer interventions must still have a concrete first move.

Integration

• Runs after CausalLoop or FindArchetype
• Reference material: ../LeveragePoints.md for full treatment with more examples
• Exits to Ideate or BeCreative for generating candidate interventions at the chosen level

Attribution

Donella Meadows, "Leverage Points: Places to Intervene in a System" (1999), published in Whole Earth, expanded in Thinking in Systems (2008). The 12-point list is canonical; ordering may vary slightly across sources but the overall ranking is stable.

Iceberg Workflow — SystemsThinking

Purpose

Walk down from visible events to the mental models that produced them. Most analysis stops at the top layer; durable fixes live at the bottom two.

The Iceberg Model (popularized by Michael Goodman and the Academy for Systemic Change) asserts that 90% of what generates behavior is below the waterline. Treating symptoms leaves the generator intact, which is why "the same thing keeps happening."

Invocation

This workflow is invoked: 1. Directly by the user: "iceberg this", "walk down the iceberg", "why does this keep happening" 2. By the Algorithm when OBSERVE capability scan selects SystemsThinking with a recurring-problem signal 3. By the RootCauseAnalysis skill — its Postmortem workflow hands off to Iceberg when patterns repeat across incidents

The Four Layers

╱═══════════════════════════════════╲
│        LAYER 1: EVENTS            │  ← What happened? (visible, reactive)
╲═══════════════════════════════════╱
        │ "Why did this happen?"
        ▼
╱═══════════════════════════════════╲
│        LAYER 2: PATTERNS          │  ← What has happened over time?
╲═══════════════════════════════════╱
        │ "What's generating this pattern?"
        ▼
╱═══════════════════════════════════╲
│       LAYER 3: STRUCTURES         │  ← What rules, incentives, feedback loops?
╲═══════════════════════════════════╱
        │ "What beliefs make this structure feel correct?"
        ▼
╱═══════════════════════════════════╲
│     LAYER 4: MENTAL MODELS        │  ← What assumptions generate the structure?
╲═══════════════════════════════════╱

Intervention leverage increases as you descend. Event-layer fixes are reactive and don't prevent recurrence. Structure-layer fixes change the generator. Mental-model-layer fixes change what the organization believes, which transforms the whole cascade.

Execution

Step 1: Name the Event Clearly

Write one sentence stating the specific event that triggered the analysis.

EVENT: [Specific thing that happened, with date/time/scope]

Avoid generalization at this stage. "A 14-minute outage of the payments service on 2026-04-12 at 23:51 UTC" is better than "reliability issues."

Step 2: Find the Pattern (Layer 2)

Ask: "Has this kind of thing happened before?"

PATTERNS:
- Over what time window has this recurred?
- Under what conditions does it appear?
- Is the frequency changing (up, flat, down)?
- Are there similar patterns in adjacent systems/teams?

If no pattern exists — this was a one-time event. Iceberg is not the right tool; go to Postmortem (RootCauseAnalysis) for a single-incident analysis. If a pattern exists, continue down.

Common pattern shapes:

• Recurring — same thing, same shape, intermittent frequency
• Escalating — same thing, worse each time
• Shifting — symptom moved but the underlying rhythm is identical
• Seasonal / triggered — tied to a schedule, a release, a team event

Step 3: Find the Structure (Layer 3)

Ask: "What rules, incentives, flows, or feedback loops generate this pattern?"

This is where most analyses stop too early. Push for at least 3 candidate structures. Categories to consider:

STRUCTURES:
- Feedback loops — what reinforces or balances the pattern?
- Incentives — what behavior does the system reward?
- Flows — where do information, resources, authority travel?
- Delays — gap between action and feedback, often the hidden cause
- Thresholds — above/below what number does behavior change?
- Boundaries — who owns what; what falls in the gaps?
- Rules / policies — what has been codified, for whom?
- Resource allocation — where does attention/time/money go?

Key question: If you removed the symptom and left the structure intact, would a new symptom of the same shape emerge somewhere else?

If yes — the structure you named is the generator.

Step 4: Find the Mental Model (Layer 4)

Ask: "What beliefs, assumptions, or worldviews make the structure feel natural or correct?"

Mental models are the hardest to surface because they are invisible to the people holding them. They feel like "how things are," not "what we believe."

MENTAL MODELS — probe with these questions:
- What does this structure imply about what we value?
- What would we have to believe for this structure to make sense?
- What does the structure say about who is trusted, who is not?
- What does the structure treat as scarce vs. abundant?
- What time horizon does the structure optimize for?
- Whose voice is amplified by the structure? Whose is quiet?

Common mental-model archetypes:

• "We don't have time for X" (structure under-invests in X; may be wrong)
• "Quality is the QA team's job" (generates buck-passing structure)
• "Moving fast is more valuable than moving carefully" (generates brittle systems)
• "People need to be managed closely" (generates layered oversight + slow decisions)
• "Prevention isn't visible; fixing is" (rewards fire-fighting over fire-prevention)

Step 5: Locate Intervention Points

Once you've walked down, walk back up with intervention candidates at each layer:

INTERVENTIONS BY LAYER:

Layer 4 (Mental Models) — highest leverage, hardest
- What belief would need to change?
- Who needs to see the structure differently?
- What evidence would shift the belief?

Layer 3 (Structures) — high leverage, actionable
- Change the feedback loop (tighten delays, flip polarity)
- Change incentives (reward what you want, stop rewarding what you don't)
- Change boundaries (merge responsibilities, split them)
- Change flows (information, resources, authority)

Layer 2 (Patterns) — medium leverage
- Instrument the pattern so it's visible
- Set thresholds that force response
- Change the rhythm (ship cadence, review cadence, staffing cycle)

Layer 1 (Events) — lowest leverage, fastest
- Patch the specific failure
- Useful only if structural fixes are already committed
- Otherwise: treating symptoms, problem returns

Rule: Never ship an event-layer fix without naming the structural fix it defers. The structural fix may not happen today, but it must be on the roadmap — otherwise the team is consenting to recurrence.

Step 6: Output

🧊 ICEBERG ANALYSIS: [topic]

EVENTS (Layer 1):
- [Specific event 1]
- [Related event 2]
- ...

PATTERN (Layer 2):
- Time window: [e.g., 3 recurrences in 6 weeks]
- Shape: [recurring / escalating / shifting / seasonal]
- Trigger conditions: [what predicts it]

STRUCTURE (Layer 3):
- Primary generator: [feedback loop / incentive / flow / delay / rule]
- Contributing structures: [list]
- Test: if we remove the symptom, would this structure produce another?

MENTAL MODEL (Layer 4):
- Belief that makes the structure feel correct: [...]
- Who holds it: [...]
- What evidence would shift it: [...]

INTERVENTION CANDIDATES:
- Event-layer patch: [quick fix, explicitly deferred]
- Structural fix: [the real lever]
- Mental-model shift: [the durable change]

RECOMMENDED: [which layer to target given cost/benefit]

Worked Example

EVENT: p99 latency spike in checkout service on 2026-04-11 caused cart abandonment

PATTERN:
- 4 p99 spikes in checkout in last 8 weeks
- Each time, fixed with a cache warm-up or pod resize
- Frequency is flat, not declining
- All spikes occur within 20min of a deploy

STRUCTURE:
- Feedback loop: deploy → cold cache → latency spike → ops response → warm-up → resolved. Loop never detects until after it damages users.
- Incentive: deploy velocity is measured; deploy safety is not (no SLO for post-deploy p99)
- Boundary: cache layer owned by infra; checkout owned by product. No team owns "the deploy behavior of the cache."
- Delay: 6-minute gap between cold cache and human response

MENTAL MODEL:
- Belief: "deploys are safe if tests pass"
- Held by: eng leadership, because CI is green
- Shift requires: evidence that tests don't cover cache warmth — a single p99 chart overlaid with deploy events does it

INTERVENTIONS:
- Event-layer patch (deferred): continue manual warm-ups — DO NOT keep doing only this
- Structural: add post-deploy p99 gate that blocks traffic shift until warm; name an owner for deploy-time cache behavior
- Mental-model: share p99-vs-deploy chart with leadership; add "post-deploy stability" to deploy definition of done

RECOMMENDED: structural fix (post-deploy p99 gate + ownership). Patches alone are consent to recurrence.

Common Mistakes

• Stopping at Layer 2. "It keeps happening on deploys" is a pattern, not a structure. Push to the feedback loop / incentive.
• Listing "people" as a structure. Individuals are events. The structure is what the organization requires of them.
• Conflating mental models with opinions. "Team members disagree about X" is noise. The mental model is what the organization's structure believes, which may differ from what individuals articulate.
• Naming a hero intervention at Layer 4 you can't actually make. "We need to change the culture" is a cop-out if there's no concrete action. Culture-layer interventions must still have a specific first move.
• Skipping the pattern check. If there's no pattern, this isn't an iceberg problem — it's an incident. Use RootCauseAnalysis/Postmortem.

Integration

• Feeds CausalLoop when Layer 3 structure is a feedback loop that deserves explicit diagramming.
• Feeds FindArchetype when Layer 2 pattern matches a known systems archetype.
• Handoffs to RootCauseAnalysis/Postmortem if the investigation reveals a single incident rather than a pattern.
• Output informs ISC criteria in OBSERVE — structural criteria, not just symptom criteria.

Attribution

Iceberg Model popularized in The Fifth Discipline Fieldbook (Senge et al., 1994); four-layer formulation from Michael Goodman / Academy for Systemic Change. Leverage-by-layer principle: Donella Meadows, Thinking in Systems.