System Dynamics and Simulation Modeling

Last Updated June 1, 2026

System dynamics is a method for understanding how complex systems change over time. It builds on the core systems-thinking ideas of feedback, stocks, flows, delays, boundaries, and behavior over time, but it adds a more formal modeling discipline. Instead of stopping at a causal-loop diagram, system dynamics asks how the structure can be represented, simulated, tested, revised, and used to compare possible futures.

Simulation modeling matters because many systems cannot be understood by intuition alone. A policy may look sensible in the short term but produce long-term harm. A system may seem stable while hidden stocks are eroding. A balancing feedback loop may oscillate when delays are introduced. A reinforcing loop may produce growth, collapse, or lock-in. A small change in assumptions can alter the timing, scale, or distribution of outcomes. System dynamics helps make those assumptions visible.

This article explains system dynamics and simulation modeling as a disciplined approach to studying complex systems. It shows how causal-loop diagrams can be extended into stock-flow models, how simulations help test assumptions, how model structure generates behavior, and why scenarios are more useful than single-point predictions. It also examines the ethical stakes of modeling: whose assumptions define the model, whose costs are included, whose futures are simulated, and how models can either clarify or obscure responsibility.

Why System Dynamics Matters

System dynamics matters because many important systems problems are dynamic rather than static. They unfold through accumulation, delay, feedback, adaptation, and changing conditions. A public-health intervention may take months or years to show results. Infrastructure neglect may accumulate quietly before failure. Workforce burnout may build beneath apparently stable output. Climate risk may intensify through long-delayed feedback. Trust may erode through repeated institutional behavior and recover only slowly through repair.

Simple cause-and-effect reasoning often fails in such systems because it assumes that effects are immediate, proportional, and isolated. System dynamics begins from a different premise: structure generates behavior over time. A system’s behavior is shaped by its stocks, flows, feedback loops, delays, constraints, goals, and information pathways. To understand the behavior, the analyst must understand the structure producing it.

System dynamics also matters because many interventions produce unintended consequences. A policy designed to reduce backlog may increase pressure, errors, rework, and turnover. A road expansion may reduce congestion briefly and then induce more driving. A performance metric may improve measured output while narrowing mission. A technology deployment may increase efficiency while reducing oversight capacity. Simulation modeling allows analysts to ask how the system might respond before intervention becomes irreversible.

The purpose of system dynamics is not to create a perfect replica of reality. No model can do that. The purpose is to make assumptions explicit, examine whether they can generate observed behavior, test alternative interventions, and improve judgment under complexity.

System dynamics is most valuable when it changes the quality of questions. Instead of asking only what caused an event, it asks what structure produced the pattern. Instead of asking whether a policy works in the abstract, it asks when, under what conditions, through what pathways, with what delays, and for whom.

Back to top ↑

From Systems Thinking to System Dynamics

Systems thinking provides the conceptual foundation: interdependence, boundaries, feedback, emergence, delay, leverage, and unintended consequences. System dynamics takes those ideas into formal modeling. It asks the analyst to represent the system structure clearly enough that its behavior can be simulated over time.

A causal-loop diagram is often an early step. It shows variables, causal links, feedback loops, and delays. But a causal-loop diagram usually does not specify stock sizes, flow rates, equations, parameter values, initial conditions, time steps, or numerical behavior. A system dynamics model adds those elements. It turns qualitative structure into a simulation that can generate behavior-over-time graphs.

This transition is important. A causal-loop diagram might suggest that workload, stress, errors, rework, turnover, and staffing capacity are connected. A system dynamics model asks how large the workforce is, how fast demand arrives, how quickly stress rises, how errors affect rework, how turnover reduces capacity, how long hiring takes, and how different staffing policies alter the system over time.

System dynamics does not replace qualitative systems thinking. It depends on it. The variables, boundaries, feedback loops, delays, and assumptions in a model are conceptual choices. If the conceptual framing is weak, the simulation may be precise but misleading. A model with poor variables, missing stakeholders, narrow boundaries, or unjustified causal signs can produce confident-looking results that distort the system.

The best system dynamics work moves back and forth between qualitative understanding and formal simulation. Stakeholder knowledge helps define variables and mechanisms. Behavior-over-time data helps test model structure. Simulation helps reveal counterintuitive consequences. Reflection helps revise assumptions. Modeling becomes a learning process, not a one-time technical product.

Back to top ↑

Stocks, Flows, and Feedback in Dynamic Models

System dynamics models are built around stocks and flows. Stocks represent accumulated conditions. Flows increase or decrease those stocks. Feedback loops influence the flows, and delays affect when information, action, and consequences appear.

For example, in an infrastructure model, the stock might be maintenance backlog. The inflows might include asset deterioration, deferred repair, increased use, and climate stress. The outflows might include preventive maintenance, replacement, and capital renewal. Feedback loops might connect failure risk to political pressure, emergency spending, maintenance funding, and public trust. Delays might occur between deterioration, inspection, budget approval, repair, and visible reliability improvement.

