What you will learn
  • Break an answer into factual, computational, and interpretive claims.
  • Select a verification method suited to each claim.
  • Detect citations that fail to support the associated sentence.
  • Recognize why repeated agreement is not independent evidence.
  • Revise an answer to preserve uncertainty rather than hide it.

Before you begin

Read USE05 for sources and USE06 for testing code. The main exercise can be completed with a short explanation and a browser; programming is optional.

Check claims, not the overall impression

An assistant explains that a Raspberry Pi can read sensors, run Python, and accept a particular sensor’s 5 V output directly. The first two statements may be reasonable while the third can damage hardware. An answer is not a single block that must be entirely trusted or rejected. Separate its important claims.

Underline factual statements, calculations, recommended actions, and assumptions. Then prioritize those whose failure would affect your decision or project. A spelling error in a heading and an incorrect voltage instruction deserve different attention. Verification should focus effort where the consequence and uncertainty are greatest.

A hallucination is generated content presented as if it were grounded in reality when it is unsupported or false. The term does not explain every error. An answer may also contain outdated information, a wrong inference, or a simple arithmetic slip. Identifying the error type helps you choose a useful check.

Match the check to the claim

For a current hardware specification, consult the exact manufacturer page or datasheet. For arithmetic, calculate independently. For code, inspect the logic and run relevant tests in a suitable environment. For a quotation, compare with the original passage. For an interpretation, inspect its premises and consider plausible alternatives.

A recommendation combines facts and values. ‘Use this board’ depends on workload, budget, interfaces, and learning goals. Verify the facts and examine whether the priorities match yours. There may be no universal answer to confirm. The useful outcome is a justified choice under stated conditions.

Do not substitute one check for another. A source saying a connector exists does not establish that your cable fits. Code compiling does not prove it produces the intended output. A model’s confidence percentage is not a calibrated probability unless a suitable evaluation has established that relationship.

A complete verification prompt

Weak prompt: ‘Is your answer correct?’ This invites the assistant to restate its own conclusion without new evidence.

Improved prompt: ‘Review the following answer as a set of claims. Separate documented facts, calculations, assumptions, and recommendations. For each consequential claim, state a concrete verification method. If browsing is available, open the exact primary source and identify what it supports. Mark unsupported claims instead of supplying a confident guess. Do not treat your earlier answer as evidence.’

For the sensor example, a useful review would isolate supply voltage, signal voltage, controller input tolerance, and required conversion. These are related but different quantities. A module powered at one voltage does not automatically produce a signal safe for another device.

Follow-up prompt: ‘The source describes 3.3 V GPIO. Revise the sentence about direct connection and state what module information is still needed.’ Verification: Inspect the Raspberry Pi GPIO documentation, which identifies GPIO signals as 3.3 V. Then inspect the exact sensor documentation before choosing any connection method. This lesson does not provide wiring instructions for an unspecified module.

Use independent evidence

Asking the same model three times can reveal inconsistency, but three agreeing answers do not become three independent sources. The model may repeat the same learned error. Another model may share similar training material or infer from your leading prompt. Agreement is a clue, not proof.

Independence comes from a different evidential route: an original document, a manual calculation, a measured observation, or a test whose expected result was specified separately. A source copied by several websites is still one underlying source. Follow the chain to understand where the information originated.

Self-critique remains useful for finding candidates to inspect. Ask the assistant which assumption is weakest or what case might break the code. Then perform the check. The distinction is between generating a verification plan and completing verification; the former does not imply the latter happened.

Keep a useful uncertainty record

Use a compact record: claim, status, evidence, and next check. Status can be supported, contradicted, or unresolved. Avoid labeling a claim true merely because you did not find a contradiction. An unresolved question should remain visible when the answer is shared.

If a source supports only a narrower statement, narrow the wording. Replace ‘works with all cameras’ with the exact supported models or conditions. Replace ‘will improve learning’ with a description of the practice method and the evidence actually available. Precision often means reducing the scope of a claim.

For calculations, preserve units and intermediate values so another reader can reproduce the result. For code, record the tested input, output, and runtime version. For hardware, distinguish a documentation review from a physical test. Do not write ‘tested’ when you only inspected a diagram.

Finish with a clear action: accept the supported portion, correct the contradicted portion, and investigate the unresolved portion before relying on it. This is more productive than treating uncertainty as a reason to abandon every useful answer.

Important terms

Claim
A statement that can be examined for support or correctness.
Hallucination
Unsupported or false generated content presented as factual.
Independent evidence
Support obtained through a separate evidential route.
Validation
Checking that a result meets its intended requirements.
Unresolved
A claim whose available evidence is not sufficient for a conclusion.

Mini project: Audit a short AI answer

  1. Choose an answer containing five to eight factual or computational claims. Avoid sensitive topics for this practice.
  2. Separate the claims and identify the two with the greatest consequence if wrong.
  3. Check each using an appropriate independent route: source, calculation, or executable test.
  4. Rewrite the answer with supported claims, corrections, and explicit unknowns. Finish when each important sentence has a clear evidence status.

Common mistakes and debugging

  • Judging the whole answer by its confident tone: inspect individual consequential claims.
  • Counting repeated model agreement as independent support: find a separate evidence route.
  • Assuming a real citation supports everything nearby: locate the relevant passage.
  • Calling documentation review a physical test: describe exactly what was checked.

Independent challenge

Ask an assistant for a short comparison of two familiar tools, then find one sentence that mixes fact and preference. Rewrite it so the factual support and decision criterion are separate.

Check your understanding: 10 questions

  1. Why split an answer into claims?

  2. Does successful code execution establish correctness?

  3. Why is repeated agreement from one model weak evidence?

  4. What should happen to a claim supported only under narrower conditions?

  5. How should an unverified hardware behavior be labeled?

  6. In your own words, what does “Claim” mean?

  7. In your own words, what does “Hallucination” mean?

  8. In your own words, what does “Independent evidence” mean?

  9. In your own words, what does “Validation” mean?

  10. In your own words, what does “Unresolved” mean?

Quiz answers

Reveal all 10 answers after your attempt
  1. Different parts can have different evidence and error types, so each needs an appropriate check.
  2. No. The output must also match independently defined requirements and relevant test cases.
  3. It may repeat the same unsupported pattern rather than consult an independent source.
  4. Its wording should be narrowed to those conditions.
  5. As unresolved or not physically tested, with the remaining check stated explicitly.
  6. A statement that can be examined for support or correctness.
  7. Unsupported or false generated content presented as factual.
  8. Support obtained through a separate evidential route.
  9. Checking that a result meets its intended requirements.
  10. A claim whose available evidence is not sufficient for a conclusion.

Summary

Break answers into claims, choose suitable independent checks, and preserve unresolved questions. Verification is an activity with evidence, not a reassuring phrase.

Continue learning

Continue with USE10 to combine prompting, research, testing, and review into a controlled multi-step workflow.

Choose a connected learning path

Sources and further reading

Prepared 2026-09-18. Draft; verification method reviewed and GPIO source checked. No unspecified sensor wiring or physical test is claimed.

GO DEEPER

Extra reading & source documents

Optional reading alongside the lessons. These sources do not add to your course lesson count.

Explore the AI model guides →