The situations behind every model

Why situations, not definitions

Most explanations of information processes start with a diagram and a set of arrows labelled input, process, output. That is accurate but hard to hold onto. We start instead from a case a reader has actually lived through — waiting for a train departures board to update, or watching a supermarket till total change as a barcode is scanned — and build the vocabulary outward from there.

Each case exposes a different part of the picture. A GP surgery booking system shows storage and retrieval under contention. A weather forecast shows how uncertain inputs still produce a usable output. By the time a reader has been through several cases, the general vocabulary — input, transformation, feedback, latency, error — has attached itself to something concrete rather than floating free.

How the topic pages are organised

Each page opens with the situation itself, described plainly enough that no prior knowledge is assumed. It then names the model that fits — sometimes a simple pipeline, sometimes a loop with feedback, sometimes a store with rules about who may read or write to it.

From there the page sets out what counts as input and output in that case, what assumptions the model quietly makes, and what happens when those assumptions do not hold. A working till assumes the barcode scans correctly the first time; the page on retail systems spends real space on what happens when it does not.

Collection and input

Several pages deal with how raw information enters a process in the first place: a sensor reading a temperature, a form being filled at a counter, a card being tapped at a barrier. The common thread is that collection is never neutral — the method used to gather information shapes what can later be done with it.

These pages look at typical collection situations and the trade-offs each one carries, such as speed against accuracy, or convenience against completeness, using examples familiar from everyday errands rather than specialist settings.

Processing and transformation

Other pages follow information through the stage where it is combined, checked, or converted into something new — a set of exam scores turned into a grade, a set of readings turned into a forecast, a set of transactions turned into a monthly statement.

The focus stays on what rules the transformation applies, what it discards along the way, and how a reader can tell a sound transformation from one that has quietly lost something important.

Storage and retrieval

A further group of pages looks at what happens once information is kept somewhere — a filing cabinet, a library catalogue, a shared spreadsheet — and needs to be found again later. These situations raise questions of who can access what, how errors creep in over time, and what it costs to keep something up to date.

The examples here are drawn from ordinary institutions: a library, a doctor's surgery, a council tax office, so the underlying pattern is easy to recognise even without technical background.

Transmission and communication

A last set of pages follows information as it moves from one place, person, or system to another — a letter posted, a phone call made, a message sent across a shared network. These cases bring in delay, loss, and the question of whether a message arrived as it was sent.

Rather than focusing on any particular technology, the pages describe the situation in general terms so the underlying pattern applies whether the channel is a postal service, a phone line, or a data connection.

Limitations, on every page

No topic page ends on a tidy note. Every model simplifies, and every page closes by naming what its model leaves out — the fraud a checkout system does not catch, the rare failure a scheduling model does not anticipate, the assumption that breaks down once volume grows large enough.

This is a deliberate habit rather than a caveat added at the end. A model is only useful once its edges are known, and the edges are usually more instructive than the middle.