In a workforce model, the stock might be effective staffing capacity. Inflows include hiring, training, onboarding, retention, and experience. Outflows include turnover, burnout, retirement, absenteeism, and skill loss. Feedback connects workload to stress, stress to turnover, turnover to capacity, capacity to workload, and workload to pressure for hiring. Delays occur in hiring, onboarding, learning, fatigue accumulation, and recovery.

Feedback adds dynamic structure:

The model’s behavior emerges from these relationships. A reinforcing loop may cause rapid growth or decline. A balancing loop may stabilize a stock near a target. A balancing loop with delay may oscillate. A reinforcing loop constrained by a delayed limit may overshoot and collapse. Multiple loops may compete, with one dominating early and another dominating later.

This is why system dynamics is not simply data analysis. It is structure-based simulation. The analyst does not only fit a curve. The analyst builds a plausible causal structure and tests whether that structure can produce the observed pattern. If it cannot, the structure must be revised.

Back to top ↑

Why Simulation Is Needed

Simulation is needed because dynamic systems are often counterintuitive. Human intuition is usually better at short causal chains than delayed feedback systems. People tend to underestimate accumulation, misread delays, overreact to recent signals, underweight long-term effects, and assume that direct interventions will produce direct results. Simulation helps discipline intuition by showing how assumptions play out over time.

Simulation is especially useful when multiple feedback loops interact. A policy may strengthen one loop while weakening another. A reform may produce early gains while creating delayed costs. A system may behave differently when a stock crosses a threshold. A small change in response delay may determine whether a system stabilizes or oscillates. These behaviors are difficult to reason through mentally, especially across long time horizons.

Simulation also helps compare policies. Instead of asking whether a single intervention is good or bad, a model can compare scenarios: early action versus delayed action, capacity investment versus enforcement, prevention versus repair, gradual adjustment versus strong correction, or narrow metric optimization versus stock repair. The model may reveal that a policy with weak short-term results produces better long-term outcomes, or that a policy with visible early success creates later instability.

Simulation does not eliminate uncertainty. It organizes uncertainty. It allows analysts to ask which assumptions matter most, which parameters are sensitive, which outcomes are robust, and which policies fail under plausible conditions. A simulation is not valuable because it predicts the future perfectly. It is valuable because it improves the conversation about how the future might unfold.

In responsible systems work, simulation is a tool for learning, not a machine for certainty.

Back to top ↑

Model Structure and Behavior Over Time

A central principle of system dynamics is that model structure generates behavior. If a model contains reinforcing feedback, delayed balancing feedback, stock accumulation, and capacity constraints, those structures shape the behavior the simulation produces. The analyst evaluates whether the model’s behavior resembles the real system behavior that needs explanation.

Behavior-over-time graphs are therefore essential. They show whether a variable rises, falls, stabilizes, oscillates, overshoots, collapses, recovers, or relapses. The model should generate behavior patterns that make sense in relation to the problem. If a system has shown recurring backlog despite repeated fixes, the model should help explain recurrence. If an institution has seen slow trust erosion followed by sudden legitimacy crisis, the model should represent the accumulation and trigger logic. If an infrastructure system has escalating emergency repair costs, the model should connect backlog, deterioration, and funding shifts.

Model behavior can be compared with historical behavior. This does not mean the model must match every data point. Complex systems contain noise, uncertainty, shocks, and measurement error. The question is whether the model can reproduce the broad mode of behavior: growth, decline, oscillation, overshoot, stagnation, or recovery. If the model cannot reproduce the historical pattern, its structure may be incomplete or wrong.

Behavior comparison can reveal missing structure. A model that produces smooth stabilization may be missing delays if the real system oscillates. A model that produces steady growth may be missing limits if the real system plateaus or collapses. A model that predicts recovery may be missing trust erosion, capacity loss, or externalized burden if the real system resists reform.

System dynamics therefore treats simulation output as a diagnostic tool. The model’s failure to match observed behavior is not only a technical problem; it is a clue. It indicates that the analyst has not yet understood the structure that generates the pattern.

Back to top ↑

Delays, Nonlinearity, and Thresholds

System dynamics is especially useful for representing delays, nonlinear relationships, and thresholds. These features are common in complex systems and often explain why interventions fail or produce unexpected results.

A delay separates cause from effect. Hiring today may not increase effective capacity for months. Emissions today may affect climate risk over long time horizons. A trust repair effort may require repeated credible action before public behavior changes. Delays can cause misperception because the system’s response appears later than expected. They can also cause oscillation when decision-makers respond to outdated information.

Nonlinearity means that effects are not always proportional. A small increase in workload may be manageable at low stress levels but damaging when fatigue is already high. A small increase in debt may be manageable until interest burden crosses a threshold. A small decline in trust may have little effect until legitimacy collapses. A small ecological disturbance may be absorbed in a resilient system and destructive in a degraded one.

Thresholds mark points where behavior changes. A system may absorb stress until a buffer is depleted. After that, change can accelerate. This is why many crises seem sudden even when the underlying accumulation was slow.

