A device reported a successful sync. The receiving application never got the data. Nothing anywhere showed an error, so for a while nobody knew there was anything to look at.
That gap, between a step reporting success and the work actually arriving, is where a specific kind of loss lives. It is quiet, it can run for weeks, and the dashboard is green the entire time.
The thing reporting success is the same thing that was supposed to do the job. That is not confirmation. That is a self-assessment.
What green actually means
When a step reports success, it usually means something narrower than anyone reads it as. It means the instruction was accepted, or the connection opened, or the function returned without raising an error.
None of those is the same as the work landing:
- A message was sent and the recipient system rejected it silently.
- A file was written to a location nothing is reading from any more.
- A record was created with a field the next step needs and cannot parse.
- The job ran, found nothing to do because of a broken filter, and reported a clean run.
Every one of those is a success by the reporting step's own definition. Every one of them means the work did not happen. The report is accurate and useless at the same time.
Why this is worse with automation
When a person does the work, confirmation is a by-product. They see the reply, notice the folder is empty, hear from the client who did not receive anything. Nobody designed that check. It comes free with a human being present.
Automate the step and the check leaves with the person. What you get instead is a status, and a status is an assertion by the system about itself. You have replaced someone who would have noticed with something that reports.
This is also why the failure runs so long. There is no complaint, because the system is not complaining, and the person who used to would have said something by now.
Confirmation comes from the other end
The fix is not more logging or more alerts on the sending side. Everything on the sending side shares the same blind spot.
Confirmation has to come from the place the work was supposed to arrive.
| Instead of | Check |
|---|---|
| Sync reported success | The record exists in the destination, with today's date |
| Email service accepted it | The reply rate is not zero this week |
| Report generated | The file is the expected size, not an empty template |
| Nightly job completed | The number of rows it touched is plausible |
The shape is always the same. Ask the destination, not the sender, and ask it something a broken run cannot accidentally satisfy. "A file exists" is weak, because an empty file exists. "A file exists and is roughly the size of yesterday's" is much harder to fake by accident.
The check worth having is boring
You do not need a monitoring platform. For most operations one arithmetic check per automated process is enough, and it is the kind of thing anyone can specify even if someone else builds it.
Pick the number that would move if the work were really happening. Invoices sent. Records updated. Files received. Then decide what range is normal, and have someone look at it once a week. If it is zero, or half, or triple, that is your signal, and you get it in days rather than at quarter end.
The point of writing the expected range down in advance is that afterwards, when the number is strange, there is always an explanation available for why it might be fine. Deciding beforehand is what makes it a check rather than a conversation.
What to take away
- Treat a success status as a claim by the system about itself, not as evidence the work arrived.
- Put one confirmation at the destination for every automated process that matters, and make it something an empty run cannot satisfy.
- Choose the number that proves the work happened and the range that counts as normal, before you need it.
Automation removed the person who would have noticed. Deciding what counts as proof is how you put that back, and it is a business decision, not a technical one. The AI does the busywork, you still make the calls.