Assumptions Hidden in Every Model
A look at the false belief that models are neutral, and a practical guide to finding the assumptions quietly built into their design.
Myth: a model just reflects reality as it is
A model is often described as a mirror held up to a process, simply showing what the process does. This framing is comforting because it makes the model feel objective, as if no one made choices along the way. But every model is built by someone who decided what counts as an input, what counts as noise, and what does not need representing at all.
Those decisions are assumptions, and they happen before a single diagram is drawn. Choosing to model 'customer requests' as a single uniform category, for example, assumes that the differences between requests do not matter for the purpose at hand. That might be true for one use and false for another, but the model itself will not tell you which.
Fact: every model encodes a point of view
A model is a simplification made for a purpose, and the purpose shapes what gets included. A model built to explain processing speed will treat storage as a black box. A model built to explain storage will do the reverse. Neither is wrong, but neither is complete, and neither is neutral about what matters.
The point of view is often invisible because it is baked into the vocabulary of the model itself. Calling something an 'error' rather than a 'variant', or a 'user' rather than an 'account', already implies a judgment about what is normal and what is not. Reading a model well means noticing these word choices as design decisions, not as facts about the world.
Where assumptions typically hide
Assumptions cluster in a few predictable places. Boundaries are one: a model has to decide where a process starts and ends, and anything outside that boundary is assumed constant or irrelevant. Categories are another: grouping things together assumes the grouping does not obscure a difference that matters later.
Defaults are a third hiding place. When a field is left blank or a case is unspecified, the model quietly falls back on some default behavior, and that default is a choice someone made, often without documenting it. Scale is a fourth: a model tested on a small, tidy dataset carries an unstated assumption that the real system will behave the same way at a much larger, messier scale.
What people get wrong about model neutrality
A common mistake is treating a model's output as evidence that the model's assumptions were correct. If a model predicts smoothly and the prediction looks reasonable, people tend to stop questioning the inputs. But a model can produce a plausible-looking answer while still resting on an assumption that quietly excludes the exact case a reader cares about.
Another common error is assuming that adding more detail automatically removes assumptions. It does not. A more detailed model simply moves the assumptions to a finer grain, deciding what counts as detail worth including and what still gets folded into a category. Detail changes the resolution of the simplification; it does not remove the simplification.
How to read a model for its hidden assumptions
Start by asking what the model leaves out rather than what it includes. Every diagram, dataset, or process description had to draw a line somewhere, and the line itself is informative. Ask who decided where that line went and what they were trying to accomplish when they drew it.
Then look at the categories and defaults directly. Ask what happens to a case that does not fit any listed category, and ask what the model does when a value is missing. The answers to those two questions usually reveal more about the model's real assumptions than its stated purpose does.
Two ways to treat model assumptions
| Approach | What it assumes about neutrality | Practical trade-off |
|---|---|---|
| Treat the model as an objective description | Assumes the builder's choices are invisible or unimportant | Faster to use, but errors surface late and are harder to trace back to a cause |
| Document assumptions alongside the model | Assumes neutrality is not achievable, only manageable | Slower to build, but limitations are visible before the model is relied on |
| Test the model against edge cases outside its intended scope | Assumes the model's boundaries were drawn imperfectly | Reveals hidden defaults and categories, at the cost of extra review time |
| Accept vendor or textbook models without inspection | Assumes someone else already checked for bias in scope | Convenient short term, risky wherever the original purpose differs from the new use |
Common questions about model assumptions
Can a model ever be fully neutral?
No. Every model requires choices about scope, categories, and what to leave out, and those choices reflect a purpose. Neutrality in the sense of having no point of view is not achievable; the realistic goal is making the point of view visible.
Does more data make a model more neutral?
Not by itself. More data can reduce certain kinds of error, but it does not remove the assumptions about what was collected, how it was categorized, or what was excluded from collection in the first place. Those choices happen before the data arrives.
Why do two models of the same process disagree?
They usually differ in where they drew boundaries or what they treated as a default. Disagreement is often not a sign that one model is broken, but that the two were built for different purposes and are carrying different unstated assumptions.
How can a reader spot an assumption that was never stated?
Look for what the model does with a case that does not fit its categories, and look for anything treated as constant. Unstated assumptions usually show up as gaps rather than statements, so the absence of detail is itself a clue.
Is it fair to say assumptions are a flaw in a model?
Not exactly. Assumptions are what make a model usable at all, since no model can represent every detail of a real process. The issue is not that assumptions exist, but that they are often left undocumented and later mistaken for facts.
Do simple models have fewer hidden assumptions than complex ones?
Not necessarily. Simple models tend to make their assumptions more visible because there is less machinery to hide behind. Complex models can bury the same number of assumptions, or more, inside layers that are harder to inspect.