An AI answer can sound finished while leaving out the one fact that matters. Verification means checking the parts that could change your action against evidence outside the answer itself. You do not need to fact-check every sentence of a low-stakes brainstorm. You do need to check claims before you publish them, send them to a customer, spend money, or change a record.
The five-step check
- Name the decision. What will someone do with this answer? A private outline needs a different level of checking from a public claim or a refund decision.
- Mark checkable claims. Highlight dates, names, numbers, prices, quotations, legal or policy requirements, and claims about what a source says. Also mark advice that depends on facts the tool may not have.
- Open the original evidence. Follow a citation to its actual page, document, or record. Check that it exists, is current enough for the decision, and supports the specific sentence. A link in an AI response is a lead, not proof.
- Recalculate and compare. Use the original inputs and a calculator or spreadsheet for arithmetic. Compare summaries with the original document. Check whether the answer omitted an exception or changed the meaning of a quotation.
- Decide and record. Keep supported claims, correct weak ones, and remove claims you cannot verify. For a consequential decision, note which source you checked, when you checked it, and who approved the result.
If a source is unavailable, say that the claim is unverified. Asking the same model to confirm its answer does not create independent evidence. The NIST profile for generative AI describes confidently presented false or misleading output as a risk that needs active management.
Worked example: a customer return reply
Suppose an assistant drafts: “Your purchase is eligible for a full refund because all returns are accepted for 30 days.” The business’s actual policy says: unopened products may be returned within 30 days of delivery; opened products need review. The customer says the box was opened and supplies an order date, but no delivery date.
The draft makes two unsupported jumps. “All returns” ignores the opened-product exception. The order date does not establish the 30-day delivery window. A checked response would say that the request needs review, ask for the delivery date, and avoid promising a refund. The human reviewer should compare the order record and current policy before sending anything.
That example is fictional, but the method is reusable: find the decisive rule, identify missing facts, and stop before an unsupported promise becomes an action.
A checklist you can print
Use your browser’s Print command to save this page as a PDF or print the list below.
- I know who will rely on the answer and what they may do with it.
- I marked factual claims, numbers, quotations, and policy statements.
- I opened each important source and checked that it supports the claim.
- I checked dates and whether the source is current for this decision.
- I recalculated important numbers from the original inputs.
- I checked for missing facts, exceptions, and conflicting evidence.
- I removed or labeled claims I could not verify.
- A person with the right authority approved any consequential action.
For recurring work, copy this list into the review step. The 30-minute pilot worksheet gives you a small task to practice on, and the workflow test guide turns repeated checks into example cases.