The Case for a Code‑Centric System Dynamics Platform
A concise manifesto for modelers who build, run, and evolve real systems.
Visual SD tools were designed for the projector, not the operator
Classic stock‑and‑flow software treats a model as something you show: drag nodes, wire arrows, hit “simulate,” paste the chart into a slide deck. That workflow is powerful for teaching or one‑off workshops, but it collapses under real‑world pressure:
- Opaqueness Diagram elements hide the actual equations; small edits have invisible side‑effects.
- Diff‑proof You cannot meaningfully code‑review a screenshot.
- Single‑player Two modelers can’t merge work the way engineers merge pull‑requests.
- Static Models are calibrated once, then drift as the organisation’s data, policies, and architecture change.
Visual SD is the no‑code studio of system modeling: accessible, but ultimately limiting when multiple teams, live data, and continuous change enter the picture.
Code moves models from artifact to infrastructure
A model expressed in Python + SQL—augmented with SD‑specific primitives—behaves like any other service in the software stack:
| Engineering Expectation | What a Code‑Centric SD Runtime Delivers |
|---|---|
| Version control | Equations, parameters, and documentation live in Git; history is auditable. |
| Continuous testing | CI re‑runs scenarios on every commit; regressions break the build instead of surprising the CFO. |
| Composable abstractions | Reusable archetypes (SIR(), inventory_chain()) import like libraries, not copy‑paste diagrams. |
| Data integration | SQL views, Kafka streams, or Parquet files feed directly into state variables—no brittle CSV dance. |
| Observability | Logs, metrics, and traces flow to the same dashboards as microservices, enabling alerting on model drift. |
In short, the model graduates from presentation layer to living digital twin: continuously evaluated, provably correct, and owned collectively.
Foundational Building Blocks for a Code‑Centric SD Platform
| Layer | Purpose | Typical Interfaces & Tech Options |
|---|---|---|
| Model & Artifact Registry | Single source of truth for model code, parameters, trained surrogates, lineage metadata | Git repositories; OCI artifact stores; MLflow or Weights & Biases registries |
| Data Fabric | Reliable ingestion & governance of historical and streaming signals that feed the models | Warehouse (Snowflake/BigQuery), Lakehouse (Iceberg/Delta), Kafka topics, CDC pipelines |
| Federated Query Engine | Uniform way to fetch calibration data or simulation outputs across heterogeneous stores | DuckDB, Trino/Starburst, Spark SQL, Polars on‑demand |
| Simulation Runtime | Deterministic & stochastic integrators that execute SD models at scale | Vectorised NumPy/JAX core, optional GPU kernels; Dask or Ray for embarrassingly parallel sweeps |
| Learning Runtime | Train ML surrogates, policy optimisers, or parameter posteriors from simulation traces | PyTorch/JAX trainers; probabilistic frameworks (NumPyro, PyMC) |
| Experiment Orchestrator | Schedule, track, and compare scenario batches; allocate cluster resources | Airflow, Prefect, K8s CronJobs, Argo Workflows |
| Observability Stack | Telemetry for both the runtime and the model outputs; anomaly alerts | OpenTelemetry traces, Prometheus metrics, Grafana dashboards |
| Visualization & API Layer | Auto‑generated causal‑loop/stock‑flow diagrams and interactive dashboards for stakeholders | Mermaid/Graphviz renderers, React or Streamlit front‑ends, REST/GraphQL for programmatic access |
| Governance & Policy Guardrails | Access control, audit logs, model‑risk management, and compliance attestation | Git‑based change approvals, data‑quality contracts, lineage graphs |
These blocks are modular by design. Each can be swapped or scaled independently, letting an organisation evolve capability without rewriting the entire stack.
Why this matters for organisations, not just modelers
- Shared reality Finance, operations, and engineering see the same repo; debates focus on parameters, not screenshots.
- Faster policy cycles A pull request that tweaks replenishment logic can ship to staging tonight and influence tomorrow’s purchase orders.
- Governance by design Every equation is attributable; every scenario run is reproducible; compliance audits read like software changelogs.
- Scalable experimentation Parameter sweeps or Monte‑Carlo runs spin out on Ray clusters, then land in BI dashboards automatically.
A collective call, not a product pitch
There is no shrink‑wrapped platform to buy—yet. The invitation is to treat models as first‑class code, assemble the building blocks above, extend the Python ecosystem with SD‑specific types, and wire everything into the Git‑based, CI‑driven culture modern engineering already trusts.
Visual tools will remain valuable for teaching and sketching. But when the goal is to steer a complex, evolving system across many teams, the only durable medium is code.
Let’s bring system dynamics into the toolchain where the system already lives.
The moment your feedback loops compile, commit, and deploy like the software they guide, modeling stops being a slide and starts being strategy.