How to Tell Whether an Automation Would Even Notice a Silent Error
A crash announces itself. A wrong value does not. The three points a quote must cover so silent errors surface before they get expensive.
This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.
Buyers almost always ask what happens when an automation fails. The more expensive question is a different one. What happens when it runs through, reports no error and still writes wrong values?
A failure is a comparatively good event. It reports itself, someone looks, the run is repeated. A silent error reports nothing. It writes a value that is technically fine and factually wrong, and it keeps doing so until somebody stumbles across it by detour.
Why a wrong value is technically valid
The best known example is number formatting. German notation uses the dot for thousands and the comma for decimals. Many systems do the exact opposite. When a price travels between systems as text, 1.234,50 can arrive as 1.23. A pallet weight of 1,500 kilograms becomes 1.5, an order quantity of 2,000 units becomes 2.
None of the systems involved did anything wrong. A valid number went in, a valid number came out. That is what makes this class of error so awkward. The result looks plausible. A price of 1.23 is a price somebody could charge, and nobody blinks at the figure on its own.
The same pattern appears wherever meaning depends on formatting. Dates where day and month swap places. Time zones that shift an appointment by hours. Quantities without a unit. Addresses missing the line that says which ward or which gate. In every case the data type stays correct and the content turns false.
The damage grows with runtime
A crash costs you the record it happened on. A silent error costs every record between its start and its discovery. If a nightly price sync runs for three weeks with a misread value, it affects every order in those three weeks, plus invoices, credit notes and possibly goods already picked.
That is why time to detection matters more than error rate. Not how often something goes wrong, but how long it can go wrong unnoticed.
Three questions a quote has to answer
First, how does the automation recognise that a value is implausible? A field can be checked against a list of permitted values, against an upper and lower bound, against yesterday's value or against the history of that particular customer.
Second, what does it do in that case? The options are few. Stop the record, put it in a clarification queue, or let it pass with a flag. Which one is right depends on what the worst conceivable error would be.
Third, who finds out, and through which channel? A message that lands in a shared mailbox is not a message. It needs a named owner, a record reference and a note on what to do.
A quote that does not name these three points has priced the normal case. That is the most common reason a cheap automation ends up costlier than an expensive one.
Plausibility is a business decision
No supplier can invent the limits. They come from your company. At what deviation from yesterday's price should an article stop being published automatically? At what quantity does an order from a known customer need a second look? Which shipment weights are physically possible at all?
These decisions cost you no money, only a commitment. They are also the biggest lever you have on the price, because they spare the supplier from guessing and spare you the buffer that guessing gets priced at.
The reconciliation that catches most silent errors
Beyond field level rules there is one check that works independently of them. At the end of every run, compare record counts and totals between source and target. If they differ, something is wrong, regardless of whether anyone anticipated that specific case.
This check is cheap to build and catches exactly the cases no rule foresaw. It is still routinely missing from quotes, because nobody asks for it.
What safeguarding costs and what it is worth
Everything built around the business logic can raise the effort of a project noticeably. Restart after an abort, protection against double processing, validation rules, traceable logs. That is one reason two quotes for the same process can be far apart without either of them being dishonest.
The decision is not the supplier's, it is yours, and it hangs on a single question. What would the worst conceivable error be? An automation that writes an internal note may occasionally be wrong. One that publishes prices, triggers orders or handles patient data may not. Say that difference out loud when you ask for a quote, otherwise the supplier prices either too much safeguarding or too little, and you pay for both.
The recommendation
Ask for validation rules, clarification handling and notification as a separate line item, apart from the business logic. Write down beforehand which values are impossible in your business, and name the person who decides a clarification case.
A supplier who does not itemise this has not priced it. You will pay for it anyway, only later and without a quote.
Sophera Consulting defines plausibility limits, clarification paths and notifications together with the department that owns the process, and itemises that part of the fixed price separately, with no subscription and with handover and documentation. The starting point is free via the automation check.
This article was created with the help of AI.