Check whether the answer does the job you asked for, then verify the claims that could change what you do. Open the sources, recalculate important numbers, and try relevant examples. Use the supported parts, repair errors, and leave unresolved claims clearly marked.
What you need before you start
You want to check an answer before relying on it, sharing it, or acting on it.
Bring: The original task, the answer, relevant sources, and what could happen if it is wrong.
Start with these steps
- Check whether the answer does the requested job.
- Separate facts, calculations, advice, and assumptions.
- Open the sources behind important claims.
- Recalculate important numbers and test relevant examples.
- Use supported parts, repair errors, and mark anything unresolved.
A prompt you can adapt
Evaluate this answer for [purpose]. List each material claim, its supporting evidence or missing source, assumptions, uncertainty and a practical check. Test the answer against [edge case]. End with use, revise or stop and explain why.
Replace every bracket with real information. Remove fields that do not affect your task.
What this looks like in practice
Teaching example: if 18 of 120 eligible responses mention a problem, the rate is 15%. An answer that divides by a different group may sound clear while giving the wrong result.
Decide what the answer must do
An answer can be well written and still fail your task. Start by returning to the original question. Did you need a simple explanation, a comparison, a working file, or a decision? Write a few conditions for a useful result. An email may need the correct facts and one clear request. A data summary may need the right population, dates, and calculation.
Check coverage before polishing the language. If you asked for three options and received two, the answer is incomplete. If you supplied a document and the answer never refers to it, ask whether it was actually used. A confident summary of the general topic is not a substitute for reading your source.
Match the checking effort to the consequence. A list of ideas for a birthday card does not need the same evidence as a public report or a change to a live system. Focus first on the claim or action most likely to cause a meaningful error. That keeps checking useful without turning every small draft into a long audit.
Separate facts, calculations, and advice
Mark the different kinds of statements in the answer. A fact says something is true. A calculation combines values. A recommendation says what you should choose. Each needs a different check. A correct calculation can still use the wrong input, and a correct fact may not support the recommendation built on it.
Ask ChatGPT to list the important claims and their support. Treat that list as help finding the checks, not as proof that the claims are true. The same model may repeat its earlier mistake. You still need to open the source, inspect the data, or run the relevant test.
Look for assumptions hidden in ordinary sentences. “This is the cheapest option” may assume the quoted price includes all required parts. “Most users preferred it” may assume the sample represents users generally. “The task is complete” may assume a file was saved or an action succeeded. Name those assumptions so you can check them directly.
| Statement type | Useful check |
|---|---|
| Fact | Find the exact supporting source |
| Calculation | Check inputs, units, and arithmetic |
| Recommendation | Test priorities and assumptions |
| Completed action | Inspect the real result or receipt |
| Unknown | Keep it visible until resolved |
Open the source and compare the exact claim
A real link can still fail to support the sentence beside it. Open the page and find the relevant passage. Check whether it describes the same product, date, country, group, or software version. A study about one group does not establish a result for everyone. An old feature page does not prove the feature is available in your account today.
For a quotation, compare the words with the original and read the surrounding passage. A short quote may lose an exception or reverse the author’s point when taken out of context. For a policy, check the current official source and the conditions that apply. Do not accept a citation merely because the domain looks familiar.
If you cannot open the source, mark the claim unverified. Ask for the missing source details or find an appropriate primary source yourself. Do not replace the missing evidence with another fluent explanation. When sources disagree, check their dates, definitions, and scope before treating one as wrong.
Work through a percentage that uses the wrong denominator
This teaching example uses invented survey data. There are 150 records in an export, but only 120 are eligible completed responses. Eighteen of those eligible responses mention a delivery problem. The percentage for eligible completed responses is eighteen divided by one hundred twenty, multiplied by one hundred. That is fifteen percent.
An answer that reports twelve percent has probably divided by all 150 records. The arithmetic is correct for that different denominator, but it does not answer the stated question. The repair needs to name the group, not merely change the number. “Fifteen percent of eligible completed responses mentioned a delivery problem” is clear about what was counted.
Recalculate important numbers outside the chat with a calculator or spreadsheet. Check units, signs, dates, rounding, and whether the same person appears more than once. A total of comments is not automatically a total of people. If the source has missing or excluded rows, explain how they affect the result before making a broad claim.
Eligible responses = 120
Responses mentioning the problem = 18
18 / 120 × 100 = 15%
All export records = 150
18 / 150 × 100 = 12%
This answers a different question unless all records belong in the denominator.Challenge the assumption that could change the conclusion
For a recommendation, ask what would make it fail. A travel plan depends on services running on the travel date. A product choice may depend on compatibility. A schedule depends on the time actually available. Check the assumption most likely to reverse the decision before spending time on minor wording.
Ask for a counterexample: a case where the answer’s rule would not apply. If the model says a process always saves time, consider a very small task where setup takes longer than doing it by hand. If it recommends a tool because it is cheap, include the required extras and the cost of switching. A useful challenge tests the mechanism, not just the model’s confidence.
Do not ask only “Are you sure?” A second confident reply does not add evidence, and a sudden apology does not prove the first answer was wrong. Ask for the specific source, calculation, or test that would settle the issue. Keep the conclusion limited to the conditions you have actually checked.
Check files, code, and completed actions in the real place
If ChatGPT creates a file, open it. Check the pages, sheets, or sections that matter. Confirm that the file is the requested type and that important content is present. A download link or a statement that the work is done does not show that a table is readable or a formula uses the right cells.
For code or a formula, try a small known example and a boundary case. Choose a case that could expose the likely failure, such as an empty input, a duplicate record, or a missing value. Run it in the environment where the result will be used when practical. A test described in prose is different from a test that actually ran.
For an external action, inspect the actual result. Drafting a message is different from sending it. Preparing a page is different from publishing it. A tool can fail after the model has produced the right wording. Ask for the receipt or check the destination, and keep partial completion separate from success.
Repair the failed part and keep the supported work
Once you find an error, give the correct evidence and identify the affected passage. Ask for a focused repair. If a wrong number changes the conclusion, request both changes. Keep the accurate facts and useful structure rather than rewriting everything without a reason.
Read the revised version against the original. Check that the error is fixed and that no new facts or promises appeared. A softer tone can hide an unsupported claim, so judge the meaning as well as the wording. If the source remains missing, removing certainty is not the same as verifying the claim.
You may be able to use only the supported part. For example, a report can describe the confirmed response count while postponing a comparison whose data is incomplete. Say what is known and what still needs checking. That is more useful than either accepting the whole answer or discarding everything because one passage failed.
Keep a short record for work you will reuse
For important work, save the claim, its source or test, the result of the check, and the remaining uncertainty. The record can be small. It should help someone else understand why the answer was accepted and what would require another check.
Refresh the parts that can change. Prices, rules, availability, account features, and software behavior may need new evidence when reused. A checked explanation from one date or dataset does not automatically apply to another. Keep stable explanations separate from changing facts so updates are easier.
Finish with a clear state: ready to use, needs a named correction, usable within a stated limit, or waiting for a missing fact. The goal is not to prove that ChatGPT is always right or always wrong. It is to know what this particular answer supports before you rely on it.
Check the result before you use it
- Does the answer meet the actual request?
- Did the most important claims pass independent checks?
- Is it clear what remains unknown?
Watch for: A confident tone or a real-looking link does not prove the answer is correct.