Day 369: System Dynamics - Stocks, Flows, and Feedback Loops

The core idea: System dynamics turns a messy story about growth, congestion, and policy into explicit accumulations, rates, and delays so you can see why an intervention helps for one quarter and backfires over the next two years.

Today's "Aha!" Moment

In ../23/16.md, Harbor City ended the month with a useful rule: pick the modeling lens that matches the mechanism creating the next failure. The first workshop of the new month applies that rule to Seawall District after the council has approved the waterfront redevelopment in principle but not the operating plan. The transport team says the district needs a parking garage. The tram team says more parking will refill congestion. The flood-control team says the real constraint is not traffic at all but how much runoff the district keeps pushing into South Marsh after each storm.

Those arguments look unrelated until you phrase them in system-dynamics terms. Parking occupancy is a stock. Water stored in the detention basin is a stock. Households living in the district, office workers commuting into it, and unresolved maintenance requests for flood pumps are all stocks. They do not change because someone writes a memo about them. They change through flows: move-ins and move-outs, vehicles arriving and leaving, runoff entering the basin and water leaving through pumps or infiltration, repair work arriving and repair work being completed.

Once Harbor City writes the problem that way, a second realization appears: the behavior people complain about is usually not caused by one rate in isolation. It is caused by feedback loops acting through those stocks. A successful district attracts more employers, which attracts more commuters, which raises pressure to add parking, which makes driving easier for a while, which attracts still more trips. That is a reinforcing loop. A congestion charge or a tram service increase can create a balancing loop, but only after budget approval, procurement, and construction delays. If those delays are long, the city can overshoot and oscillate even when every department is acting rationally.

The misconception to discard is that "more capacity" is always a direct fix. System dynamics says capacity changes matter only through the flows and incentives they alter over time. A garage does not delete congestion from the city. It changes trip choices, land value, curb behavior, and future demand. The model becomes valuable precisely because it makes those indirect consequences visible before Harbor City commits to concrete and asphalt.

Why This Matters

Static dashboards are good at telling Harbor City what exists now: current tram crowding, current parking occupancy, current marsh depth after rain. They are much worse at telling the city what today's policy will cause next season. If Seawall District adds a garage to relieve queueing, the immediate result may be smoother arrivals. Six months later, commuters who had tolerated the tram may drive instead, delivery activity may shift toward the curb lane, and the city may face the same queue plus a larger runoff problem because more impermeable surface was added to the district. A point-in-time metric can report local relief while the underlying feedback loop is getting stronger.

This is why system dynamics matters in production settings, not only in public policy classrooms. Incident backlog, unfinished feature work, inventory on hand, infected population, and customer support queues are all stocks. Hiring, recovery, arrivals, churn, and completions are flows. If you manage only the snapshot, you miss the mechanism that makes the snapshot keep returning. Harbor City needs more than a forecast for opening day. It needs a disciplined way to ask which quantities accumulate, which policies change the rates, and which delays make the response late enough to create oscillation or lock-in.

The practical payoff is not a perfect prophecy. It is a better decision boundary. Harbor City can compare a garage-only plan, a transit-first plan, and a phased-development plan with explicit assumptions about how each one changes occupancy, travel demand, stormwater storage, and marsh recovery over time. That is the difference between arguing from intuition and reasoning from structure.

Learning Objectives

By the end of this session, you will be able to:

1. Identify stocks and flows in a real system - Distinguish what accumulates from the rates that change it in an operational scenario.
2. Explain how feedback loops and delays generate behavior over time - Trace why a policy can stabilize, amplify, or oscillate instead of assuming an immediate linear effect.
3. Frame a useful system-dynamics model for decision-making - Choose a defensible model boundary and compare policy options without pretending to simulate every detail.

Core Concepts Explained

Concept 1: Stocks and flows are the minimum accounting structure of a dynamic system

