How information models really describe collection, processing, storage and transmission — and which widely repeated claims about them do not survive a second look.
| Kind of model | What people assume it does | What it actually does |
|---|---|---|
| Flow diagram (boxes and arrows) | Shows the whole system, so it counts as the model | Shows the order of steps only. It carries no rules about what the data is, how long it lasts, or what happens when a step fails |
| Data model (entities, fields, relationships) | Describes how the system behaves | Describes what is recorded and how records relate. It says nothing about timing, volume or who reads the output |
| Process model (inputs, transformations, outputs) | Is a technical document only specialists can read | States what goes in, what comes out and what changes in between. A library loan or a GP referral can be written this way in plain English |
| Simulation or statistical model | Predicts what will happen | Estimates what may happen under stated assumptions. Change an assumption and the output changes with it — that is a property of the method, not a fault |
| Written procedure or policy | Is separate from modelling altogether | Is an informal model: it fixes inputs, sequence and responsibility in prose rather than notation, and inherits the same blind spots |
| Spreadsheet | Is just a record of numbers | Encodes relationships in its formulas. The assumptions live in cells nobody reads, which is why spreadsheet errors are so persistent |
Ask someone to model an information process and they usually reach for a pen: boxes for the stages, arrows for the flow, a printout for the wall. The drawing is useful, but it is notation rather than the model itself. What makes something a model is a set of claims: what enters the process, what leaves it, what is held on to, what depends on what, and the conditions under which the description stops being true. A flowchart of booking a GP appointment can be perfectly tidy and still say nothing about whether a cancelled slot becomes visible to the next caller, or how long an unanswered request waits before it is dropped. Two teams can draw the identical diagram and still be working from two different models, which is how disagreements survive undetected until something is tested.
The practical test is whether the thing can be asked a question. Add an online booking route alongside the phone line: which inputs change, which records now exist in two places, and which step becomes the bottleneck? A diagram is redrawn to match the answer. A model produces the answer. That test also explains why models need not be pictures at all. A numbered list of rules, a table of fields with their units and permitted values, or a short paragraph describing who may write to a record and when — each counts as a model if it lets you reason about behaviour you have not yet observed. Notation is a convenience for talking to other people; the reasoning is the substance, and it is the part usually left implicit.
Collection, processing, storage and transmission are the four things an information process does, and they are easiest to see in something ordinary. Tapping a contactless card at a ticket barrier collects a small set of values: a card identifier, a gate, a time. Those values are transmitted from the reader onward. Somewhere they are processed against fare rules and daily caps. Journey history and balances are stored. A further transmission reaches the card provider, perhaps hours later. Each verb is separable, and each fails in its own way: the barrier can read the card while the network is down, the network can behave perfectly while the fare rule is wrong, and the record can be correct but retrievable only by someone who knows where to look.
The common picture is a relay — collect, then process, then store, then transmit, once, in order. Real processes loop. Information is stored halfway through processing because a queue has to hold it. It is transmitted before anything has been calculated. A later output triggers a fresh round of collection, as when a mismatch prompts a letter asking the same question again. Modelling honestly means allowing the same item to be transmitted three times and stored in two different forms. Naming the verbs matters because each invites a different question: timeliness and accuracy for collection, reproducibility for processing, retention and retrieval for storage, delay and integrity for transmission. Asking the storage question about a transmission problem is one of the most reliable ways to waste a fortnight.
Inputs feel like facts that arrived from outside, but every one of them is the residue of a decision someone made earlier. A form field was designed with a length limit. A sensor was set to take a reading every fifteen minutes rather than every second. A caller was asked one question and not another. Councils recording household collections may log a date or only a week; a service holding a postcode but not a full address has decided that a household is close enough to a person. None of those choices is wrong in itself. The problem is that a model treating inputs as given inherits them silently, then reports confident results whose precision belongs to the calculation rather than to the world it describes.
Outputs are chosen just as deliberately. An output can be a figure, a decision, a message to someone, or nothing visible at all — a record quietly updated for use much later. Alongside them sits the single most consequential choice in any model: where the process is said to begin and end. A model of an online order that ends at "dispatch confirmed" cannot notice a parcel that never arrives, no matter how accurate everything inside it is. Boundaries are usually set by accident, following whoever owns which system, and then defended as though they described the world. Writing the boundary down, in one sentence, turns an assumption into something a reader can argue with.
A stubborn belief holds that the best model is the one with the fewest assumptions, and that a well-built model is neutral. Neither survives contact with a real description. Every model assumes something: that a name identifies one person, that a timestamp marks the moment an event happened rather than the moment it was entered, that a form was completed by the person it names, that an unread message is as good as a delivered one. Most of these assumptions are reasonable most of the time. The difficulty is that unwritten assumptions cannot be checked, and they fail quietly — the output still looks like a number, still lines up in the column, and gives no sign that the ground beneath it shifted.
Limits work the same way. Every model leaves things out, and leaving things out is precisely what makes it usable; a description complete to the last detail would simply be the process itself, no easier to reason about than the original. So the honest question is never "is this model complete?" but "what did it omit, and does that omission matter for the decision in front of me?" A model of library lending can ignore whether a returned book was reshelved correctly and still be perfectly adequate for sending due-date reminders. The same model is useless for explaining why a reserved copy cannot be found. One description, two verdicts, decided entirely by the question being asked of it.
A diagram is not a model, and the difference decides what you can do with it. This area sets out the minimum a description needs before it can predict anything: named inputs, named outputs, stated relationships and a boundary. Worked through with ordinary examples such as booking a repair or issuing a library book.
More rows is not better input. Collection is where the decisions get made: which fields exist, how often a reading is taken, who is asked and who never appears in the data at all. A larger set gathered the same flawed way repeats the flaw at scale rather than cancelling it out.
Processing is often treated as a sealed box only specialists may open. Usually it is a sequence of describable steps: a rule applied, a total calculated, one record matched to another. Where a step genuinely cannot be explained, that is normally a sign nobody wrote it down, not proof that it is unknowable.
Saved is not the same as safe, and full is rarely about physical space. Storage models deal in copies, retention periods, formats that outlive the software able to read them, and the gap between holding something and being able to retrieve it on the day it is actually needed.
Information moving between a person, a form and a system is neither instant nor lossless. Meaning changes at the handover: a field renamed, a unit dropped, a message that arrived but was never read. Useful transmission models describe delay, confirmation, and what is supposed to happen on the second attempt.
Every model rests on assumptions — that a name identifies one person, that a timestamp marks when an event happened — and every model leaves things out. Neither is a defect. The questions worth asking are which assumptions were never written down, and whether what was omitted matters for the decision in hand.
This is an illustration only. It multiplies your figure by 365 and by a fixed 2 KB per record. Real systems compress, deduplicate and discard.
A flowchart can be part of one, but on its own it shows sequence and nothing else. A model also states what enters and leaves, what each step changes, which assumptions must hold, and where its own boundary sits. That is why two teams can share an identical diagram and still disagree about what the process does: the diagram was never carrying the disputed information.
Not by itself. Extra records can repeat an existing bias more times, add fields nobody defined, or widen the gap between what was collected and what the question needs. Volume and quality are separate properties. A small, well-defined set with known collection conditions is often easier to reason about than a very large set assembled from mixed sources over several years.
Usually more than people expect. The steps may be inconvenient to inspect, but they are not mystical: inputs, transformations and outputs can be described, tested with known cases and compared against expectations. The black box feeling often comes from missing documentation rather than genuine impossibility. Where a step truly cannot be examined, that itself belongs in the model as a stated limitation.
The bits may be stable while their meaning drifts. Field definitions change, reference lists are updated, codes are reused, and the people who knew the conventions move on. Storage models therefore have to cover meaning and context as well as media and capacity. Permanence is a property of arrangements and upkeep, not something a storage device supplies on its own.
Every model embeds choices: which inputs counted, how categories were drawn, what rounding was acceptable, what got left outside the boundary. None of that makes a model dishonest. It makes it a product of decisions that can be written down, questioned and revised. The risk lies not in having assumptions but in presenting a model as though it had none.
It would be the thing itself, at which point it stops being useful. A tube map that restored true distances and street layouts would no longer help anyone change at Bank. Models earn their value by leaving things out. The honest version tells you what was omitted and under which conditions the omission stops being safe.
Yes, and the everyday cases are often clearer. A GP surgery's appointment system, a school register, a stocktake in a corner shop and a household energy meter all collect, process, store and pass on information. Each has inputs, assumptions and limits. Working through a paper example first tends to make the same structure easier to spot in software later.
Every topic here takes one widely held belief about information processes and sets it beside what models actually do. Read in any order, disagree in writing, and tell us where our explanations fall short.
