Trust, but verify

The last three modules were about putting AI to work: projects and connectors, research and writing, automations. This one is about the other half: knowing that what came out is right before it reaches a customer, a contract or a decision. In the 4D framework this is discernment, and here we take it from "read critically" to a set of checks you design once and that run every time.

Why does verification have to be designed in rather than left to good intentions?

Because three things you have already seen in this course work against you at once. First: the model sounds exactly as confident when it is right as when it is making things up (module 1). Tone gives you no clue, and nobody has the attention to doubt every sentence that sounds fine. Second: sycophancy (module 5). Ask "is this good?" and it will most likely say yes; show your opinion before asking for its own and it will agree with you. Third: in an automation (module 8) nobody is watching. A mistake you would fix in two seconds in a chat gets repeated a hundred times in a job that runs every night, mixed in with the correct results, and by the time someone notices, everything has to be checked backwards.

Good intentions ("I always review") fail because reviewing is boring, the draft almost always looks fine, and by the tenth one you are no longer reading, just skimming. So verification is not a habit; it is a part of the workflow: a named step, with an owner and a concrete question that gets a yes or a no. In this module you build three pieces: a list of what to check by output type, a test set for each workflow, and a fixed point where a person approves.

How do I verify each type of output?

Not everything is checked the same way. Text gets read; a figure gets recomputed; an extracted table gets sampled. This is the list we use, by type:

• Facts (names, dates, articles of law, quoted figures, prices). The only valid check is opening the source. If the model used web search, open the link and confirm the page says that; if it worked from a document you gave it, ask for the exact quote and find it in the original with Ctrl+F. A fact with no source you can open counts as unverified and comes out.
• Numbers and calculations (totals, percentages, projections). A language model predicts text; it does not calculate. Recompute whatever matters yourself, or ask it to use code execution and show the operation. A cheap control: always ask for the total to appear next to its parts, and check that they add up.
• Long documents (summaries, reviewed contracts, translations). Compare against the original, not against your memory of the original. For a summary: take three claims from the summary and look for them in the document, and three points from the document and look for them in the summary. For a contract or a translation: read the clauses that matter (deadlines, amounts, obligations) side by side.
• Customer-facing text (replies, quotes, posts). Three questions: is the tone ours? does it promise something we cannot deliver (a discount, a date, an exception)? does it contradict a policy? The third is solved by putting the policy in the context document and asking it to flag any sentence that steps outside it.
• Extracted data (from invoices, emails or forms into a table). You are not going to read a thousand rows. Two controls: validation rules applied to every row (subtotal plus VAT equals total, tax ID exists in your supplier list, dates within range, required fields filled) and a random sample that a person compares with the original document, counting errors per field rather than per document. Anything that fails a rule goes to manual review. The post on extracting invoice data works through this case.

I am going to give you two things: a SOURCE and a TEXT that is supposed to be based on it. Your job is to verify the text against the source, not against what you know.

Instructions:
1. Split the TEXT into individual claims (one per fact, figure, date, name, promise or conclusion).
2. For each claim, find the exact quote in the SOURCE that supports it.
3. Classify each one as: SUPPORTED (there is an exact quote that says it), NOT SUPPORTED (the source says something else or contradicts it) or NOT IN SOURCE (the source does not cover it).
4. Use only the SOURCE. If something is true according to your general knowledge but is not in the source, it goes under NOT IN SOURCE.

Deliver a table with four columns: claim, classification, exact quote from the source (or "none") and a short note. At the end, list the claims I should remove or correct before using the text.

SOURCE:
[PASTE THE DOCUMENT OR THE PAGE TEXT]

TEXT:
[PASTE THE DRAFT]

How do I test a workflow before I trust it?

Everything above is for checking one output. When the same prompt is going to run a hundred times (an email classifier, a data extractor, a reply drafter), checking one output tells you nothing about the other ninety-nine. For that you need to test the workflow, and the way to do it is the same one teams that build seriously with AI use, just smaller: a test set of real cases and a written rubric.

1. 1Collect 10 to 20 real past cases whose correct answer is already known: ten emails you already classified, twenty invoices you already typed in, fifteen customer messages you already answered well. Include the ugly ones: the ambiguous email, the invoice photographed at an angle, the message in two languages. Anthropic recommends that test cases mirror the real distribution of the work and that edge cases not be forgotten.
2. 2Write the rubric: for each case, what the output must satisfy to count as correct. Specific, measurable criteria, not "it looks good": "the category matches mine", "all six fields are identical to the original", "it promises nothing that is not in the policy", "it is under 120 words". Anthropic’s guide puts it this way: instead of "good performance", specify "accurate classification".
3. 3Run the cases with the prompt as it is today and grade each one against the rubric. Record the result per criterion, not an overall "more or less fine".
4. 4Measure: 14 out of 20 correct is a number; "it usually gets it right" is not. Look at where it fails: if every error sits in the same field or the same kind of case, you already know what to fix.
5. 5Fix one thing and run again. Change the prompt, add an example, adjust the context document, and repeat the 20 cases. If the score went up, keep the change; if it went down, undo it. One change at a time, so you know what helped.
6. 6Keep the set and rerun it every time you change the prompt, the model or the context. It is your insurance against "it worked last week".

