Somebody says it in the review meeting, usually with a small shrug. Garbage in, garbage out. Everyone nods, the report stays wrong, and the meeting moves on. The phrase has become a way of closing a conversation instead of starting one.
It started as an honest description of a machine: a computer will process a wrong number as obediently as a right one. Used that way it is true and slightly useful. Used in a meeting about a broken supplier report it explains nothing, because it names the outcome and never asks the only question that leads anywhere. Which door did it come through?
There are five doors
Master data almost never arrives one way. In a system of any age it arrives through roughly five:
- Somebody typing into a screen, one row at a time.
- Somebody pasting four hundred rows out of a spreadsheet.
- A file import, usually a CSV or an Excel sheet from a supplier.
- A scheduled load from an ETL job, running at three in the morning.
- An API call from another system, which nobody watches at all.
Now ask where the validation lives. In most systems I have looked at, it lives in the first one. It was written when the screen was built, by the person building the screen, in the language the screen is written in. The other four routes write to the same tables and never render that screen.
That is the whole mechanism. The routes that carry volume are the routes with no lock, and volume is where garbage lives. One careless paste puts more bad rows in than a year of typing.
Put the lock on the write, not the door
Move the check to the one thing every route has in common. Every one of those five doors ends in a write to a table. Put the rule there and the number of guarded routes stops being a function of how many screens somebody remembered.
In Primentra a business rule belongs to the entity, not to a screen, and every write goes through the same stored procedure. Type a value the rule refuses and the save is refused. Paste four hundred rows and the offending ones are named. Import a file and the bad rows are reported against their line numbers. Stage a batch overnight and the violating rows are held back while the good ones load. Call the REST API and you get the same refusal, with the rule and the column in the message.
Approvals get checked twice, which surprises people. A rule runs when the change is submitted, so a broken row never reaches the queue and lands on a reviewer who cannot fix it. It runs again when the change is applied, because the world may have moved while the request sat waiting. And an administrator's force approve skips the approvers, not the rules. That is deliberate, and we wrote about it in approval on every route in.
Refuse or flag, per rule
Not everything deserves a locked door, and treating every rule as a blocker is how a data quality programme becomes the thing people route around.
A fact that is definitively wrong should refuse the save. A negative price. A duplicate supplier code. A start date before the company existed. Letting those in means somebody cleans them up in three months with less information than the person who typed them had at the time.
A judgement call should warn instead. The row saves, it carries a marker, and a reviewer decides. A warning that travels with the record is worth more than a blocker people learn to defeat by putting a space in front of the value.
And the garbage already in there
A new rule does not reach backwards, and it should not. Silently rewriting rows nobody reviewed is a worse problem than the one you started with.
Running a rule across existing data is a separate, deliberate action. It flags every row that breaks the rule and changes none of them, which turns a vague sense that the data is bad into a list with names on it. That is a different job from stopping new garbage, and doing them in the wrong order is why cleanup projects repeat. More on that in running rules against data you already have.
Where the phrase is still right
No rule catches a value that is wrong and plausible. A supplier address that is real, correctly formatted, unique, and belongs to the wrong supplier passes every check anyone can write. That is not a gap in the tooling; it is the boundary of what a rule is.
Past that boundary you need someone who owns the domain and reviews changes to it. What the gate buys you is that their attention goes to the hard cases instead of being spent on negative prices and duplicate codes.
Common questions
We already validate in the entry form. Is that not enough?
Only for the people using the form. A paste of 400 rows, a file import, an overnight load from an ETL job and an API call all write to the same table without ever rendering your form. Those are the routes that carry volume, which makes them the routes that carry most of the garbage.
Will strict rules stop people working?
They stop people saving rows that are definitively wrong, which is the point. For anything that is a judgement rather than a fact, use a warning: the row saves, it is flagged, and a reviewer sees it. The mistake is making everything an error, and the other mistake is making everything a warning.
What happens to the rows already in there?
Nothing, until you ask. A rule applies to what is written from now on. Running it against existing data is a separate action that flags rows without changing them, so you get a work list rather than a surprise rewrite of records nobody reviewed.
Can a rule catch a value that is wrong but looks fine?
No, and be suspicious of anyone who says otherwise. A rule catches what breaks a stated expectation: a range, a format, a duplicate, a relationship between two columns. A plausible wrong address passes every one of them. That is what review and ownership are for.
Count the doors into your master data
Then check how many of them run the same rules. In Primentra it is all of them, because the rule lives with the entity rather than the screen. Runs on your own SQL Server, deploys in a day, €7,500 per year flat with a 60-day trial.