A model is a deliberate reduction of reality. It keeps some things, leaves others out, and creates a structure that can be inspected, calculated, tested or used to ask “what if?”. A weather model does not contain the atmosphere. A financial model does not contain an economy. A traffic simulation does not contain a city. A classroom model does not contain a child. Each keeps selected relationships because those relationships are useful for a particular question.

This is why models are powerful and dangerous at the same time. Their strength comes from simplification. Their weakness also comes from simplification. A model can make a difficult system intelligible, but it can also create confidence in a structure whose assumptions have quietly stopped matching the world.

Simulation adds time, interaction or repeated computation to a model. The model defines how a system is represented. The simulation explores what that representation does under specified conditions. Together they form one of civilisation’s most important reasoning machines: represent → compute → compare → challenge → revise.

The model-to-world loop

QUESTION
→ DEFINE THE DECISION JOB
→ CHOOSE SYSTEM BOUNDARY
→ ABSTRACT
→ DECLARE ASSUMPTIONS
→ DEFINE STATE + PARAMETERS + RULES
→ IMPLEMENT
→ VERIFY
→ CALIBRATE WHERE APPROPRIATE
→ VALIDATE AGAINST EVIDENCE
→ QUANTIFY UNCERTAINTY
→ TEST SENSITIVITY
→ RUN SCENARIOS
→ INTERPRET WITHIN DOMAIN OF VALIDITY
→ DECIDE
→ OBSERVE WORLD RETURN
→ REVISE MODEL

The important point is that the loop returns to the world. A simulation is not trusted because it runs. It is trusted only to the degree that its structure, implementation and evidence justify the particular use being made of it.

1. Start with the question, not the software

The same real system can support many models because different questions require different representations. A city model for emergency evacuation needs road capacity, movement, bottlenecks and time. A city model for heat exposure needs land cover, buildings, shade, weather and human vulnerability. A city model for property taxation needs parcels, ownership, valuation and legal boundaries.

A common failure is to begin with a favourite tool and ask what can be modelled inside it. Strong modelling begins with the decision or research question and asks what minimum representation is sufficient to answer it responsibly.

2. Abstraction is controlled omission

No useful model can include every detail of reality. Abstraction removes details judged irrelevant to the purpose. The discipline lies in deciding which details are safe to omit.

• Structural abstraction simplifies components and relationships.
• Spatial abstraction represents geography at a chosen resolution.
• Temporal abstraction groups continuous activity into time steps or events.
• Behavioural abstraction represents human or organisational decisions through rules.
• Statistical abstraction replaces individual variation with distributions or averages.
• Physical abstraction ignores effects too small to matter at the intended scale.

A good abstraction leaves out detail without removing the mechanism needed for the answer.

3. Every model has a boundary

A model boundary defines what is represented explicitly and what is treated as external. In an energy-system model, fuel prices might be an input. In a global economic model, those same prices might be produced endogenously by supply and demand. Neither is automatically correct. The boundary should match the question.

Boundary mistakes are especially serious in complex systems because important feedback can sit just outside the model. A policy model that represents only intended responses may miss behavioural adaptation. A transport model that ignores land-use change may predict immediate traffic effects while missing longer-term relocation and development.

4. State describes what the model currently knows

Many simulations evolve through state. State variables capture the information needed to determine what happens next: vehicle position and speed, reservoir volume, patient condition, inventory level, machine status or population composition.

The choice of state is consequential. If a simulation omits a variable that carries memory, it may be unable to reproduce path dependence. If it records unnecessary detail, the model may become computationally expensive without becoming more useful.

5. Parameters encode assumptions about behaviour

Parameters define quantities that control the model: reaction rates, demand elasticity, failure probability, walking speed, infection transmissibility, learning rate, friction coefficient or queue-service time. Some are directly measured. Others are estimated. Some are chosen because evidence is weak.

The model should distinguish these origins. A measured parameter with uncertainty is not epistemically equivalent to a convenient default chosen because the modeller lacked data.

6. Initial conditions matter

A dynamic simulation needs a starting state. In nonlinear systems, small differences in initial conditions can produce large differences later. Even when the system is not chaotic, initial inventory, population distribution, moisture, temperature or network congestion can materially change outcomes.

Initial conditions should therefore be sourced, time-stamped and tested rather than treated as invisible setup.

7. Rules create transitions

A model contains rules describing how state changes. These may be physical equations, statistical relationships, logical rules, learned functions or behavioural heuristics. The rule system is the model’s causal grammar.

When a model predicts, the prediction is not generated from “data” alone. It emerges from data processed through this grammar. Readers therefore need access to the structural assumptions, not merely the final output.

8. Deterministic and stochastic models answer different questions

A deterministic model returns the same output from the same inputs. A stochastic model includes randomness or probabilistic events, so repeated runs can produce a distribution of outcomes.

Stochasticity can represent real variability, incomplete knowledge or both. The source should be explicit. Randomness added merely because a system “feels uncertain” does not create meaningful uncertainty analysis.

9. Continuous, discrete and agent-based simulations