Delays, nonlinearities, and thresholds make simulation valuable because their combined effects are hard to reason through intuitively. A model can test what happens when response is delayed, when capacity declines, when a buffer is depleted, or when a policy is introduced before or after a threshold.

A simulation model that excludes delays and thresholds may produce a false sense of stability. Responsible modeling asks where the system might behave differently under stress, depletion, or delayed correction.

Back to top ↑

Scenarios, Not Simple Predictions

System dynamics models are often most useful as scenario tools rather than prediction machines. A prediction claims that a specific outcome will occur. A scenario explores what could happen under a set of assumptions. In complex systems, scenario comparison is usually more honest and more useful than a single forecast.

Scenarios help analysts compare policy choices, test uncertainties, and examine tradeoffs. What happens if intervention begins early? What happens if response is delayed? What happens if demand grows faster than expected? What happens if trust declines? What happens if funding is temporary? What happens if a balancing loop is delayed? What happens if a stock crosses a threshold?

A system dynamics model can compare scenarios such as:

• baseline continuation;
• early prevention;
• delayed intervention;
• capacity investment;
• short-term symptom relief;
• strong enforcement without trust repair;
• gradual adaptive correction;
• high-demand stress case;
• low-resource austerity case;
• combined structural reform.

The goal is not to identify one perfect future. The goal is to understand how different assumptions and interventions shape possible behavior over time. A scenario may reveal that a policy works only under optimistic assumptions. Another may reveal that prevention is less dramatic but more robust. Another may reveal that delayed intervention becomes far more expensive. Another may reveal that improving one stock while ignoring another leads to relapse.

Scenario modeling is especially useful for public decision-making because it can make tradeoffs visible. A policy may reduce cost in the short term but increase backlog later. A prevention strategy may require early investment but avoid collapse. A trust-building intervention may be slow but durable. A narrow technical fix may improve one metric while weakening resilience. Scenarios help show what each path accumulates or depletes.

Good scenario work should include uncertainty, sensitivity testing, distributional effects, and stakeholder review. A scenario that only reflects the assumptions of powerful actors may reproduce their blind spots. A scenario that includes affected communities, frontline workers, ecological constraints, and long time horizons is more likely to reveal hidden consequences.

Back to top ↑

Model Testing, Validation, and Confidence

Validation in system dynamics does not mean proving that a model is perfectly true. A model is always a simplified representation. Validation means building confidence that the model is useful for its purpose, that its assumptions are transparent, that its structure is plausible, and that its behavior is relevant to the real system being studied.

System dynamics models can be tested in several ways. Boundary adequacy asks whether the model includes the main structures needed to explain the behavior. Dimensional consistency asks whether equations make sense in units. Extreme-condition testing asks whether the model behaves reasonably under very high or low values. Behavior reproduction asks whether the model can generate patterns similar to historical behavior. Sensitivity analysis asks which assumptions strongly affect results. Policy testing asks whether conclusions remain robust under plausible uncertainty.

Model testing should not be treated as a technical afterthought. It is part of systems learning. A model that fails a test can improve understanding by revealing missing structure. If stakeholders reject a relationship, the disagreement should be examined. If sensitivity analysis shows that results depend on one uncertain parameter, that parameter deserves more evidence. If the model cannot reproduce the historical pattern, the causal structure may need revision.

Confidence in a model should be proportional to its purpose. A model used for exploratory learning does not need the same precision as a model used to allocate major public resources. A model used to compare scenarios can be valuable even when uncertain, as long as its assumptions are transparent. A model used to justify high-stakes decisions requires stronger testing, documentation, and accountability.

The most dangerous model is not an imperfect one. All models are imperfect. The most dangerous model is one that hides its assumptions, exceeds its evidence, or presents uncertainty as certainty.

Back to top ↑

Policy Design, Leverage, and Intervention Testing

System dynamics is often used to test policy design. Because models represent feedback and accumulation, they can show why some interventions produce durable change while others create temporary improvement, unintended consequences, or policy resistance.

A weak intervention often acts on a symptom. It reduces visible pressure without changing the stock, flow, or feedback structure that generates the problem. For example, overtime may reduce backlog temporarily but increase fatigue and turnover. Emergency repair may restore service but leave maintenance backlog growing. A communication campaign may increase awareness but fail to rebuild trust if service quality does not change.

A stronger intervention changes the structure. It may reduce harmful inflows, increase repair flows, rebuild depleted stocks, shorten feedback delays, improve information quality, change incentives, alter goals, or expand legitimate capacity. System dynamics allows analysts to test whether a proposed intervention actually changes the structure or merely shifts symptoms.

Simulation can compare intervention strategies:

• increase capacity versus increase pressure;
• prevention versus emergency repair;
• trust repair versus enforcement escalation;
• maintenance funding versus deferred spending;
• staff retention versus hiring alone;
• burden reduction versus compliance monitoring;
• early intervention versus delayed correction;
• single policy lever versus combined structural reform.

Leverage is not always where attention first goes. Highly visible variables are not always high-leverage variables. A model may reveal that reducing delay, improving feedback, changing incentives, preserving buffers, or repairing trust produces more durable change than pushing harder on output. It may also reveal that some policies fail because they act too late, too weakly, or at the wrong level.