In plain language, these are evaluations: what module 20 covers with tooling and at volume. Anthropic recommends automating the grading where possible and prefers many automatically graded cases, even with a slightly weaker signal, over a few graded by hand. With 20 cases and a spreadsheet you already know whether you can trust the workflow, for what, and how much.

I have an AI workflow that does the following: [WHAT IT DOES: for example, "classifies customer emails into quote, support, complaint and other", or "extracts tax ID, number, date, subtotal, VAT and total from PDF delivery notes"]. The current prompt is:

[PASTE THE PROMPT]

I want to build a test set to measure it. Help me in three steps, and do not move to the next one without my answer:

Step 1. Ask me for 10 to 20 real past cases with the correct answer already known. Tell me what variety I need to cover (typical, ambiguous, badly formed, rare) so the set reflects my real work, and ask me to paste them anonymized.

Step 2. With the cases, write a rubric: for each criterion, one specific sentence that can be answered yes or no (for example, "the category matches mine", "all six fields are identical to the document", "it promises nothing that is not in the policy"). Avoid criteria like "it looks good".

Step 3. Give me a table with one row per case and one column per criterion, ready for me to run the prompt and mark yes or no, with a final row that counts passes per criterion.

Where do I put the person who reviews?

Having a person in the process does not mean someone glances at it now and then. It means a fixed point where the workflow stops and waits for approval. The rule for placing it: before the action takes effect outside your company or on your data. A draft reply waits before it is sent; an extracted table waits before it enters the accounting system. If you put the check afterwards (reviewing what was already sent), it is not a check, it is an audit.

How much to review changes over time:

• At first, 100%. For the first weeks of any workflow you review everything, and every error you find goes into the test set as a new case. That is not distrust: it is how the set gets built.
• Then, a sample. Once the test set gives stable results and you have gone weeks without finding errors in full review, move to a random sample (one in ten, say) and keep reviewing 100% of whatever trips a red flag.
• Never below 100% for what cannot be undone: payments, contracts, replies to a formal complaint, anything that carries your signature. There, AI prepares and a person sends, always.

And some signals should trigger human review regardless of the sample. Write them into the workflow as rules, not as the reviewer’s judgment:

• Money appears: an amount, a discount, a refund, a payment term.
• A commitment appears: a date, an exception, a promise that something "will be sorted out".
• The customer’s tone is a complaint, anger or a legal threat.
• The output says "I don’t know" or "I don’t have that information", or leaves a field empty. That is the model’s correct answer and the signal that a person has to step in.
• The output breaks the agreed format (an extra column, text where a number should be, the wrong language).
• The case looks like nothing in the test set: a new supplier, a new document type, a question you have never seen.
• It involves personal data or decisions about people: hiring, collecting a debt, turning something down.

Is it useful to have another AI review what the first one did?

Yes, with a clear limit. Asking a second model, or a fresh chat with none of the conversation’s context, to review an output is useful for the same reason a second person is: it does not carry the bias of having written it. It finds contradictions, unsupported claims, a shift in tone, a promise that was not in the brief. Anthropic uses this in its own evaluation guides and recommends that the grading model be different from the one that produced the output.

The limit: an AI reviewer compares the text with what it knows, and what it knows has the same problems as what the first one knew. Two models can agree on a false fact. If the reviewer has no access to the source (the original document, the page, the real figure), it can tell you the text is coherent, not that it is true. So the division of labor is: the second model reviews form, consistency and compliance with the rules you gave it; the source verifies the facts; the person approves. An AI reviewer saves you time on the first two steps and never replaces the third.

Act as a skeptical reviewer. Your job is to find problems in the text below, not to improve it or praise it. Assume it was written by someone competent but rushed, and that a person will answer for it in front of a customer.

Context: the text is [WHAT IT IS: a customer reply, a quote, a contract summary, an article] and it is addressed to [WHO]. The rules it must follow are: [PASTE THE POLICY, THE BRIEF OR THE RULES].

Review in this order and report only what you find:
1. Factual claims with no support in the material I gave you (list each one).
2. Promises, dates, amounts or exceptions the rules do not allow.
3. Contradictions, internal or with the rules.
4. Tone: sentences that would not sound like us.
5. What is missing: something the reader would expect that is not there.

Do not fix the text. For each problem, quote the exact sentence and say why it is a problem. If you find nothing in a category, say so in one line. End with your recommendation in one word: SEND, FIX or DO NOT SEND.

TEXT:
[PASTE THE DRAFT]

Module 10, "Bringing AI to your team", closes Part 2: usage policies, training, what to measure and how to go from everyone with their own ChatGPT to a shared method. What you built here is exactly what that method needs so that trust does not depend on who happens to be reviewing that day.