Form	What changes	Typical use
Continuous	State changes continuously through equations	Physical systems, flows, dynamics
Discrete-event	State changes at events	Queues, factories, hospitals, logistics
Agent-based	Individual agents follow rules and interact	Markets, crowds, ecosystems, social systems
System dynamics	Stocks, flows and feedback loops evolve	Policy, resource systems, strategic dynamics
Monte Carlo	Repeated sampling propagates uncertainty	Risk, finance, reliability, estimation

These are not rival philosophies. A complex programme may combine several forms. The method should follow the mechanism and decision job.

10. Verification asks whether we built the model right

Verification checks whether the implemented model correctly represents the intended mathematical, logical or computational specification. It asks whether equations were coded properly, units are consistent, events fire correctly, algorithms converge and software behaves as designed.

NASA’s public Models and Simulations Standard and associated handbook formalise credibility practices for modelling and simulation. The underlying lesson is broadly useful: model acceptance requires evidence about construction and use, not merely plausible-looking output.

11. Validation asks whether the model is adequate for the real-world use

Validation compares model behaviour with relevant observations, experiments, historical cases or accepted knowledge. It asks whether the model reproduces the important features of reality closely enough for the stated purpose.

Validation is never absolute. A model validated for one regime may fail outside it. A fire model validated for particular geometries, fuels and ventilation conditions should not automatically be trusted for every possible fire. NIST’s Fire Dynamics Simulator Technical Reference Guide separates theoretical basis, verification, experimental validation and configuration management—a useful example of disciplined model credibility.

12. Verification is not validation

A perfectly coded wrong model is verified but invalid for the world. A conceptually useful model implemented with a coding error may be valid in intent but unusable in execution. Credibility requires both questions.

VERIFICATION: DID WE IMPLEMENT THE INTENDED MODEL CORRECTLY?
VALIDATION: IS THAT MODEL ADEQUATE FOR THIS REAL-WORLD PURPOSE?

13. Calibration estimates uncertain parameters

Calibration tunes parameters using observed data. It can improve fit, but it can also hide structural weakness. A model with the wrong mechanism may still match historical observations after enough parameters are adjusted.

Strong practice separates calibration data from validation evidence where feasible and records which parameters were estimated, which remained fixed and how parameter uncertainty was handled.

14. Overfitting exists in simulation too

A model can be tuned so tightly to known cases that it loses predictive or explanatory value elsewhere. This is not limited to machine learning. Complex mechanistic models with many adjustable parameters can also fit history without capturing transferable structure.

Out-of-sample tests, new regimes, alternate datasets and withheld validation cases help reveal whether apparent accuracy is genuine or merely retrospective fitting.

15. Uncertainty has several sources

• Parameter uncertainty — values are not known exactly.
• Input uncertainty — future demand, weather or operating conditions vary.
• Measurement uncertainty — observations used for calibration and validation are imperfect.
• Structural uncertainty — the model may omit or misrepresent mechanisms.
• Numerical uncertainty — discretisation and computation introduce approximation.
• Scenario uncertainty — the future operating environment cannot be assigned one known path.

These should not be collapsed into one generic confidence number. Different uncertainties call for different tests and decisions.

16. Sensitivity analysis asks what drives the result

Sensitivity analysis changes inputs, parameters or assumptions and observes how output responds. It reveals which parts of the model matter most and which conclusions are fragile.

A result that changes dramatically when a poorly known parameter moves slightly should be treated differently from a result that remains stable across a broad plausible range.

17. Local and global sensitivity answer different questions

Local sensitivity examines small changes around a selected point. Global sensitivity explores wider parameter ranges and interactions. Local analysis can be useful for smooth systems near a known operating state. Global analysis is often more informative when uncertainty is large or relationships are nonlinear.

18. Scenario analysis is not probability unless probabilities are justified

A scenario is a coherent set of assumptions. It may be plausible without having a defensible probability. Confusing scenarios with forecasts can make decision-makers treat imaginative boundary tests as quantified expectations.

Models should therefore label scenario purpose: baseline, stress case, exploratory future, policy alternative or probabilistic draw.

19. Model ensembles can reveal structural disagreement

When several credible models represent a phenomenon differently, an ensemble can show whether conclusions depend on one model structure. Agreement across different models can strengthen confidence; disagreement can reveal unresolved mechanisms.

An ensemble does not automatically solve uncertainty. If all models share the same omitted mechanism or common data bias, apparent consensus can still be wrong.

20. Benchmarking needs reference cases

Reference cases allow modellers to test whether outputs match known analytical solutions, experiments, historical observations or other trusted standards. Benchmarks are especially useful after software changes because they can reveal unintended behavioural drift.

21. Configuration management preserves the model edition

Model results depend on code version, configuration, parameter files, input data, compiler or runtime environment and sometimes random seeds. Without configuration management, later users may be unable to reproduce the result even if they possess the source code.

This connects modelling to How Data Management Works and How Citations, References and Scholarly Linking Work: a credible model run should preserve identity and route back to inputs.

22. Reproducibility is a model property and a workflow property

A deterministic model may still be irreproducible if dependencies changed or preprocessing steps were undocumented. A stochastic model can be reproducible in a different sense if seeds, distributions and software states are preserved.

