Module 4 · Check before you trust
Our review routine
In short
An AI report saying "done" is not evidence yet. Our routine answers three things: who checks, what evidence to look for, and when you may stop. The bigger the risk, the more evidence you collect and the more you need a second pair of eyes.
After this lesson you can
- Run our review routine: who checks, what evidence to look for, when to stop
- Match how thoroughly you check to the size of the risk
Terms in this lesson
Understand
In our team, checking AI output is a habit, especially now that AI does work, not only writes. The previous lesson showed what to check in one output. Here we turn it into a routine.
The more you use an AI agent, meaning AI that carries out steps itself such as changing files, filling in data or sending messages, the more often you get reports like "done, 40 records updated, no issues". The model writes that report the same way as any other answer: as a plausible continuation of text. If one step failed without any message, the report can still say "done". This is the form of hallucination that slips through most easily, because we want the work to be done.
Our rule of thumb: what counts is evidence you can open yourself. A report saying "done" does not count yet. The routine answers three questions.
Who checks? The person who asked for the work checks the result themselves. Asking the same model to check its own work does not count as a check. For high-risk output, add a second pair of eyes: someone else who did not help make it. The maker tends to read what they meant, while a fresh reader reads what is written.
What evidence do you look for? Evidence lives where the result lives, outside the conversation: data that changed in its system, a file that is saved and opens, an email in the sent folder, a page that looks right from the side of the person using it. For large batches, take a random sample, plus every high-risk item. Out of 40 customer records, for example, open five at random and every one that touches billing. This is a small evaluation you can repeat every time.
When do you stop? When every item on your risk list has evidence. Do not guess or polish an item that cannot be proven: mark it "not yet proven", hold the result, or send it with an honest note. Stopping also means knowing the limit: a routine that is too heavy for small things gets abandoned.
How thoroughly you check should match the risk. We use three levels.
Low risk: output for yourself that is easy to fix. Personal notes, a first draft, title ideas. Read it once, fix what looks off, done.
Medium risk: output read by colleagues or clients but still correctable. Internal reports, customer emails, presentation material. Run the claims list from the previous lesson, match every high-risk claim to its source, and keep the result of your check.
High risk: output that touches money, law, health, decisions about people, or that is published, and that is hard to take back. Contracts, official announcements, payroll data, changes to a system many people use. Match every claim, record the evidence where others can see it, and have a second pair of eyes approve before the output is used. For legal or health matters, pick a second pair of eyes with authority in the field. This material is not legal or medical advice.
A sign you picked the wrong level: you feel relieved because "the AI said it checked". Nobody else can open and check that feeling.
Before
The prompt
Update the prices of 40 products in the catalogue to match the new price list. Report when done.
What came back
Done! The prices of 40 products have been updated to match the new price list. No errors during the process.
After
The prompt
Update the prices of 40 products in the catalogue to match the new price list. After that, do not just report done. For every product, make a row with: product code, old price, price on the new list, and the price now read back from the catalogue after the update. Mark "not yet proven" for products whose price you cannot read back from the catalogue, and mark "different" if the catalogue price does not match the new list.
What came back
37 products: the catalogue price matches the new list (table attached). 2 products marked "different": their codes on the new list have an extra space, so they did not match the catalogue and the price did not change. 1 product marked "not yet proven": this product was not found in the catalogue. In short: 37 of 40 proven, 3 need your attention.
What changed
- The first report says done, yet three products kept their old price.
- The better version asks for the price read back from the catalogue, row by row. A statement of done is not enough.
- The "not yet proven" category gives the model a way to be honest.
- You still open the catalogue and check a few random rows yourself, plus the three flagged rows.
Common mistake
- Mistake
- Accepting "checked, all fine" from the AI as the check, especially for high-risk output seen by one person only.
- Why it hurts
- That statement is just more text from the same model. If a step failed without a message, you find out only when a customer, a manager or the person whose data is affected finds it.
- Do this instead
- Look for evidence where the result lives. For high risk, ask a second person who did not help make it to check and approve.
Try
Sorting card
Sort these pieces of work by risk level.
Price change announcement on the public site
Meeting summary sent to the team
Title ideas for an internal presentation
A first draft you will rewrite yourself
Email reply to a customer about delivery schedule
Payroll changes for 120 employees
6 cards left
An AI agent reports: "The training invitation has been sent to 85 participants." Which evidence is strongest?
Take home
Ask for evidence read back
Works with any AI assistant.
Your prompt
After finishing ‹pekerjaan›, do not just write that the work is done. For every item, show evidence read back from ‹tempat-hasil›: the value before, the value requested, and the value now read there. Mark "not yet proven" for items that cannot be read back, and "different" for items whose result does not match the request. End with the number of items proven, different and not yet proven.
What went wrong for us
Flags that never reached their service
- Context
- New features are controlled by flags in environment variables. Our compose file passes an explicit list of variables to each service.
- What happened
- A new flag was set in the env file but not added to the compose list, so it never reached the app and the feature stayed off. Elsewhere, a worker's imports started reading AI flags it was not passed.
- Impact
- Features could stay off silently, without errors. The worker gap was caught by a guard test before release.
- Root cause
- Setting the env file is not enough when compose uses an explicit list, and nobody tracked which flags each service's code reads.
- What we did
- The flags were added to the compose list for every service whose code reads them.
- The guard we keep now
- A test maps every service to the flags its code reads and fails when compose does not pass them.
The lessonA feature that is silently off is more dangerous than one that errors.
What it means for your workA report that something is "set" does not mean it works. Check the result where people use it, because silent failures will not tell you.