Models describe how information is collected, processed, stored and sent. This site explains the moving parts in plain English, then asks the question most guides skip: which choices carry the cost, and who pays it later.
A model of an information process is a simplified description of how something moves: what goes in, what happens to it on the way, where it rests, and what comes out at the far end. A school attendance register is a model. So is the routine a corner shop follows to count stock on a Sunday evening, and so is the form a GP surgery uses to record a new patient. None of them is the real world. Each is a deliberate reduction, kept only as detailed as somebody was willing to maintain week after week. That last clause is where cost enters. A model is not a drawing that sits still; it is a set of promises about work that will keep being done by people or machines, and those promises are paid for in instalments.
Cost, on this site, means more than an invoice. It includes the minutes spent typing a figure twice, the attention spent checking it, the software licence, the electricity, the training of a new colleague who inherits the spreadsheet, and the awkward afternoon when a number turns out to have been wrong since March. Some of these appear in pounds on a statement. Most appear as time, and time is the line item nobody writes down. When we talk about what drives the price of a model, we are asking which design decisions quietly commit somebody to recurring effort. A model that is cheap to draw can be expensive to live with, and the reverse happens just as often.
Information processes are conventionally split into collection, processing, storage and transmission, and it is useful to keep them apart because each one is priced differently. Collection is priced by effort per item and by how fussy you are about accuracy: a tick box costs almost nothing, a measurement that must be verified by a second person costs several times more. Processing is priced by the number and depth of the relationships you insist on encoding — every extra rule, exception and cross-check is code or judgement that must be written once and then understood forever. Storage is priced by volume multiplied by time, and the time part is the half people forget when they decide to keep everything.
Transmission is priced by how fast, how reliable and how well formatted the handover has to be. Sending a monthly summary as a simple file to one colleague is nearly free. Sending the same information continuously, to several parties, in a format each of them can read without asking questions, is a different proposition entirely, and the cost is mostly in the agreement rather than the wires. Reading the four stages separately also shows where savings are real and where they are only moved. Trimming a collection form often pushes work into processing, because somebody must now infer what was not asked. The total is what matters, and the total is rarely visible from inside one stage.
Every model rests on things nobody wrote down: that addresses in the United Kingdom fit a certain shape, that a date is always complete, that the working week has five days, that no customer will ever appear twice under slightly different spellings. These assumptions are what make a model affordable. Without them you would have to describe the entire world, which is the one thing a model exists to avoid. The difficulty is that assumptions are borrowed on interest. They cost nothing on the day they are made and become expensive on the day reality departs from them, usually while somebody is trying to explain a discrepancy to a person who does not care about data structures.
Limitations work the same way. A model that ignores part of its subject is not defective; it is scoped. The honest question is what an error inside that scope would actually cost — a rounding difference in an internal report is not the same as a missed appointment or a mis-addressed delivery. Putting a rough figure against being wrong is uncomfortable, but it is the only way to judge whether more checking is worth buying. Some models deserve heavy verification. Many do not, and spending on them is a habit rather than a decision. Knowing which of the two you are looking at is most of the skill.
A few questions expose most of the cost of a model before anyone builds it. Who supplies each input, how often, and what happens on the week they are unavailable? How many rules does the processing stage need before the output is trusted, and who will still understand them in two years? How long is information kept, and did anyone decide that, or did it simply accumulate? Which handovers cross a boundary between teams or organisations, because those are where formats are argued about and where delays get expensive? And finally: if this model is wrong, who notices, how quickly, and what does the correction involve?
None of these questions requires technical vocabulary, and none of them produces a single number. They produce a shape — a sense of where effort will concentrate and which parts will keep asking for attention. The topic pages on this site take each of those areas in turn, with everyday examples rather than case studies, and no advice about what you should buy. We describe how the costs arise and what tends to move them. Deciding what any of it is worth in your own situation stays with you, because value depends on things only you can see.
Two models of the same process can differ tenfold in effort. The difference is rarely the software. It is the number of inputs you insist on, how often the model must run, how many exceptions it has to handle, and who has to check the output. We separate the structural choices that genuinely add cost from the ones that only look expensive.
Inputs are never free. A reading taken by a sensor, a figure typed into a form and a number asked for over the phone all carry different costs per record, different error rates and different correction work later. We look at how far accuracy requirements push the price of a model's front end, and when a rougher input is honestly good enough.
Every rule and relationship a model encodes has to be built, tested, explained and maintained. Depth is where upkeep expense hides: a model with fifty interacting conditions costs far more to keep truthful than one with five. We explain how processing effort grows, and why the bill often arrives months after the build.
Keeping information costs a little each month and forever. Deleting it costs nothing now and may cost a great deal later, when the question you cannot answer turns out to matter. We set out how retention periods, copies, backups and format decisions trade ongoing expense against the future usefulness of what you held on to.
Moving information between stages or between parties has its own price list: speed, reliability, format conversion and the human time spent reconciling what arrived with what was sent. We cover why a daily file can cost a fraction of a live feed, and when paying for immediacy earns its keep rather than simply feeling modern.
Models are built on things nobody wrote down: that the source keeps reporting, that the categories stay stable, that last year resembles next year. When one of those quietly fails, the cost lands as rework, wrong decisions or lost value. We look at how to find the boundaries of a model before they find you.
Masterofbruck is an independent educational publication about modelling information processes — how collection, processing, storage and transmission are represented, and what each of those representations costs to build and keep. We came to the subject because most explanations stop at the diagram. The boxes and arrows get drawn, everyone nods, and nobody says which arrow will need a person watching it every Tuesday morning. Cost is treated as an afterthought when it is in fact one of the model's properties, as real as its inputs and outputs.
So every article here reads the same way: what is being represented, what it actually takes to represent it, and what drives that figure up or down. We use ordinary examples — a library issuing desk, a council recycling round, a corner shop counting stock — because the structure of an information process is identical whether it handles ten records a day or ten million. Where we mention money we use pounds, and we describe the shape of a cost rather than quoting figures we cannot vouch for.
Nothing on this site is for sale. There is no tool, no service and no recommendation waiting at the end of a page. That is deliberate: advice about cost is worth very little if the person giving it benefits from the answer. We write for students, administrators, analysts and anyone who has been handed a process diagram and asked, reasonably enough, what it will take to make it work.
Commissioning, structure and the cost-and-value angle across every topic page
Decides what each article must answer before a word is written, and sends back anything that describes a process without saying what it costs to run. Keeps the pounds-and-hours framing consistent from page to page.
Model logic, inputs and outputs, processing and storage claims
Checks that each worked example holds together: that stated inputs could produce the stated outputs, that the relationships described are the ones a practitioner would actually encode, and that no limitation is glossed over.
Readability, everyday examples and defined terminology
Rewrites anything that assumes the reader already works in the field. Insists that every technical term appears next to an ordinary example, and that sentences survive being read once at normal speed.
Sources, figures, dates and UK conventions
Verifies every number that appears and removes those that cannot be traced to a public source. Also confirms dates, units and currency follow UK conventions, so nothing reads as borrowed from elsewhere.
Essentially, all models are wrong, but some are useful — which makes the real question how wrong, and at what price.
George Box and Norman Draper, Empirical Model-Building and Response Surfaces (1987), p. 424
Personal data must be adequate, relevant and limited to what is necessary for the purpose it is processed for.
UK GDPR, Article 5(1)(c) — data minimisation
Data quality is not one property but a set of named characteristics, from accuracy and completeness to traceability and recoverability.
ISO/IEC 25012:2008, Data quality model
It is a deliberate simplification of how information moves: what gets collected, what is done to it, where it rests, and who receives it. A model names inputs, outputs, relationships and assumptions, and it leaves things out on purpose. A household budget spreadsheet is one. So is the diagram behind a library's lending records. Every omission is a decision, and most decisions carry a price.
Because a model is always paid for with something, even when no invoice appears. Someone's hours go into gathering inputs, checking them, writing the rules, holding the results and explaining the output. Describing a process without asking what each part demands leaves you with a diagram that looks tidy and behaves expensively. Cost is simply the honest unit for comparing two designs.
Usually the number of relationships, not the number of boxes. Every dependency between fields, stages or parties has to be defined, tested, documented and maintained, and that work grows faster than the diagram suggests. Next comes data quality: the standard you set for accuracy and completeness decides how much checking, correcting and chasing the front end has to do, week after week.
Not always. A thin model can push cost outward onto the people using it — manual checks, side spreadsheets, phone calls to confirm something the process never recorded. That effort is real; it just sits somewhere without a line item. The cheaper model is the one whose total work, including the workarounds it forces, comes out lower.
Retention is a recurring commitment rather than a one-off purchase. Keeping information means paying to hold it, index it, back it up, migrate it when formats age, and answer questions about it later. Keeping less lowers those running costs but narrows what you can answer in future. The storage limitation principle in UK data protection law pushes in the same direction as the budget: choose a period and state why.
The kind created by assumptions nobody wrote down — that addresses stay current, that a file arrives every morning, that one colleague understands the rules. Nothing goes wrong while the assumption holds. When it breaks, the cost surfaces as rework, disputed figures, or a rebuild under time pressure. Writing assumptions beside the diagram is the cheapest insurance a model has.
No. Nothing here is for sale, and we quote no prices, rates or vendor comparisons. Figures for storage, bandwidth and labour move constantly and depend on where you sit and what you already run. What we explain instead is the structure underneath: which choices make a model expensive, which keep it lean, and which costs arrive long after the decision that caused them.
Someone wants a number before anyone has agreed what the model does. Start with the choices that set the total: how many inputs, how strict the quality bar, how many parties touch the data, how long anything is kept. The guides walk through each of those levers and what moving it does to the workload.
Every extra item on a form has a life: it must be gathered, validated, corrected when wrong, stored, protected and eventually deleted. One field looks free. Forty of them become a standing job. We set out how collection methods and quality requirements shape the cost of a model's front end, and how to tell a useful input from a habit.
Keeping everything feels safe and prices itself quietly, month after month. The honest comparison is between the running cost of retention and the value of a question you might ask later. We describe how to frame that trade-off, and why an undated "keep indefinitely" is usually an unpriced decision rather than a cautious one.
Most models behave beautifully while their unwritten assumptions hold: the file arrives, the format is stable, one person remembers the rules. We look at how to surface those assumptions early, because the cost of an assumption is paid not when it is made but when reality departs from it, often at the worst moment.
Every model has boundaries, and outside them it produces confident nonsense. Knowing where the edges sit is what separates a limitation from a failure. We cover how to state what a model does not cover, who should be told, and how that disclosure changes the practical cost of being wrong.
Seven guides follow one thread: where the real effort in an information process model sits, and which everyday decisions quietly move the total. No prices, no products, no recommendations — just the mechanics, in plain English.
