There is a persistent gap between how complex systems are understood and how they are actually engaged. Most people who work on hard problems — chronic illness, organizational dysfunction, social fragility — are working with frameworks built for a simpler kind of problem. They diagnose causes. They design corrections. They implement them. And then they encounter the feature that defines complex systems: the system pushes back.
Not because the diagnosis was wrong. Not because the implementation was poor. Because the dynamics that maintain a harmful pattern are structural, not incidental — and structural problems do not yield to interventions aimed at their surface.
This is the problem ISRD is organized around. And the tools are not incidental to that mission. They are the argument made practical.
What the Tools Are Not For
It is worth saying what the simulation toolkit is not, because the most likely mental model is wrong.
The simulations are not demonstrations. They are not interactive textbook exhibits where a learner watches a feedback loop animate in order to understand what a feedback loop is. That would be useful. It is not what this is.
They are not dashboards for displaying pre-existing data. They do not tell you what already happened in some system somewhere. They are forward-running models, driven by feedback logic, in which behavior emerges from the structure rather than being plotted from a record.
And they are not visualizations in the ordinary sense — pictures of complexity that convey the impression of rigor without its requirements. Every gauge in an ISRD simulation is a node in a directed feedback graph. Every parameter adjustment propagates. The rendering is visual, but the engine is causal.
The distinction matters because what you use a tool for determines what you learn from it. A simulation used as a demonstration teaches you what something looks like. A simulation used as an intervention instrument teaches you what something does — and, critically, what it responds to.
The Problem That Makes the Tools Necessary
Complex systems maintain their states. This is not a malfunction. It is how complex systems work: feedback loops, social reinforcement, institutional inertia, and delay combine to create basins of attraction — regions of the system's behavior space that it keeps returning to, even under significant perturbation. The same patient relapses after treatment. The same organization reconstructs its dysfunction after restructuring. The same policy initiative encounters the same resistance it has always encountered.
Understanding why this happens requires a different analytical framework than the one most practitioners are trained in. It requires being able to see the feedback structure rather than the surface events, to identify the attractor state the system is maintaining and the mechanisms that maintain it, and to locate the leverage points where an intervention can actually change the dynamics rather than temporarily displacing them.
This is what ISRD calls systems literacy. And systems literacy, like every form of literacy, is not transferred by description — it is built through practice.
A practitioner who has read about attractors knows the word. A practitioner who has run a simulation, adjusted a parameter, watched the system return to its stable state despite the adjustment, and then found the leverage point that actually shifts the basin — that practitioner has built a mental model that transfers. They can recognize attractor dynamics in their own domain. They can formulate intervention hypotheses that the framework supports. They can look at a chronic problem and see it differently than they did before.
The tools exist to produce that transfer. That is the mission-level argument for building them.
Three Layers of the Toolkit
The ISRD simulation infrastructure has three layers, each targeting a different practitioner need.
The Markdown Simulator
The entry point is the free .md Sim Creator. It is designed for the most common case: a practitioner who wants to illustrate a complex systems concept in something they are already writing — an article, a report, a course document — without requiring the reader to leave the page, install anything, or take a tutorial.
The output is a Markdown code block using the isrd-sim syntax. The practitioner selects a simulation type, configures its parameters, and copies the embed code. Readers with the ISRD plugin encounter a live, interactive simulation in place — not a screenshot, not a link to somewhere else, but a running model with adjustable parameters that responds in real time.
The available simulation types are not arbitrary. Era 3 simulations — emergence and flocking, feedback loops, the Lorenz attractor — cover the foundational dynamics of complexity science: the behavior that emerges from simple rules applied iteratively, the sensitive dependence on initial conditions that makes complex systems resist prediction, the attractor geometry that explains why interventions fail when they do not address the maintaining feedback structure. Era 4 network diffusion covers how dynamics spread through connected populations. Era 5 backroom dynamics covers the dual-layer reality of formal and informal networks — the invisible influence structure beneath the org chart that determines what actually happens when anything changes.
The free tier is a literacy instrument. It does not require a subscription or an account. It requires only that someone has something to say about a complex system and wants the reader to experience the dynamics rather than just read about them.
The Expert HTML Simulator
The second layer is for practitioners who are not illustrating complexity — they are modeling it. The Expert .html Sim Creator works differently. The practitioner does not select from a library of demo types. They describe their system. An AI conducts a structured diagnostic intake, asking targeted questions to extract the system's agent properties, feedback weights, and risk architecture. It then constructs a domain schema — a full specification of the simulation in terms of the practitioner's actual domain.
The output is a self-contained .html file. No dependencies. No server. No account required to distribute or use it. The researcher can email it, publish it, archive it, or hand it to a colleague who has never heard of ISRD and have them run it without any further explanation.
This is important for a reason that is not immediately obvious. One of the consistent failure modes in applied systems work is the gap between the person who built the model and the people who need to use it. Technical tools stay in technical hands. The domain knowledge that makes a model meaningful is isolated in specialists who do not have the tools. The Expert sim creator is designed to close that gap: a clinician, a policy analyst, an organizational consultant brings the domain knowledge; the AI and the simulation engine handle the technical construction; the output is a working model that the domain expert can adjust, run, and share without an intermediary.
The system also includes a YOU character — a feature that allows the practitioner to map themselves or a specific participant onto the simulation. This is not a cosmetic feature. It is a deliberate pedagogical structure: the most durable form of understanding is understanding that places the learner inside the system they are modeling, not outside it observing it. When the simulation includes a representation of the practitioner's own position in the feedback structure, the experience of adjusting parameters and watching outcomes propagate becomes personal in a way that changes what is learned.
The Sim-Toolkit SDK
The third layer is for builders. The Sim-Toolkit SDK is the React/TypeScript library that powers the entire ISRD simulation engine. Every simulation on the site runs on it. The SDK is available for anyone building custom simulation laboratories — researchers constructing their own study environments, organizations building internal modeling tools, developers extending the platform.
The core hook, useSystemicSimulation, manages attractor states, the feedback graph, and the simulation tick loop. The FeedbackLoop component handles the directed graph of nodes and edges that underlies every simulation. The AttractorBasin component models stable states and computes basin classification and stability. The DomainSchema interface is the TypeScript contract that the AI dialogue produces — a structured specification that connects the practitioner's domain knowledge to the simulation engine.
The SDK is the layer at which ISRD's methodology becomes infrastructure. The same evolutionary design principles that govern ISRD project work — structured cycles of variation, testing, and selection — govern how labs built on the SDK are developed and extended.
The Three-Step Logic
Across all three layers, the same logic governs how a practitioner engages with the toolkit.
First, describe the system. Not the problem — the system. What are the actors? What feedback structures connect them? What external forces shape the dynamics? What stable states is the system currently maintaining, and what mechanisms maintain them? This is Phase 1 of the ISRD project cycle made interactive: the structured survey that produces the map the rest of the work depends on.
Second, dialogue. The AI asks diagnostic questions. It does not assume what kind of system the practitioner has described, or what intervention logic the domain requires. It extracts. It maps the practitioner's domain onto simulation concepts — not by substituting jargon for other jargon, but by identifying which feedback structures in the domain correspond to which dynamics in the model. This is where domain knowledge and systems science make contact, and where the literacy building that makes the simulation meaningful actually occurs.
Third, simulate. Run the model. Adjust parameters. Watch the system respond. Look for the leverage points — the places where a small intervention produces a large and durable shift in behavior, as opposed to the places where an intervention produces temporary displacement followed by return to the original state. Discover what the system actually does, not what you expected it to do. This is the experience that transfers.
The three steps are a structured perturbation of the practitioner's existing mental model. Step one surfaces it. Step two challenges it — the AI's diagnostic questions force the practitioner to account for system elements and feedback relationships they had not made explicit. Step three tests whether the resulting model corresponds to what the system actually does. This is attractor-shifting for practitioners, built into the workflow of building a simulation.
Why This Matters Beyond the Tool
ISRD's methodology is explicit about the relationship between tools and mission. The toolkit is not a product that exists for its own sake while the real work happens elsewhere. It is the mechanism by which the methodology reaches practitioners.
The most valuable thing ISRD can produce is practitioners who think in systems about their domain's hardest problems. Not practitioners who know the vocabulary of systems science, but practitioners who have built working mental models of the dynamics they are working in — who can see the attractor, identify the maintaining feedback structure, locate the leverage point, and formulate an intervention hypothesis that the framework supports.
That does not happen through reading. It happens through practice with models that actually run — models that respond to intervention hypotheses, that show what the system does when the leverage point is found and what it does when it is not, that make the dynamics visible in a way that description alone cannot achieve.
The simulations are the practice environment. The SDK is the infrastructure that makes that environment extensible to every domain where the problem exists. The AI dialogue is the bridge that makes the environment accessible to domain experts who are not simulation engineers.
Each layer exists because the layer before it is insufficient on its own. A description of complexity is not enough. A demonstration is not enough. A demonstration the practitioner can configure to their own domain is closer. A running model of the practitioner's actual system, with the practitioner's own position represented in it, is what actually shifts the attractor.
That is the argument. The tools are its execution.
Who Needs This
The practitioner who belongs in this toolkit is recognizable by one consistent feature: they are working on a problem that has resisted the best available intervention approaches applied by skilled, well-resourced people. Not because those people were wrong. Not because they lacked expertise. Because the problem's maintaining structure is at a level those approaches were not designed to address.
That describes a significant portion of the hardest problems in medicine, organizational development, policy, and research methodology. It describes exactly the problems this toolkit exists to work on — and the tools are how that work becomes accessible to the practitioners who need it most.
The Free .md Sim Creator is available now. The Sim-Toolkit SDK is active. Explore the simulations →