I described someone else's system from common sense. Everything fit except the truth

I was writing out the path of a document through an office system — enquiry, quote, contract, invoice — and arrived at the place where the process breaks: duplicates in the customer file. The same customer three times, each copy holding part of the history.

I wrote the cause straight off, because it seemed obvious: the search demands an exact name, and with a customer waiting on the phone it's quicker to create a new record than to find the old one. The sentence sounded good. Anyone who had worked in an office would have nodded.

It was untrue.

What the check said

I showed the text to a person who had worked in that system for five years. The answer turned the paragraph 180 degrees.

The search was good. It searched by name, by customer number and by a vehicle's registration plate — by any fragment, with a list of suggestions as you typed. In the office people mostly searched by plate, because it's the one thing a customer standing at the counter always has on them.

The duplicates appeared anyway, because the break was somewhere else entirely: when a customer was created, the program checked nothing. You could create ten records with an identical name and an identical address. The only thing telling them apart was the next customer number.

You only see it later, in the search results — two or three entries you can't tell apart. To decide which one is "the right one", you have to open each and see which one has the orders and invoices attached. There was nothing to merge them with, so users invented their own workaround: on an abandoned record they added a note, "inactive, see customer number …".

Two functions that have nothing to do with each other

This is the core of it, not the mistake itself.

"It's easy to search" and "you can't create a duplicate" are two separate functions of the system. Nothing connects them — not the code, not the screen, not the moment of use. The first works on read, the second on write. A system can have one in full and the other not at all.

My wrong description fused them into a single mechanism, because that's what common sense suggests: if there are duplicates, finding the original must have been hard. The reasoning is sensible and leads to the wrong place.

At acceptance of a rollout, almost always the first one gets tested. You type a fragment of a name, see the suggestions, nod. The question about the second is rarely asked, and it goes like this:

What happens when I create a second customer with exactly the same details?

The answer is sometimes silence and a new record. A year of cleaning up the customer file costs many times more than one warning at the moment of saving.

Why I didn't notice myself

Because in the wrong version there was nothing to notice.

Compare the two sentences:

• Duplicates came about because the search demanded an exact name, so it was quicker to create a new customer than to find the old one.
• Duplicates came about because, when creating a customer, the system didn't check whether one already existed.

Both have a sensible mechanism. Both end in the same outcome. Both sound like a memory from an office, not a theory. Reading them, you can't point to the invented one — because an invented account doesn't contain an error, it contains plausibility.

There is exactly one difference, and you can see it only once you know the true version: the true one contains a detail the reader would never come up with alone. That a system with good search across three different fields can have no check at all on save. Such things aren't guessed, because they aren't logical — and office systems grow over years and are under no obligation to be logical.

What I did NOT do

I didn't go back to the search to "mention it anyway". It was tempting, because the paragraph was written, it read well, and it seemed a pity to delete — I could have kept it as a second, minor cause.

That would have been worse than the error itself. The sentence "and besides, the search could be awkward" is exactly the same untruth, only tucked into the background where nobody will check it. The paragraph went in the bin in its entirety.

I also didn't add a warning to the text saying "this description may be inaccurate". A note of uncertainty makes sense when checking truly isn't possible. Here it was — all it took was asking. The warning would only have moved the cost of verification onto the reader, who has worse tools for it than I do.

The conclusion I'm taking forward

Process documentation written "from common sense" contains no visible error. It contains a smooth untruth. There's no place in it that would jar — which is why it gets through every proofread, every read-aloud and every "sounds sensible".

The only thing that detects it is someone who was there. Not a reviewer, not a second pair of eyes, not a language model — a witness. Since I saw this, I split every paragraph about someone else's system into two categories: what I saw or have a record of, and what I added because it fitted. The second category isn't bad. It just has to go out for verification before anyone reads it as fact.

Not to be confused with the situation where a measurement failed or came from a different day. Here there was no measurement at all — there was a plausible hypothesis cast in the role of a fact. It's the hardest case to catch, because there's nothing to compare against anything.