One-sentence answer: A simulation works by executing a model under declared starting conditions, rules and scenarios so we can observe possible system trajectories without first imposing those experiments on the real system—and then checking whether the simulation is implemented correctly, represents reality well enough for its intended use, and remains honest about uncertainty.
Simulation is one of humanity’s most powerful ways to learn before acting. Engineers simulate airflow before building an aircraft. Weather centres run numerical models before issuing forecasts. Manufacturers simulate production lines before moving machines. Students rehearse oral examinations. Pilots train in flight simulators. Epidemiologists explore transmission scenarios. Computer scientists stress-test systems before release.
These activities look different, but they share a common architecture: a representation of the world is made executable, allowed to evolve under specified rules, and its outputs are inspected before—or alongside—real-world action.
A simulation is not a second reality. It is a controlled rehearsal inside a model whose usefulness must eventually be tested against the first reality.
PHASE 4++++ · DEFINITIVE SIMULATION MAP
How to Read This Simulation Guide
A simulation is an executable conditional world. It allows a model to unfold through time, events or repeated interactions so that trajectories, thresholds and failure paths can be inspected before the corresponding real-world action is taken. Its power comes from controlled rehearsal; its limit is that every result remains inside the assumptions of the model and scenario that produced it.
The invariant simulation chain
Question and intended use → real-world target → model and version → scenario → initial state → parameters and rules → randomness or event logic → execution → trajectory and outputs → repeated runs where justified → verification → validation against external observations → sensitivity → decision, training or redesign → world return.
The simulation can expose what the model implies; it cannot independently prove that the model describes reality. Repetition explores the model’s possible paths, while validation requires evidence from outside the simulated world.
What this article owns
This article owns the general mechanism by which a model becomes executable and produces conditional trajectories or rehearsals.
Models own the underlying representation. Scenarios own the declared conditions being explored. Probability owns coherent weighting where justified. Forecasting owns claims about likely future states. Counterfactuals own comparisons with unrealised alternatives. Observation owns the external evidence needed for validation. Decision-making owns whether a simulated result should change action.
The conditional-world test
A dramatic simulated outcome means: the model produced this path under these starting conditions, rules and assumptions. It does not automatically mean the path is likely, that no omitted mechanism would alter it, or that the receiver should act as though it has already happened.
The useful question is whether the simulation changes a robust decision, identifies a critical threshold, improves training or reveals which real-world observation should be collected next.
Four distinctions that prevent simulation theatre
- Simulation is not observation. It generates consequences of a representation; it does not create fresh independent evidence about the target world.
- Verification is not validation. Correct code can execute the intended model perfectly while the model itself represents the real system poorly.
- A scenario is not a forecast. Exploring what happens under a condition does not assign that condition a probability.
- Repeated runs are not repeated experiments on reality. More runs reduce computational sampling noise where relevant, but they cannot repair an omitted mechanism, biased input distribution or wrong boundary.
Clickable deep routes
- How Models Work — the assumptions, boundaries and relationships every simulation executes.
- How Observation Works — the external records needed to validate simulated behaviour.
- How Uncertainty Works — the input, parameter, structural and scenario uncertainty carried into outputs.
- How Sensitivity Analysis Works — which assumptions and parameters drive the simulated result.
- How Forecasting Works — when model outputs and evidence become time-bound expectations rather than conditional rehearsals.
- How Counterfactuals Work — how alternative states and interventions are compared when only one real path occurs.
- How X Works Master Hub — return to the wider mechanism library.
A definitive simulation identifies the model, scenario, version, starting state, rules and uncertainty; shows which conclusions survive perturbation; and returns to the real world before rehearsal is mistaken for evidence that the future has already been observed.
Quick Read: the causal chain
QUESTION → REAL-WORLD TARGET → MODEL → SCENARIO → INITIAL STATE → PARAMETERS → RULES / DYNAMICS → RANDOMNESS WHERE RELEVANT → EXECUTION → TRAJECTORY → OUTPUTS → REPEATED RUNS → DISTRIBUTION / FAILURE PATHS → VERIFICATION → VALIDATION → UNCERTAINTY → DECISION BOUNDARY → REAL-WORLD CHECK → REVISION
The critical final arrow is the one most easily forgotten. Simulation becomes safer and more useful when its outputs remain answerable to observations outside the simulation.
1. Simulation begins with a model
A simulation cannot escape the model underneath it. If the model omits an important mechanism, uses the wrong boundary, relies on unrealistic assumptions or has poor data, running it a million times does not repair the underlying representation.
This is why How Models Work comes first. A model selects which parts of reality to represent. A simulation then executes that representation through time, events, agents, states or repeated calculations.
| Model | A representation of selected relationships in a target system. |
|---|---|
| Simulation | An execution of a model under specified conditions. |
| Scenario | A declared set of conditions or assumptions supplied to the simulation. |
| Run | One execution of the simulation. |
| Trajectory | The sequence of states produced during a run. |
| Outcome | A result extracted from the trajectory for the question being studied. |
2. The scenario defines the world being rehearsed
Simulation asks a conditional question: if these starting conditions and rules held, what would the model do? The answer is conditional on the scenario.
- What is the initial state?
- Which inputs vary?
- Which constraints remain fixed?
- What time horizon matters?
- Which actors or components are represented?
- What happens when a threshold is crossed?
- What failures are allowed?
- What uncertainty is sampled?
Scenario discipline matters because a dramatic output from an extreme scenario does not mean the real world is likely to follow that path. It means the model followed that path under those declared assumptions.
3. Simulation turns relationships into trajectories
Some models are static: they describe relationships at one state. Simulation adds execution. The system changes step by step, event by event or continuously according to the model’s rules.
Different simulation families encode this evolution differently:
| Simulation family | Core idea | Typical use |
|---|---|---|
| Continuous / numerical | Equations evolve system states through time. | Physics, weather, fluids, engineering |
| Discrete-event | State changes when events occur. | Queues, factories, logistics, services |
| Agent-based | Individual agents follow rules and interact. | Crowds, epidemics, markets, social systems |
| Monte Carlo | Repeated random sampling explores outcome distributions. | Risk, uncertainty, reliability, finance |
| Hardware / human-in-the-loop | Real operators or components interact with a simulated environment. | Flight, driving, defence, training |
| Digital-twin style | Operational data and models represent a live or evolving asset. | Manufacturing, infrastructure, maintenance |
These are not interchangeable labels. The appropriate simulation structure depends on the question and the mechanisms that must be represented.
4. Randomness can reveal distributions that one run hides
Many systems contain variability or uncertain inputs. A single simulation run can therefore be dangerously seductive: it produces a clean story, but that story may be only one possible path.
Repeated runs can reveal:
- the spread of plausible outcomes;
- rare but consequential paths;
- threshold behaviour;
- which inputs drive most variation;
- how often a service level is missed;
- whether an apparently good design is fragile.
NIST’s work on simulation uncertainty emphasises that uncertainty and sampling quality need explicit assessment so users understand the significance and limitations of simulated data. A thousand runs are valuable only when the model, random process, parameters and stopping logic are themselves defensible.
5. Verification and validation are different questions
This distinction is foundational in serious simulation work.
| Question | Meaning |
|---|---|
| Verification | Did we build or implement the computational model correctly? |
| Validation | Does the model represent the real system accurately enough for the intended use? |
| Uncertainty quantification | How do uncertain inputs, parameters, numerical methods and model choices affect the outputs? |
| Credibility | Is the total evidence strong enough for the decision being asked of the simulation? |
NIST’s NISTIR 8298 treats verification and validation as independent but complementary procedures for assessing simulation accuracy, with uncertainty quantification identifying and estimating factors that affect results. It also warns that these are necessary but not sufficient for overall simulation credibility.
A simulation may therefore be coded perfectly and still model the wrong reality. Or it may have a sound model but a software defect. Those failures require different repairs.
6. Validation needs observations outside the simulation
Simulation cannot validate itself. At some point, outputs must be compared with observations, experiments, operational records or other relevant world evidence. The comparison should reflect the intended use, not merely a convenient quantity that happens to fit.
That creates a correction loop:
MODEL → SIMULATE → PREDICT / REHEARSE → OBSERVE THE WORLD → COMPARE → EXPLAIN DISCREPANCY → REVISE MODEL / PARAMETERS / RANGE → SIMULATE AGAIN
The neighbouring articles How Observation Works and How Comparison Works carry those two handoffs.
7. A realistic-looking simulation can still be wrong
Visual realism is psychologically powerful. Smooth animation, high-resolution graphics and large datasets can make a simulation feel authoritative even when its causal structure is weak.
Ask instead:
- Which mechanisms drive the output?
- Which relationships have empirical support?
- Which assumptions are conveniences?
- What happens if an assumption is relaxed?
- Which real observations were reserved for validation?
- Where has the model failed?
A crude simulation with transparent assumptions and strong validation can be more useful than a cinematic simulation whose assumptions cannot be inspected.
8. Sensitivity analysis asks what actually drives the result
If a small change in one uncertain input completely reverses the output, the decision is fragile. Sensitivity analysis varies inputs, parameters or structural choices to identify which assumptions matter most.
This can tell us where additional evidence is worth collecting. If the result barely changes across a wide range of plausible values, that uncertainty may not be decision-critical. If one poorly known parameter dominates the result, measuring it better may be more valuable than increasing simulation resolution elsewhere.
9. Simulation ≠ prediction ≠ forecast
| Simulation | Executes a model under specified conditions to produce trajectories or outcomes. |
|---|---|
| Prediction | A claim about an unobserved state or outcome. |
| Forecast | A time-bounded expectation about a future state, usually updated as evidence changes. |
| Scenario | A conditional set of assumptions, not necessarily an estimate of what will happen. |
A simulation can explore a scenario without claiming the scenario is likely. It can also produce inputs to a forecast. Keeping these jobs separate prevents “the computer showed this future” from becoming a false statement of certainty.
10. Worked example: a school canteen queue
Suppose a school wants to reduce lunch queues. A discrete-event simulation could represent student arrivals, serving stations, service-time distributions, payment delays and seating capacity.
The team might test scenarios:
- open one additional serving station;
- stagger lunch release by five minutes;
- separate quick-purchase and cooked-meal queues;
- change payment workflow;
- increase staff during the peak 15 minutes.
The simulation could estimate queue length and waiting-time distributions. But a good decision does not end there. The school should compare predicted waits with observed waits after a pilot. It should also measure receiver effects: Does the change reduce time to eat? Does it create crowding elsewhere? Does it disadvantage students with mobility needs? A local queue improvement can still be a system-level failure.
11. Simulation across domains
| Domain | What simulation can help explore | Boundary |
|---|---|---|
| Engineering | Loads, flows, failure conditions, design alternatives | Simulation does not replace required tests or safety authority. |
| Weather and climate | Atmospheric trajectories and scenario response | Outputs remain model- and initial-condition-dependent. |
| Public health | Transmission patterns and intervention scenarios | A population model does not diagnose an individual. |
| Manufacturing | Throughput, bottlenecks, buffers, changeovers | Real process variability and human behaviour require validation. |
| Transport | Traffic, routing, demand and disruption | Current world state can invalidate a static scenario. |
| Education | Rehearsal, role-play, exam practice, process scenarios | Simulated performance must transfer to authentic tasks. |
| AI | Agent interactions, test environments, synthetic scenarios | Synthetic success is not automatic real-world safety or reliability. |
12. Simulation can train people as well as test systems
Flight simulators, emergency drills, mock interviews, clinical simulations and examination rehearsals all use controlled environments to practise decisions before the stakes are real.
But training transfer is a separate question. A learner may become excellent at the simulator while failing in the target environment if the cues, stressors, timing or consequences differ. World-class simulation therefore asks not only “Did performance improve in the rehearsal?” but “Did the intended capability transfer when the world changed?”
13. Common simulation failures
| Failure | What goes wrong | Repair |
|---|---|---|
| Model error | The simulated relationships do not represent the important real mechanism. | Revisit model structure and evidence. |
| Implementation error | Code or execution does not match the intended model. | Verification, tests and independent checks. |
| Parameter overconfidence | Uncertain values are treated as fixed truth. | Use ranges, distributions and sensitivity tests. |
| Single-run storytelling | One trajectory is mistaken for the outcome. | Repeat runs where stochastic variation matters. |
| Scenario laundering | A hypothetical case is reported as a forecast. | Label scenario assumptions and likelihood separately. |
| Visual realism bias | Graphic polish is mistaken for validity. | Inspect evidence, assumptions and validation. |
| Post-result scenario selection | Only favourable runs or scenarios are shown. | Predeclare analyses or report the exploration set. |
| No world return | The simulation is never compared with operational outcomes. | Design a validation and monitoring loop. |
14. Hostile test: reproduce, perturb, compare
A serious simulation should survive three kinds of challenge:
- Reproduce: Can another analyst recreate the run from the model version, inputs, parameters, code and random seed where relevant?
- Perturb: What happens when plausible assumptions, parameter values or structural choices change?
- Compare: How do outputs perform against observations not used merely to tune the model?
If a conclusion survives only one hidden parameter setting, one selected run or one unchallenged model structure, confidence should fall.
15. How to read any simulation
- What real system is being represented?
- What question is the simulation supposed to answer?
- What model sits underneath it?
- Which scenario and starting conditions were supplied?
- Which mechanisms and constraints are represented?
- Where does randomness enter?
- How many runs were performed, and why is that enough?
- How was the implementation verified?
- Which independent observations support validation?
- What uncertainty and sensitivity analyses were performed?
- Where is the simulation known to fail?
- What real-world observation will update it next?
16. Where Simulation fits in the wider How Things Work map
Simulation connects Models to Observation, Comparison, Forecasting, Risk, Optimisation and Decision-Making.
The next question is often counterfactual: if one simulated or observed path occurred, what evidence would justify saying that a different intervention, choice or condition caused the difference?
17. What this article does not claim
- A simulation is not an independent observation of the real world.
- A realistic animation is not evidence of model validity.
- Repeated runs do not repair a structurally wrong model.
- A scenario is not automatically a forecast.
- Verification is not the same as validation.
- A successful simulation does not by itself authorise a medical, legal, safety, financial or policy intervention.
- Simulation evidence must remain within the validated operating envelope for the intended use.
18. Observable mastery test
You understand simulation when you can take an unfamiliar simulation and identify its real-world target, model, scenario, initial state, rules, randomness, outputs, verification evidence, validation evidence, uncertainty, sensitivity, operating range and world-return test—and explain why running a model is not the same thing as observing reality.
Authoritative source corridor
- NISTIR 8298: Verification, Validation and Uncertainty Quantification — verification and validation as complementary accuracy procedures, plus uncertainty quantification.
- NISTIR 7655: Best Practices for Modeling, Simulation and Analysis — modelling practice, reliability, V&V, standards and interoperability.
- NIST: Best Practices for Quantification of Uncertainty and Sampling Quality in Molecular Simulations.
- NIST AI 200-2 initial public draft: TEVV-Athlon Framework — announced August 7, 2026; a current example of structured test, evaluation, verification and validation for AI systems.
Governing idea: Simulate boldly inside the model; believe cautiously until the world answers back.