Reproducibility therefore belongs to the complete computational workflow, not only to the mathematical equations.

23. Explainability matters differently for different model classes

A physically based model may offer mechanistic interpretation but still contain uncertain closures and approximations. A statistical model may be transparent in coefficients while failing outside the data-generating regime. A machine-learning model may predict accurately while providing weak causal explanation.

The right question is not “Is the model explainable?” but “What kind of explanation is needed for this decision?”

24. Prediction and explanation are different jobs

A model can predict well without representing the true mechanism, and a mechanistically faithful model can be poor at short-term prediction if inputs are uncertain. Confusing these jobs creates false expectations.

Research should state whether the model is being used to predict, explain, estimate, optimise, stress-test, teach or coordinate. Each purpose has different credibility requirements.

25. Optimisation can exploit model errors

When an optimiser searches aggressively inside a model, it may discover solutions that exploit unrealistic assumptions. A schedule, design or policy can look optimal in the representation while failing in the world.

Strong optimisation therefore includes realism constraints, robustness tests, alternate models and human review of unusual solutions.

26. Digital twins are models coupled to operational data

A digital twin links a model of an asset or system with observations from the real counterpart, often updating state as operations continue. This can support monitoring, diagnosis and prediction.

The label “twin” should not imply perfect equivalence. A twin remains a representation. Sensor coverage, model fidelity, latency and configuration determine what it actually knows.

27. Human behaviour is difficult to model

People react to policies, information, prices, each other and sometimes to the model itself. Rules derived from yesterday’s behaviour may fail after institutions change incentives. Agent-based and behavioural models can explore these effects, but their assumptions need unusually careful testing because human adaptation can be strategic and context-dependent.

28. Model governance becomes essential when consequences rise

High-stakes models need named ownership, independent challenge, documented approval, version control, review triggers and boundaries on acceptable use. Governance should answer:

• Who owns the model?
• Who may change it?
• Who validates it?
• What use is approved?
• What evidence supports that use?
• When must the model be revalidated?
• How are limitations communicated to decision-makers?

29. Models can become performative

When people act on a model, the model can change the system it predicts. Credit models affect lending. traffic apps reroute vehicles. ranking systems change institutional behaviour. forecasts influence investment. The model is no longer only observing the world; it has entered the causal loop.

Validation must therefore continue after deployment because the data-generating system may change in response to use.

30. Failure outside the validation domain is not surprising

Every credible model has a domain of validity: the conditions under which evidence supports its use. Extrapolation beyond that domain should be flagged, not hidden by smooth graphics.

A model tested at ordinary temperatures may fail under extreme heat. A demand model trained in stable conditions may fail during crisis. A biological model developed for one species should not silently migrate to another.

31. A model audit should work backwards from the claim

DECISION CLAIM
→ MODEL OUTPUT
→ RUN CONFIGURATION
→ MODEL VERSION
→ PARAMETERS
→ INPUT DATA
→ ASSUMPTIONS
→ EQUATIONS / RULES
→ VALIDATION EVIDENCE
→ SOURCE OBSERVATIONS
→ WORLD

If that reverse path cannot be reconstructed, the result may be informative but is weak as accountable evidence.

32. A practical credibility checklist

1. State the exact use case.
2. Define the system boundary.
3. List assumptions.
4. Identify state variables and parameters.
5. Document data sources and preprocessing.
6. Verify implementation.
7. Validate against relevant evidence.
8. Separate calibration and evaluation where possible.
9. Quantify parameter and input uncertainty.
10. Test structural sensitivity.
11. Stress the model outside ordinary conditions.
12. Record software and configuration versions.
13. State the domain of validity.
14. Have consequential uses independently challenged.
15. Monitor post-deployment performance and revise when the world changes.

33. The model belongs inside the research graph, not above it

Models can synthesise evidence, but they do not escape evidence. They depend on measurement, data, assumptions, theory and validation. Research Methods and Source Evaluation owns the general discipline. Statistical Inference and Uncertainty owns inferential reasoning. Experimental Design owns controlled empirical testing. This article owns the methodological problem of representing systems and exploring their behaviour computationally.

34. What a learner should remember

Never ask only “What does the model say?” Ask: what is represented, what is omitted, which assumptions drive the result, how was the implementation checked, where was it validated, what uncertainty remains, and does the decision stay inside the model’s supported domain?

A model is useful when its simplification makes reasoning stronger. It becomes dangerous when the simplification disappears from view.

Sources and further reading

• NASA — Models and Simulations Standard
• NASA — Models and Simulations Handbooks
• NASA Handbook for Models and Simulations: Implementation Guide for NASA-STD-7009
• NIST — Fire Dynamics Simulator Technical Reference Guide
• NIST — Verification and Validation of Simulation Models

Continue through eduKate

• How Research Methods and Source Evaluation Work
• How Statistical Inference and Uncertainty Work
• How Experimental Design Works
• Data Quality
• How Standards Work
• How Comparative Systems Research Works

Wintour House return: the model is not the answer. The model is a disciplined instrument for asking the world a structured question. Its value is measured by how visibly it preserves assumptions, evidence, limits and the route back to reality.