Policy testing should include distributional analysis. A policy may improve the average while worsening conditions for specific groups or places. A model that tracks only aggregate outcomes can hide unequal accumulation. Responsible intervention testing asks who benefits, who bears costs, when effects appear, and whether the system is shifting burden across boundaries.

Back to top ↑

Ethics, Power, and Modeling Responsibility

Simulation modeling has ethical stakes because models shape decisions. A model can make hidden dynamics visible, but it can also hide harm if its boundaries are too narrow. It can clarify long-term consequences, but it can also create false authority. It can support responsible governance, but it can also legitimize decisions that were already preferred by powerful actors.

Every model contains choices: what variables matter, what boundaries define the system, what time horizon counts, which data are trusted, whose knowledge is included, which harms are measured, which costs are externalized, and what outcomes are treated as success. These choices are not purely technical. They are ethical and political.

A model of public benefits that includes fraud risk but not administrative burden may justify restrictive policy. A workforce model that includes productivity but not fatigue may normalize overwork. A climate model that includes emissions but not displacement, justice, or adaptation capacity may miss uneven harm. An AI governance model that tracks accuracy but not appeal, accountability, or user harm may overstate system performance. A transportation model that tracks travel time but not induced demand, emissions, land use, or accessibility may misrepresent value.

Ethical modeling asks:

• Who helped define the model boundary?
• Whose experience is represented?
• Which stocks are included?
• Which stocks are ignored?
• What time horizon is used?
• What delayed harms are counted?
• What costs are externalized?
• How is uncertainty communicated?
• Who can challenge the assumptions?
• What decisions will the model influence?

Power also shapes model interpretation. A model can be used as a learning tool or as a weapon of authority. When decision-makers present model output without assumptions, uncertainty, or stakeholder review, the model can silence legitimate contestation. Responsible modeling should make assumptions visible enough to dispute. It should invite revision rather than demand obedience.

Models should clarify responsibility, not dissolve it. Complexity does not mean nobody is accountable. A model can show that harm arises from feedback, incentives, boundaries, and delays, but those structures are often designed, funded, maintained, ignored, or protected by institutions. Ethical system dynamics connects structure to responsibility.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

System dynamics models can be represented through difference equations, differential equations, stock-flow diagrams, causal-loop diagrams, simulation code, and scenario workflows. The level of mathematical detail should match the purpose of the model. A simple educational model may use discrete time steps. A more formal model may use continuous equations, sensitivity analysis, parameter estimation, and calibration.

The basic discrete stock-flow model is:

The continuous-time form is:

Feedback-controlled flows can be represented as:

A delayed feedback structure can be represented as:

A policy scenario model can be represented as:

A sensitivity analysis can be represented conceptually as:

Computation should not make the model less accountable. Code, data, assumptions, parameter values, and scenario definitions should be documented. Synthetic data should be labeled as synthetic. Uncertainty should be explicit. Model results should be interpreted as structured reasoning, not automatic truth.

Back to top ↑

Python Workflow: System Dynamics, Delayed Feedback, Scenario, and Sensitivity Diagnostics

The Python workflow below turns system dynamics into a small reproducible simulation. It compares four scenarios: symptom pressure response, capacity investment with delay, prevention and trust repair, and adaptive resilient policy. It also includes a simple sensitivity analysis for key assumptions. The script uses only the Python standard library, writes CSV outputs relative to the article folder, and is designed as a clear starting point for companion repository work.

# system_dynamics_simulation_modeling_workflow.py
# Dependency-light workflow for system dynamics, stock-flow simulation,
# delayed feedback, scenario comparison, validation checks, and sensitivity.
# Writes outputs relative to the article root.

from __future__ import annotations

from dataclasses import dataclass, replace
from pathlib import Path
import csv
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"


@dataclass
class DynamicsScenario:
    name: str
    initial_capacity: float
    initial_backlog: float
    demand_pressure: float
    service_productivity: float
    hiring_rate: float
    turnover_pressure: float
    training_delay: float
    feedback_delay: float
    trust_repair: float
    prevention_investment: float
    accountability: float
    shock_pressure: float


def clamp(value: float, low: float = 0.0, high: float = 160.0) -> float:
    return max(low, min(high, value))


