The Assumptions Hiding Inside Ordinary Models
Every model of collecting, storing, or moving information leans on assumptions nobody states out loud. This page walks through the common ones, case by case, and what happens when reality disagrees.
Why models need assumptions at all
A model is a simplification, and simplification only works if some things are held fixed. When someone models a form that collects a customer's address, they assume the postal system exists, that addresses have a roughly stable format, and that the person filling it in is who they claim to be. None of that is drawn on the diagram, but all of it is doing work behind the scenes.
This is not a flaw specific to bad models. It is what makes any model usable at all. A model that tried to represent every possible complication would be as complicated as the situation itself, and therefore useless as a simplification. The skill is not in avoiding assumptions but in knowing which ones you are making.
The case of the stable format
Consider a spreadsheet used to log daily deliveries. The model assumes each row will have a date, a quantity, and a destination, in that order, entered the same way each time. This works for months. Then someone starts entering two deliveries on one row because a driver made two stops, and the model that assumed one row per event quietly starts producing wrong totals.
The assumption was never written down because it seemed too obvious to state: one event, one entry. Formats drift as the people and situations behind them change, and a model that does not revisit its format assumption periodically will keep producing confident, wrong answers long after the drift began.
The case of the honest input
Many models of data collection assume the person or sensor supplying information is reporting accurately and is not being deceived or gamed. A model of a customer feedback form assumes ratings reflect genuine experience. A model of a thermostat assumes the sensor reads the actual room temperature.
Both assumptions can fail in ordinary ways that have nothing to do with malice. A feedback form gets rushed answers from people who just want to finish it. A sensor drifts out of calibration or sits near a draft. The model itself cannot tell the difference between an honest reading and a distorted one; it only knows how to process whatever arrives as if it were trustworthy.
The case of available capacity
Storage and transmission models often assume there will be enough room and enough bandwidth to move ahead as planned. A backup schedule assumes the drive has space; a video call assumes the network can carry the load. These assumptions hold until a busy day, a full disk, or a shared connection changes the picture.
When capacity assumptions fail, the visible symptom is rarely labeled as a capacity problem. It shows up as a dropped call, a failed save, or a silently truncated file, and the person affected often blames the wrong part of the process because the actual constraint was invisible in the model they were shown.
What people get wrong about assumptions
The most common mistake is treating an assumption as a fact once it has gone unchallenged for a while. A model built five years ago assumed a particular volume of activity, a particular set of formats, a particular kind of user. If nobody revisits it, the model keeps running on those original terms even as the situation around it has moved on.
The second common mistake is assuming that naming an assumption fixes it. Writing 'assumes stable network conditions' in a document does not make the network stable; it only means someone, somewhere, now knows where to look when things go wrong. Recognition is a starting point, not a solution.
How Different Kinds of Assumptions Behave When They Break
| Assumption type | How it usually breaks | What the model shows instead |
|---|---|---|
| Stable format | New field, merged rows, or a changed unit slips in unnoticed | Numbers that look plausible but no longer mean what they used to |
| Honest input | Rushed answers, miscalibrated sensors, or gamed metrics | Confident output built from data nobody actually verified |
| Available capacity | Storage fills up or bandwidth is shared unexpectedly | Silent truncation, dropped packets, or a failed save with no clear cause |
| Consistent timing | Delays, retries, or clock differences between systems | Events appear out of order or seem to happen twice |
| Single authoritative source | Two systems disagree about the same fact | Conflicting records with no built-in way to say which is right |
What People Ask About Hidden Assumptions
How can I find the assumptions in a model I did not build?
Look at what the model does not check. If it never verifies where a number came from, it assumes the source is honest. If it never checks available space, it assumes capacity. Assumptions tend to live in the steps a model skips, not the ones it performs.
Do all models eventually break their assumptions?
Most do, simply because the situation they describe keeps changing while the model stays fixed unless someone updates it. This is not a sign of a poorly built model; it is a normal consequence of using a fixed simplification for a moving target.
Is it possible to build a model with no assumptions?
No. A model without assumptions would have to represent every possible variation of the situation, at which point it stops being a simplification and becomes the situation itself, which defeats the purpose of modeling in the first place.
Why do assumptions matter more in some situations than others?
They matter most where the cost of being wrong is high or where the situation changes quickly. A model of a stable, slow-moving process can tolerate stale assumptions for years; a model of a fast-changing one needs its assumptions checked far more often.
How do people usually notice an assumption has broken?
Usually through a symptom rather than the assumption itself: numbers stop reconciling, a process fails intermittently, or two records disagree. Tracing the symptom back to the assumption that no longer holds is often the harder part.
Should every assumption be written down?
Writing them down helps, but only if someone actually revisits the list. An assumption documented once and never reviewed provides little more protection than one left unspoken, since both can quietly stop being true without anyone noticing.