Harbor City's first mistake was discussing Seawall District as a list of disconnected metrics. Once the team translates the district into stocks and flows, the picture becomes less rhetorical and more mechanical. Occupied apartments, morning tram queue, water stored in the detention basin, and pending pump repairs are stocks because each one represents a quantity that persists from one time step to the next. New leases, passenger arrivals, runoff, and incoming maintenance tickets are inflows. Move-outs, boardings, pump discharge, and completed repairs are outflows.

That distinction matters because stocks are the system's memory. If Harbor City has already accumulated a large commuter base that prefers driving, a single rainy morning cannot be understood by looking only at today's arrival rate. The existing stock of car-dependent commuters shapes how much demand will hit the district when weather worsens. The same is true for the marsh. A basin that is already half full from previous rain behaves differently from an empty basin receiving the same new runoff.

System dynamics makes this explicit with very plain arithmetic:

occupied_housing(t+1) = occupied_housing(t) + move_ins - move_outs
tram_queue(t+1)       = tram_queue(t) + passenger_arrivals - passenger_boardings
basin_storage(t+1)    = basin_storage(t) + storm_runoff - pumping - infiltration

The useful constraint is that a stock changes only through its flows. "Make congestion disappear" is not an action in this language. A policy must change arrival rates, service rates, route choice, or land-use incentives. That is why system dynamics is good at exposing weak proposals. If a team cannot say which flow its policy changes, it probably does not yet understand the mechanism.

The trade-off is aggregation. Harbor City gives up block-by-block driver identity and parcel-level hydrology to gain a model that can compare policy bundles over months and years. That is the right bargain when the decision is about structural behavior, not about which exact van will double-park at 8:17 a.m.

Concept 2: Feedback loops and delays explain why interventions produce counterintuitive results

Once Harbor City identifies the main stocks, the next question is not "what is the average value?" but "what loop keeps pushing that value up or down?" Seawall District contains both reinforcing and balancing feedback. A reinforcing loop appears when success attracts more of the behavior that defines success: a lively district draws employers, more employers draw commuters, more commuters support more retail, and stronger retail makes the district still more attractive. If parking expansion is the easiest short-term response, that same loop can increase car dependence while officials believe they are solving congestion.

A balancing loop pushes the system back toward a target. When tram crowding rises, the city may add service, raise parking prices, or reserve curb space for buses and deliveries. Those changes reduce waiting and make car trips less attractive, which can bring congestion back down. The catch is delay. Service changes need a budget cycle. Pump upgrades need procurement and construction. Marsh restoration may need multiple wet seasons before storage capacity recovers. During those delays, the original pressure keeps accumulating.

That is why system dynamics often produces overshoot and oscillation instead of smooth adjustment. Harbor City may approve a garage based on last year's traffic complaints, open it after commuters have already shifted modes twice, and then discover the district now has both more parking and more trips. The policy was not irrational. It was late relative to the loop it was trying to control.

You can sketch the structure without pretending to have a finished simulation:

district appeal -> jobs and visitors -> car-trip demand -> pressure for more parking
       ^                                                      |
       |                                                      v
retail activity <- easier car access <- added parking supply

tram crowding -> pressure for service increase -> tram capacity -> lower crowding
          ^                                                |
          |---------------------- demand growth -----------|

The trade-off here is interpretability versus certainty. Feedback diagrams explain why the system can surprise you, but they still depend on assumptions about behavior, delays, and policy sensitivity. The lesson is not that any loop diagram is true. It is that explicit loop structure is safer than treating cause and effect as instantaneous and one-directional.

Concept 3: A useful system-dynamics model is scoped around a decision, not around the whole world

Harbor City does not need a universal digital twin of the entire municipality to make the Seawall decision. It needs a model boundary that is large enough to capture the decisive feedback loops and small enough to reason about. For this lesson, a workable scope includes district households, jobs, peak travel demand by mode, parking supply, detention-basin storage, marsh health, and maintenance backlog for pumps and curb assets. It does not need to simulate every resident or every street in the metro area.