def run_scenario(scenario: DynamicsScenario, periods: int = 60) -> list[dict[str, object]]:
    capacity = scenario.initial_capacity
    backlog = scenario.initial_backlog
    trust = 42.0 + scenario.trust_repair * 24.0
    fatigue = 18.0 + scenario.turnover_pressure * 20.0
    trained_capacity_pipeline = scenario.hiring_rate * 18.0
    backlog_history: list[float] = [backlog]
    capacity_history: list[float] = [capacity]
    rows: list[dict[str, object]] = []

    feedback_delay_steps = max(0, int(round(scenario.feedback_delay * 8.0)))
    training_delay_steps = max(0, int(round(scenario.training_delay * 8.0)))

    for period in range(periods + 1):
        feedback_index = max(0, len(backlog_history) - 1 - feedback_delay_steps)
        training_index = max(0, len(capacity_history) - 1 - training_delay_steps)
        perceived_backlog = backlog_history[feedback_index]
        delayed_capacity_reference = capacity_history[training_index]

        demand_inflow = clamp(
            scenario.demand_pressure * 20.0
            + scenario.shock_pressure * 12.0
            + max(0.0, 55.0 - trust) * 0.10
            - scenario.prevention_investment * 5.0,
            0.0,
            120.0
        )

        effective_productivity = clamp(
            scenario.service_productivity * 22.0
            + capacity * 0.18
            + trust * 0.06
            - fatigue * 0.10
            - max(0.0, backlog - 70.0) * 0.03,
            0.0,
            120.0
        )

        completions_outflow = clamp(
            effective_productivity
            + scenario.accountability * 6.0
            - max(0.0, fatigue - 55.0) * 0.08,
            0.0,
            120.0
        )

        pressure_for_hiring = clamp(
            max(0.0, perceived_backlog - 45.0) * 0.22
            + scenario.hiring_rate * 12.0
            + scenario.accountability * 4.0,
            0.0,
            100.0
        )

        trained_capacity_pipeline = clamp(
            trained_capacity_pipeline
            + pressure_for_hiring * 0.14
            - scenario.training_delay * 2.0
            - fatigue * 0.03,
            0.0,
            100.0
        )

        new_effective_capacity = clamp(
            scenario.hiring_rate * 6.0
            + trained_capacity_pipeline * 0.07
            + delayed_capacity_reference * 0.03
            - scenario.training_delay * 1.6,
            0.0,
            100.0
        )

        turnover_outflow = clamp(
            scenario.turnover_pressure * 8.0
            + fatigue * 0.10
            + max(0.0, backlog - 65.0) * 0.07
            - trust * 0.035
            - scenario.accountability * 2.0,
            0.0,
            100.0
        )

        capacity = clamp(
            capacity
            + new_effective_capacity * 0.18
            - turnover_outflow * 0.14
            + scenario.prevention_investment * 1.2,
            0.0,
            120.0
        )

        backlog = clamp(
            backlog
            + demand_inflow * 0.18
            - completions_outflow * 0.16
            - scenario.prevention_investment * 0.8,
            0.0,
            160.0
        )

        fatigue = clamp(
            fatigue
            + max(0.0, backlog - capacity) * 0.08
            + scenario.shock_pressure * 2.0
            - scenario.prevention_investment * 1.1
            - scenario.accountability * 0.9,
            0.0,
            100.0
        )

        trust = clamp(
            trust
            + scenario.trust_repair * 1.7
            + scenario.accountability * 1.4
            + max(0.0, completions_outflow - demand_inflow) * 0.04
            - backlog * 0.025
            - fatigue * 0.025,
            0.0,
            100.0
        )

        oscillation_pressure = clamp(
            scenario.feedback_delay * 8.0
            + scenario.training_delay * 6.0
            + abs(perceived_backlog - backlog) * 0.18
            + max(0.0, pressure_for_hiring - new_effective_capacity) * 0.12
            - scenario.accountability * 3.0,
            0.0,
            100.0
        )

        robustness_score = clamp(
            capacity * 0.22
            + trust * 0.20
            + completions_outflow * 0.18
            + scenario.prevention_investment * 12.0
            + scenario.accountability * 10.0
            - backlog * 0.18
            - fatigue * 0.16
            - oscillation_pressure * 0.10,
            0.0,
            100.0
        )

        rows.append({
            "period": period,
            "scenario": scenario.name,
            "backlog": round(backlog, 3),
            "capacity": round(capacity, 3),
            "trust": round(trust, 3),
            "fatigue": round(fatigue, 3),
            "perceived_backlog": round(perceived_backlog, 3),
            "demand_inflow": round(demand_inflow, 3),
            "completions_outflow": round(completions_outflow, 3),
            "pressure_for_hiring": round(pressure_for_hiring, 3),
            "new_effective_capacity": round(new_effective_capacity, 3),
            "turnover_outflow": round(turnover_outflow, 3),
            "oscillation_pressure": round(oscillation_pressure, 3),
            "robustness_score": round(robustness_score, 3),
        })

        backlog_history.append(backlog)
        capacity_history.append(capacity)

    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows to write: {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def summarize(rows: list[dict[str, object]]) -> list[dict[str, object]]:
    output: list[dict[str, object]] = []
    for scenario_name in sorted({row["scenario"] for row in rows}):
        subset = [row for row in rows if row["scenario"] == scenario_name]
        final = subset[-1]
        avg_backlog = mean(float(row["backlog"]) for row in subset)
        avg_oscillation = mean(float(row["oscillation_pressure"]) for row in subset)
        avg_robustness = mean(float(row["robustness_score"]) for row in subset)

        if float(final["robustness_score"]) >= 65 and float(final["backlog"]) <= 40:
            diagnostic = "simulation suggests durable system improvement"
        elif avg_backlog >= 70:
            diagnostic = "backlog remains structurally generated"
        elif avg_oscillation >= 45:
            diagnostic = "delayed feedback creates oscillation or mistimed correction"
        elif avg_robustness >= 55:
            diagnostic = "partial improvement with remaining structural risk"
        else:
            diagnostic = "policy structure remains weak under simulated conditions"

        output.append({
            "scenario": scenario_name,
            "final_robustness_score": final["robustness_score"],
            "final_backlog": final["backlog"],
            "final_capacity": final["capacity"],
            "final_trust": final["trust"],
            "final_fatigue": final["fatigue"],
            "average_backlog": round(avg_backlog, 3),
            "average_oscillation_pressure": round(avg_oscillation, 3),
            "average_robustness_score": round(avg_robustness, 3),
            "diagnostic": diagnostic,
        })

    return output


def sensitivity_analysis(base: DynamicsScenario) -> list[dict[str, object]]:
    base_rows = run_scenario(base)
    base_final = float(base_rows[-1]["robustness_score"])
    tests = [
        ("demand_pressure", -0.10),
        ("demand_pressure", 0.10),
        ("feedback_delay", -0.10),
        ("feedback_delay", 0.10),
        ("training_delay", -0.10),
        ("training_delay", 0.10),
        ("prevention_investment", -0.10),
        ("prevention_investment", 0.10),
        ("accountability", -0.10),
        ("accountability", 0.10),
    ]

    rows: list[dict[str, object]] = []
    for parameter, delta in tests:
        current_value = getattr(base, parameter)
        revised_value = max(0.0, min(1.0, current_value + delta))
        revised = replace(base, name=f"{base.name} sensitivity {parameter} {delta:+.2f}", **{parameter: revised_value})
        revised_rows = run_scenario(revised)
        revised_final = float(revised_rows[-1]["robustness_score"])
        rows.append({
            "parameter": parameter,
            "delta": delta,
            "base_final_robustness_score": round(base_final, 3),
            "revised_final_robustness_score": round(revised_final, 3),
            "score_change": round(revised_final - base_final, 3),
        })

    return rows


def main() -> None:
    scenarios = [
        DynamicsScenario("Symptom pressure response", 48.0, 68.0, 0.70, 0.48, 0.42, 0.68, 0.66, 0.62, 0.32, 0.24, 0.28, 0.58),
        DynamicsScenario("Capacity investment with delay", 50.0, 64.0, 0.62, 0.56, 0.66, 0.48, 0.58, 0.52, 0.48, 0.50, 0.48, 0.48),
        DynamicsScenario("Prevention and trust repair", 54.0, 58.0, 0.50, 0.64, 0.62, 0.36, 0.42, 0.38, 0.72, 0.76, 0.68, 0.36),
        DynamicsScenario("Adaptive resilient policy", 58.0, 52.0, 0.42, 0.74, 0.72, 0.28, 0.26, 0.26, 0.84, 0.84, 0.82, 0.28),
    ]

    rows: list[dict[str, object]] = []
    for scenario in scenarios:
        rows.extend(run_scenario(scenario))

    write_csv(TABLES / "system_dynamics_simulation_modeling_timeseries.csv", rows)
    write_csv(TABLES / "system_dynamics_simulation_modeling_summary.csv", summarize(rows))
    write_csv(TABLES / "system_dynamics_sensitivity_analysis.csv", sensitivity_analysis(scenarios[-1]))

    print("System dynamics simulation workflow complete.")
    print(TABLES / "system_dynamics_simulation_modeling_timeseries.csv")


if __name__ == "__main__":
    main()

The workflow is intentionally simple enough to inspect. It shows how backlog, capacity, trust, fatigue, delayed hiring, perceived backlog, and prevention interact over time. It also demonstrates why system dynamics models should compare scenarios and test assumptions rather than presenting a single numerical output as certainty. The model is synthetic and illustrative; it supports disciplined inquiry rather than replacing domain expertise, stakeholder evidence, or ethical judgment.

Back to top ↑

R Workflow: Simulation Summary and Scenario Visualization

The R workflow reads the Python-generated time-series and sensitivity outputs, creates scenario summaries, and exports base R plots for backlog, capacity, trust, fatigue, oscillation pressure, and robustness. It uses only base R so it remains portable across simple local environments.

# system_dynamics_simulation_modeling_diagnostics.R
# Base R workflow for simulation summary and scenario visualization.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

timeseries_path <- file.path(tables_dir, "system_dynamics_simulation_modeling_timeseries.csv")

if (!file.exists(timeseries_path)) {
  stop(paste("Missing", timeseries_path, "Run the Python workflow first."))
}

data <- read.csv(timeseries_path, stringsAsFactors = FALSE)

last_by_scenario <- do.call(
  rbind,
  lapply(split(data, data$scenario), function(df) df[nrow(df), ])
)

avg_backlog <- aggregate(backlog ~ scenario, data = data, FUN = mean)
avg_oscillation <- aggregate(oscillation_pressure ~ scenario, data = data, FUN = mean)
avg_robustness <- aggregate(robustness_score ~ scenario, data = data, FUN = mean)

names(avg_backlog)[2] <- "average_backlog"
names(avg_oscillation)[2] <- "average_oscillation_pressure"
names(avg_robustness)[2] <- "average_robustness_score"

final_fields <- last_by_scenario[, c(
  "scenario",
  "robustness_score",
  "backlog",
  "capacity",
  "trust",
  "fatigue"
)]

names(final_fields) <- c(
  "scenario",
  "final_robustness_score",
  "final_backlog",
  "final_capacity",
  "final_trust",
  "final_fatigue"
)

summary_table <- Reduce(
  function(x, y) merge(x, y, by = "scenario"),
  list(avg_backlog, avg_oscillation, avg_robustness, final_fields)
)

summary_table$diagnostic <- ifelse(
  summary_table$final_robustness_score >= 65 &
    summary_table$final_backlog <= 40,
  "simulation suggests durable system improvement",
  ifelse(
    summary_table$average_backlog >= 70,
    "backlog remains structurally generated",
    ifelse(
      summary_table$average_oscillation_pressure >= 45,
      "delayed feedback creates oscillation or mistimed correction",
      ifelse(
        summary_table$average_robustness_score >= 55,
        "partial improvement with remaining structural risk",
        "policy structure remains weak under simulated conditions"
      )
    )
  )
)

write.csv(
  summary_table,
  file.path(tables_dir, "system_dynamics_simulation_modeling_r_summary.csv"),
  row.names = FALSE
)

plot_metric <- function(metric, label, file_name) {
  png(file.path(figures_dir, file_name), width = 1200, height = 700)
  scenarios <- unique(data$scenario)
  plot(
    NA,
    xlim = range(data$period),
    ylim = range(data[[metric]], na.rm = TRUE),
    xlab = "Period",
    ylab = label,
    main = paste(label, "by System Dynamics Scenario")
  )
  for (scenario_name in scenarios) {
    subset_data <- data[data$scenario == scenario_name, ]
    lines(subset_data$period, subset_data[[metric]], lwd = 2)
  }
  legend("topleft", legend = scenarios, lwd = 2, cex = 0.8, bty = "n")
  grid()
  dev.off()
}

plot_metric("backlog", "Backlog", "backlog_trajectories.png")
plot_metric("capacity", "Capacity", "capacity_trajectories.png")
plot_metric("trust", "Trust", "trust_trajectories.png")
plot_metric("fatigue", "Fatigue", "fatigue_trajectories.png")
plot_metric("oscillation_pressure", "Oscillation pressure", "oscillation_pressure_trajectories.png")
plot_metric("robustness_score", "Robustness score", "robustness_score_trajectories.png")

sensitivity_path <- file.path(tables_dir, "system_dynamics_sensitivity_analysis.csv")
if (file.exists(sensitivity_path)) {
  sensitivity <- read.csv(sensitivity_path, stringsAsFactors = FALSE)
  write.csv(
    sensitivity[order(abs(sensitivity$score_change), decreasing = TRUE), ],
    file.path(tables_dir, "system_dynamics_sensitivity_ranked.csv"),
    row.names = FALSE
  )
}

print(summary_table)

This workflow supports the article’s central methodological claim: simulation modeling should connect structure to behavior over time, test alternative scenarios, and expose which assumptions most influence conclusions. The R outputs help readers compare whether a policy changes the underlying system or only shifts the visible symptom.

Back to top ↑

GitHub Repository

The companion repository for this article should help readers build and test system dynamics models, stock-flow simulations, delayed feedback examples, scenario comparisons, sensitivity analyses, validation workflows, and reproducible modeling documentation using synthetic datasets and multi-language examples.

articles/system-dynamics-and-simulation-modeling/
├── python/
│   ├── system_dynamics_simulation_modeling_workflow.py
│   ├── system_dynamics_baseline_model.py
│   ├── stock_flow_simulation.py
│   ├── delayed_feedback_simulation.py
│   ├── scenario_comparison.py
│   ├── sensitivity_analysis.py
│   ├── model_validation_checks.py
│   ├── validation_checks.py
│   └── run_all_system_dynamics_workflows.py
├── r/
│   ├── system_dynamics_simulation_modeling_diagnostics.R
│   ├── stock_flow_simulation.R
│   ├── behavior_over_time_plots.R
│   ├── scenario_comparison.R
│   ├── sensitivity_summary.R
│   ├── validation_diagnostics.R
│   └── run_all_system_dynamics_workflows.R
├── julia/
│   ├── continuous_system_dynamics_model.jl
│   ├── delayed_feedback_dynamics.jl
│   └── nonlinear_threshold_simulation.jl
├── sql/
│   ├── schema_model_variables.sql
│   ├── schema_stocks_flows.sql
│   ├── schema_parameters.sql
│   ├── schema_scenarios.sql
│   ├── schema_simulation_runs.sql
│   └── schema_model_outputs.sql
├── rust/
│   └── simulation_diagnostics_cli.rs
├── go/
│   └── scenario_runner_utility.go
├── cpp/
│   ├── efficient_stock_flow_solver.cpp
│   └── sensitivity_scan.cpp
├── fortran/
│   └── continuous_dynamics_solver.f90
├── c/
│   └── low_level_stock_flow_engine.c
├── docs/
│   ├── modeling_principles.md
│   ├── article_notes.md
│   ├── validation_framework.md
│   ├── scenario_design_notes.md
│   ├── assumptions_and_limitations.md
│   └── responsible_use.md
├── data/
│   ├── synthetic_model_variables.csv
│   ├── synthetic_stocks_flows.csv
│   ├── synthetic_parameters.csv
│   ├── synthetic_scenarios.csv
│   ├── synthetic_simulation_runs.csv
│   └── synthetic_model_outputs.csv
├── outputs/
│   ├── figures/
│   └── tables/
└── notebooks/
    ├── python_system_dynamics_walkthrough.ipynb
    └── r_simulation_visualization_placeholder.ipynb

This repository structure supports the article’s central argument: system dynamics uses simulation to connect structure with behavior over time. The data/ folder separates variables, stocks and flows, parameters, scenarios, simulation runs, and outputs. The python/ and r/ folders support baseline modeling, stock-flow simulation, delayed feedback analysis, scenario comparison, sensitivity analysis, and validation diagnostics. The julia folder supports continuous-time and nonlinear dynamics. The sql folder defines schemas for model structure, parameters, scenarios, runs, and outputs. The lower-level language folders provide scaffolds for efficient solvers, diagnostics, scenario execution, and low-level simulation engines.

Back to top ↑

Back to top ↑

Back to top ↑

Why Simulation Modeling Matters

System dynamics and simulation modeling matter because complex systems often deceive intuition. They hide accumulation, delay consequences, shift burdens, amplify small changes, resist interventions, and produce behavior that cannot be understood from isolated events. Simulation helps analysts connect structure to behavior over time.

A good model does not claim to capture everything. It clarifies what it includes, what it excludes, what assumptions it makes, and what behavior it is designed to explain. It allows people to compare scenarios, test interventions, examine delays, locate sensitive assumptions, and ask whether a policy changes the underlying structure or merely changes visible activity.

Simulation is especially valuable for responsible governance because many harms are delayed. A model can reveal that prevention matters before collapse, that repair takes time, that trust is a stock, that backlog accumulates, that capacity can erode, and that short-term success may create long-term risk. It can also reveal when an intervention shifts costs to people or places outside the official frame.

System dynamics is not about replacing human judgment with models. It is about improving judgment by making dynamic assumptions visible. In complex systems, that visibility is one of the first conditions of responsible action.

Back to top ↑

Related Articles

• Stocks, Flows, and the Architecture of Change
• Causal Loop Diagrams and the Logic of Interaction
• Feedback Loop Polarity and Causal Signs
• Delays, Oscillation, and Misperception
• Delayed Feedback and Policy Timing
• Overshoot, Collapse, and Correction
• Dynamic Complexity and Policy Resistance
• Stock-Flow Thinking in Social Systems

Further Reading

• Forrester, Jay W. Industrial Dynamics. MIT Press.
• Forrester, Jay W. World Dynamics. Wright-Allen Press.
• Sterman, John D. Business Dynamics: Systems Thinking and Modeling for a Complex World. Irwin/McGraw-Hill.
• Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing.
• Richardson, George P. Feedback Thought in Social Science and Systems Theory. University of Pennsylvania Press.
• Senge, Peter M. The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday/Currency.
• Barlas, Yaman. “Formal Aspects of Model Validity and Validation in System Dynamics.” System Dynamics Review.
• Homer, Jack B. and Hirsch, Gary B. “System Dynamics Modeling for Public Health: Background and Opportunities.” American Journal of Public Health.

Back to top ↑

References

• Barlas, Y. (1996) “Formal Aspects of Model Validity and Validation in System Dynamics.” System Dynamics Review, 12(3), pp. 183–210.
• Forrester, J.W. (1961) Industrial Dynamics. Cambridge, MA: MIT Press.
• Forrester, J.W. (1971) World Dynamics. Cambridge, MA: Wright-Allen Press.
• Homer, J.B. and Hirsch, G.B. (2006) “System Dynamics Modeling for Public Health: Background and Opportunities.” American Journal of Public Health, 96(3), pp. 452–458. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1470514/
• Meadows, D.H. (2008) Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing. Available at: https://www.chelseagreen.com/product/thinking-in-systems/
• MIT OpenCourseWare (2013) Introduction to System Dynamics. Massachusetts Institute of Technology. Available at: https://ocw.mit.edu/courses/15-871-introduction-to-system-dynamics-fall-2013/
• Richardson, G.P. (1991) Feedback Thought in Social Science and Systems Theory. Philadelphia: University of Pennsylvania Press.
• Senge, P.M. (1990) The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday/Currency.
• Sterman, J.D. (1989) “Misperceptions of Feedback in Dynamic Decision Making.” Organizational Behavior and Human Decision Processes, 43(3), pp. 301–335.
• Sterman, J.D. (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill.

Back to top ↑