It has to prove itself before it touches your business.

Before any automation goes live we build a test set from the work your business has already done: real invoices, real approvals, real emails, with the answers you actually arrived at. The automation is then asked to reproduce those answers from scratch.

In our own family's business this is 53 automations tested this way. The test set is built from that company's records, not a sample dataset, because an automation that works on somebody else's paperwork tells you nothing about yours.

The clearest example is payroll. Our family's manufacturing business has approved its monthly payroll by email every month since March 2015, more than eleven years without a gap, and every month since April 2018 has been pre-audited by an outside firm before payment. That is the record the payroll engine is tested against, and the test set grows with it every month.

Each automation refuses to produce output unless its test has just passed. It is not a warning in a log that somebody is supposed to read. The failing path simply produces nothing, so a broken automation is silent rather than confidently wrong.

Confidently wrong is the expensive failure. An automation that stops is an inconvenience; one that keeps going with a bad number is a payment you have to claw back.

Nothing is paid, posted, or sent because the machine decided it was right. Work arrives as a draft with the evidence attached, and a named person approves it. Authority is not delegated to the software, and the software cannot grant itself more.

Where money is involved the approval is per item: permission to post one document is never permission to post the next one. Closed accounting periods are refused outright, whatever anyone approves.

Every action, every approval, every rejection is written to an audit trail that is checked daily for tampering, with its own record kept off the database it describes. If the history were ever edited, the check fails.

The point is not that we expect tampering. It is that "trust us, the log is accurate" is not evidence, and an audit trail nobody verifies is decoration.

Your business changes. A test that passed in March is a statement about March. So every automation is re-run against its test set nightly, the result is published to a dashboard, and a failure raises an alert rather than waiting to be noticed.

We learned this the hard way: a component of our own system failed silently for six weeks because nothing was watching the one signal that would have caught it on day one. Now something is.

A test that cannot fail is worse than no test, because it manufactures confidence nobody checked. So we remove each safeguard deliberately and confirm the tests notice. If the tests still pass with a protection deleted, the tests were never testing it.

This has caught real gaps in our own work more than once, including two safety checks that appeared to be covered and were not, because a different check was quietly refusing first and hiding them.