Within that boundary, the city can compare policies as changes to flows and delays. A garage-only plan increases parking-entry capacity and lowers the perceived cost of driving. A transit-first plan increases tram boardings and may reduce car-trip inflow, but only after procurement delay. A phased-development plan caps office occupancy growth until stormwater storage and pump redundancy catch up. Each option tells a different causal story about the future path of the same stocks.

This is also the point where system dynamics becomes operational rather than academic. The model should tell Harbor City what to monitor after launch: not only corridor speed, but also parking saturation, tram crowding by station, pump-failure backlog, basin recovery time after storms, and marsh turbidity after heavy rainfall. If the model changes no monitoring plan and no decision threshold, it is probably too decorative to be useful.

The main trade-off is between false precision and omitted structure. An oversized model invites endless parameter arguments and gives a misleading sense of certainty. An undersized model misses the loop that actually drives failure. The right target is the smallest endogenous model that can still falsify the favored policy. That framing also prepares the ground for 02.md, where the same stock-flow logic will govern susceptible, infected, and recovered populations, but the infection flow will depend on contact structure across a network.

Troubleshooting

Issue: The team labels every important metric as a stock.

Why it happens / is confusing: Many operational dashboards mix states, rates, and derived indicators on one screen, so people start treating "traffic speed" or "rent price" as if they accumulate like inventory or water volume.

Clarification / Fix: Ask whether the quantity is conserved from one time step to the next and can only change through inflow and outflow. Queue length is a stock. Arrival rate is a flow. Average speed is usually an auxiliary variable derived from other states.

Issue: The model shows immediate stabilization, but operations in the real world keep overshooting.

Why it happens / is confusing: The structure probably omitted material delays such as budget approval, construction lead time, behavioral adjustment, or maintenance lag.

Clarification / Fix: Put the delay into the model explicitly. If a policy takes nine months to affect service capacity, do not let the simulated flow change instantly at the moment the policy is announced.

Issue: A causal loop diagram feels persuasive, so the team stops before building stock-flow equations.

Why it happens / is confusing: Loop diagrams are good for discussion, but they do not enforce conservation or show whether the implied rates can actually produce the claimed trajectories.

Clarification / Fix: Use the loop diagram as a hypothesis map, then convert the decisive loops into explicit stocks, flows, units, and time steps before using the model for policy comparison.

Advanced Connections

Connection 1: System Dynamics ↔ Reliability and Operations Backlogs

An incident queue in an SRE team behaves like Harbor City's pump-maintenance backlog. Open incidents are a stock. New pages are an inflow. Resolutions are an outflow. Overtime can temporarily raise the service rate, but if burnout reduces future capacity, the balancing loop becomes a reinforcing loop. System dynamics is useful here because it explains why a team can work harder for a month and still end up with a worse steady state later.

Connection 2: System Dynamics ↔ Epidemiology on Networks

The next lesson in 02.md adds a network lens to the same core machinery. Susceptible, infected, and recovered populations are stocks. Infection and recovery are flows. Feedback appears because more infected people create more opportunities for new infections. Contact networks then determine where that infection flow is concentrated and how fast it propagates. System dynamics provides the accounting grammar before network structure adds geography and social mixing.

Resources

• [DOC] MIT System Dynamics Self-Study Course
  • Focus: Core lessons on stocks, rates, feedback, and policy design from the MIT tradition that founded the field.
• [BOOK] Thinking in Systems: A Primer
  • Focus: A concise introduction to accumulation, delay, leverage points, and why interventions often produce unintended consequences.
• [DOC] Vensim Documentation
  • Focus: Practical stock-flow notation, simulation setup, and equation documentation in a widely used system-dynamics tool.
• [DOC] System Dynamics Society Resources
  • Focus: Curated cases, conference papers, and learning material once the basic stock-flow vocabulary is familiar.

Key Insights

1. Stocks are the system's memory - If you ignore what has accumulated, current rates are easy to misread.
2. Policies work by changing flows, not by editing outcomes directly - A serious proposal must name the rate, delay, or incentive it changes.
3. Feedback loops determine whether relief lasts - The same intervention can stabilize or amplify pressure depending on the loop structure and the delays around it.