Separate claims from the rest of the output
Start by copying the AI response into a document and highlighting every factual statement. Mark sentences that assert a specific result, number, behavior, or relationship. Leave opinions, suggestions, and filler unmarked.
This separation step prevents mixing solid information with speculative language. It also creates a clear map of what later steps must address. Teams can then focus effort only on the highlighted material rather than the entire response.
The process works best when done in a single pass without immediate judgment. Returning later to re-read the unmarked text can reveal overlooked assertions that were initially treated as filler.
- Underline numbers, dates, version numbers, and performance claims.
- Circle any statement that could be checked against documentation or code.
- Ignore hedging language such as 'usually' or 'often' for the first pass.
- Record the line number or paragraph location of each highlighted item for easy reference in later steps.
List every assumption the answer relies on
Read the highlighted claims again and write down what must be true for each one to hold. These hidden requirements are the assumptions. Common examples include 'the library version is current' or 'the input data matches the training distribution.'
Making assumptions explicit turns vague concerns into concrete items that can be tested or accepted. It also surfaces dependencies that may differ across environments or teams.
When an assumption cannot be stated clearly, the related claim should be treated as unverifiable until more context is available. This prevents carrying forward statements whose conditions remain unknown.
- Write each assumption as a short declarative sentence.
- Note any assumption that depends on unstated context such as hardware or environment.
- If an assumption cannot be stated clearly, mark the claim as unverifiable for now.
- Group related assumptions together so that testing one item can address several claims at once.
Design quick tests for the claims that matter
For each claim that affects correctness or safety, create a minimal test. The test can be a code snippet, a query against official documentation, or a small experiment. Record the expected result before running the test.
Keeping tests small reduces the chance that the verification step itself introduces new errors. It also makes it easier to repeat the check later if the answer is reused in a different setting.
Documenting both the test and its outcome next to the original claim creates an audit trail. Future reviewers can see exactly what was checked and what result was obtained without re-deriving the test.
- Keep tests small enough to run in under five minutes.
- Use the exact versions or conditions stated in the answer.
- Log both the test and its outcome next to the original claim.
- If a test cannot be completed quickly, note the reason and schedule a separate verification task.
Verify sources with primary references
Trace every cited fact back to an official source. Prefer vendor documentation, standards bodies, and peer-reviewed papers over secondary summaries. When the AI names a source, open it and confirm the exact statement appears.
Primary references reduce the risk of propagating errors that appear in summaries or forum posts. They also provide the most current wording and any qualifying conditions that may have been omitted.
When a source is missing or the link is broken, the claim should be marked for further research rather than accepted on the strength of the AI output alone.
- Check publication dates against the AI's knowledge cutoff if known.
- Confirm that any quoted numbers or limits match the current documentation.
- Note when a source is missing or the link is broken.
- Keep a copy of the exact source text that supports each verified claim for later reference.
Decide what can be reused and what needs human review
After the checks, tag each claim as verified, assumed, or rejected. Only reuse sections where every supporting claim is verified and every assumption has been tested or explicitly accepted by the team. Rejected claims require rewriting or further research.
A short log of verified claims and their sources makes future audits faster. It also helps new team members understand which parts of the answer have already been examined.
If more than one critical assumption remains untested, treat the whole answer as provisional. This conservative approach prevents partial verification from creating a false sense of completeness.
- Keep a short log of verified claims and their sources.
- Flag any remaining assumptions for the next reviewer.
- If more than one critical assumption remains untested, treat the whole answer as provisional.
- Schedule a follow-up review when new documentation or test results become available.