1.1.3: When do we use models?#
Models are not only for research. They are used wherever a system is too complex, too costly, too dangerous, or too slow to study directly. This section looks at where modelling has become routine practice, and at the conditions that decide whether building a model is worth the effort.
1.1.3.1: Where models are used#
Modelling is not a niche academic exercise; in several fields it has become part of the everyday toolkit for understanding a system and deciding what to do about it. Seeing where it is already routine makes the case concrete, because each field turned to modelling for the same underlying reason: the behaviour that matters comes from many parts interacting, and that behaviour is hard to see, and risky to test, in the real world. The three fields below, traffic, epidemics, and economics, are among the clearest examples. Pick one to see how modelling is used there, what kinds of question it answers, and what it reveals that direct observation alone would miss.
Sources: phantom jams and driver-level traffic flow [1]; epidemic models during COVID-19 [2]; the limits of aggregate economic models [3].
Different as these fields are, they reach for modelling for one shared reason: the important behaviour lives in the interactions between many parts, where intuition is weak and real experiments are impractical. That common thread is what the rest of this section makes precise.
1.1.3.2: Why some decisions need models#
Beyond particular fields, some kinds of decision benefit from modelling whatever the subject. What they share is that experimenting on the real system is impossible, unethical, or impractical, while the cost of getting the decision wrong is high [4]. Before cataloguing those kinds, it helps to see why a model earns its place in even a single risky decision.
A decision under uncertainty is one where you must commit to a choice now, before you can know how things will turn out. A model helps not by making the future certain, which nothing can do, but by giving you a good estimate of what is likely, so that your choice is wrong by less and costs you less. In the short activity below you run a bike-share station and decide each morning how many bikes to place before the day’s demand is known, first on instinct alone and then with a simple forecast to guide you, so you can feel what the forecast is worth.
1.1.3.3: The recurring decision contexts#
The bike-share game showed the value of a forecast in one decision; that same logic recurs across whole families of decisions. Four such contexts come up again and again: policy design, disaster response, resource management, and technology development. Consider each in turn using the tabs below.
Policies act on complex systems, and their knock-on effects are hard to foresee by intuition. A model makes the assumptions behind a policy explicit, so that different groups can question them and weigh the trade-offs on a shared basis [4].
Examples: cost–benefit analysis of large infrastructure, environmental assessment of land-use or energy plans, and comparison of health technologies.
Emergency planning involves fast, high-stakes decisions with incomplete information, and experimenting on real populations is not an option. A model provides a safe setting in which to test and refine response plans in advance, so that the options have already been explored when a crisis arrives [5].
Examples: simulating a building evacuation to check where exits should go, and stress-testing pandemic preparedness plans.
Managing a renewable resource means balancing its natural dynamics against economic and regulatory pressures over the long term. A model brings these together and makes the long-run consequences of short-run choices visible [6].
Examples: setting sustainable catch limits for a fishery, and comparing harvesting regimes for a forest.
A model can show not just whether a design works but why it succeeds or fails, and it can do so far more cheaply than building and testing physical prototypes [4].
Examples: computational fluid dynamics for aerodynamic shapes, finite-element analysis for structural strength, and circuit simulation for electronics.
These four contexts look very different on the surface, yet recognising their shared shape matters more than memorising the four labels, because it lets you spot the pattern in a problem you have never seen before. In the activity below, match each real task to the decision context it belongs to, and as you do, notice the shared feature running through all of them.
Across every context the same signature appears: the real experiment is out of reach and the wrong choice is costly. Once you can recognise that signature, you can judge for yourself whether a new problem is one a model should be built for.
1.1.3.4: When a model is worth building#
Across these examples, a model is most worth building when one or more of the following holds [4]:
the system is too complex to understand reliably by intuition alone;
direct experimentation is impossible, too expensive, too slow, or unethical;
several groups need a shared, transparent basis for comparing trade-offs;
many scenarios must be checked before a costly, hard-to-reverse decision;
understanding the mechanism matters, not just predicting a single number.
A model adds little, and can mislead, when the question could be settled by direct observation, when there is too little data to support the model’s parameters, or when the assumptions it needs are so strong that the results cannot be trusted [4].
1.1.3.5: Knowing when not to model#
The harder judgement is not whether a model is possible, but whether it is worth building. A model can be constructed for almost any question, and that is exactly the danger: applied to the wrong question it does not just waste effort, it can dress up a guess in false confidence and mislead the people who rely on it. Knowing when to decline to model is therefore as much a part of good practice as knowing how to build one. In the activity below, judge each case for yourself, weighing each one carefully rather than guessing.
The goal is not to model whenever you can, but to model when it adds real value and to hold back when it would only add complexity or false confidence. That restraint is itself a mark of a careful modeller.
Reflection questions
For each of the four contexts above (policy design, disaster response, resource management, technology development), name one situation where a model would be essential and one where direct observation or expert judgement would be enough.
What distinguishes a situation where a model adds real value from one where it only adds complexity?
Give an example of a question where building a model would mislead more than it helps, and explain why.
Suggested answers
There is no single right answer. Policy design, essential: evaluating a proposed carbon tax, where economy-wide effects cannot be judged by intuition; enough: deciding to repaint a public building. Disaster response, essential: planning evacuation routes for a new multi-storey venue before it opens; enough: deciding where to put a fire extinguisher in a small office. Resource management, essential: setting annual catch limits for a slow-reproducing fish species; enough: deciding how often to water a small garden. Technology development, essential: testing a new aircraft wing at many speeds before it is built; enough: choosing between two off-the-shelf parts with well-documented performance [4].
A model adds real value when the system involves interactions, feedbacks, or scale beyond what unaided judgement can handle, and when the cost of a wrong decision justifies the effort of building and checking the model. It only adds complexity when the question can be answered by simpler means, by observation, calculation, or expert knowledge, and when the model would need assumptions so strong that its output is less reliable than the judgement it is meant to replace [4].
A model misleads when it gives false confidence to an answer the data and assumptions cannot support. Predicting the exact level of a stock market a year from now, or the precise population of a city in fifty years, asks a model to be accurate about a system that is highly sensitive to events no one can foresee. A model can make such a guess look more reliable than it is; honest judgement that admits the uncertainty may serve better [4].
Having settled when a model is worth building, we can turn to how one is built: the next section, 1.2: The modelling cycle, lays out the modelling cycle that carries a question from a first sketch through to a working, tested model.
Key takeaways#
Key takeaways
Modelling is standard practice in fields such as traffic, epidemics, and economics, where the system is hard or impossible to experiment on directly.
Certain decisions, in policy, disaster response, resource management, and technology, benefit from modelling because real-world experimentation is impractical and the stakes are high.
A model is worth building when complexity, ethics, cost, or shared decision-making rule out simpler methods, and adds little when direct observation would do.