A script I depend on reported that it had sent ninety messages. It had. Every line in that log was true. What the log did not say, because nobody had asked it to, was that the messages had been handed to a queue that was not draining. They sat there for two days while the status stayed green.
Nothing in that log was false. It simply did not describe the thing I cared about.
I build small automations for small businesses, and this is the failure I now look for before any other. Not the system that breaks loudly. The one that reports success while doing nothing.
A surface is not what ran
Every automation has two parts: the work, and a surface that tells you about the work. A log line. A green tick. A row count. A 200 back from an API.
That surface is a separate artifact. It was built by separate code, usually written at a different time, by someone thinking about a different problem. It can be accurate. It can also be stale, scoped to the wrong step, or faithfully reporting on the part that comes before the part that fails.
A 200 means your request was accepted. It does not mean the email arrived. A mail client showing a message in Sent means the handoff happened; delivery is a different event, hours later, that nothing on your screen is watching. A dashboard that is green usually means the job started.
Hold those apart and most of the nasty surprises stop being surprising.
A check that never fails may be unable to fail
I had a spelling guard running over everything I published. It passed for weeks. It passed because, one busy afternoon, I had trimmed it to keep a payload small and left the trimmed version in place. It was not catching anything. It was incapable of catching anything, and its steady stream of passes read exactly like good news.
A guard whose failing branch has never fired in production is not proven. It is unobserved, and those are not the same.
So every guard gets a positive control: feed it something you know is bad and confirm it complains. Do it the day you write the guard. Do it again any time you touch the guard, and any time you touch the thing it watches. It takes a minute and it is the only evidence that the quiet is real.
Zero is not an answer
There are three states, not two. Pass, fail, and unknown. Most tooling only shows you two, so unknown gets quietly filed as pass.
A search of mine returned no results and I read that as nothing to do. The records existed. They simply never appear on the surface I was searching, so that query could only ever return zero. I had built a question that could not produce a yes.
When a check returns nothing, the honest reading is that you learned nothing. Before you act on an empty result, confirm the query can find something by pointing it at a case you know is there. If it cannot find the one you planted, it was never going to find the one you were worried about.
The witness should not be written by the thing it judges
An invoice is not proof of payment. The bank statement is. Your outbox is not proof of delivery. The recipient’s reply is, or failing that, the receiving system’s own record.
This is the rule most often broken, because the convenient evidence is nearly always the evidence the system produced about itself. It is right there, it is free, and it agrees with you. Independent evidence takes another step and sometimes another login.
Take the step. The whole class of failure being described here is a system being wrong about itself, and you cannot detect that by asking it again more politely.
Why this lands hardest on small businesses
In a company with an operations team, a silent failure gets caught by a person. Somebody notices the report did not come, the customer did not reply, the number looks wrong. The automation fails and the organization absorbs it.
In a four person business, the automation is the person who would have noticed. That is why it was built. Remove the human check, and the only thing standing between a broken process and a lost month is whether the thing tells you the truth about itself.
So the smaller the team, the more the verification matters, which is the exact opposite of how it usually gets budgeted. Verification is treated as polish, something to add once the thing works. For a small team it is the product.
The version that fits on one page
Four questions, for any automation you already depend on.
What exactly does the success message certify? Write the sentence out. If the honest version is “the request was accepted”, say so, and find out what would certify the part you actually care about.
What would make this check fail? If you cannot name a specific input that turns it red, you do not have a check.
Who produced the evidence? If the answer is the same system being judged, find a second source before you rely on it.
What does a zero mean here? Decide in advance whether an empty result means clean or means unknown, because in the moment you will read it as clean.
Before you automate the next thing
Most founders I work with do not need another tool. They need to know which of the tools they already run are lying to them, and none of them are lying on purpose.
If you are about to hand a process to a machine, the question ahead of which tool is whether the process is in a state where you would be able to tell that it had stopped working. That is what the AI Readiness Check is built to surface. Twelve questions, four minutes, scored out of 48, no email and the result is on screen: founderwise.io/ai-readiness/
If you would rather walk through your own stack with someone, book a strategy call: cal.com/pirwot/strategy-call
Advice is free. Being wrong about a system you already trust is not.
So: of the automations running in your business this week, which one has never once reported a failure? Start there.