Review a claim against its evidence

Version 1.1 · Published October 13, 2026 · Revised October 13, 2026

Newly authored public companion, October 2026. This standalone practice card can be read and used without installing software.

The skill

Make one important claim precise enough that another person can check it. Separate the work that happened from the conclusion someone wants to draw. Use this when reviewing an AI-generated artifact, research note, software result or creative draft.

Inputs

• One claim, written exactly as it is currently stated
• The output the claim refers to
• Available evidence, including how it was collected
• The decision that depends on the claim
• Time and access limits on the review

Do not bring private data into a public review record. Work from permitted material or a synthetic example.

Procedure

1. Restate the claim narrowly. Replace “it works” with a description of the behavior, conditions and version.
2. Inspect the evidence. Identify whether it is a plan, an originating report, a direct observation or a fresh repeat check.
3. Ask whether the evidence tests the actual claim. A file existing is different from a reader being able to use it.
4. Look for the most consequential missing case. Record it without pretending it has already failed or passed.
5. Write a bounded conclusion and the next action it supports.
6. Keep unresolved failures beside success counts. Preserve the denominator and what was not tested.

NIST's AI Risk Management Framework treats AI risk management as an ongoing, context-dependent activity. This card is a small editorial practice for reviewing evidence; it is not a NIST assessment, certification or full risk framework.

Output template

Claim:
Artifact or version:
Decision this would support:
Evidence inspected:
How the evidence was obtained:
What it directly establishes:
What it does not establish:
Failure, uncertainty or missing case:
Review conclusion: supported in scope / partly supported / unsupported
Next check or repair:
Reviewer and date, if appropriate for the audience:

Synthetic practice case

Claim: “The new signup form is ready.” Evidence: three automated checks passed. Available checks cover rendering, required-field labels and submitting a valid test address.

A bounded conclusion is: “The three named checks passed in the test environment.” The evidence does not yet establish delivery to the inbox, consent handling, keyboard usability or operation under failure. Choose the missing check that matters most for the planned release instead of treating three passes as universal readiness.

Copy-ready prompt

Review the claim below using only the supplied evidence.
Claim: [paste]
Decision at stake: [paste]
Evidence: [paste permitted material]

Return the completed evidence-review template. Preserve the difference
between a proposed test, a reported result and a check you directly
performed. Do not invent test runs, reviewers or measurements.

Name the smallest additional observation that would most improve the
conclusion. If the evidence conflicts, describe the conflict and leave
it unresolved until a relevant check is available.

Check your practice

The output should let someone answer three questions: What was checked? What conclusion follows? What remains unknown? If those answers are not visible, revise the review. If the decision has substantial legal, financial, medical or safety consequences, use an appropriately qualified reviewer and the required domain-specific process.

Common mistakes

• Counting planned checks as executed checks
• Calling a self-report an independent verification
• Generalizing from one example to every use case
• Losing failed cases in a headline success rate
• Repeating a claim because it appeared in multiple summaries of the same source

Revision note

Revised October 13, 2026: added a practical worked check and a clearer next decision. Original publication and evidence limits are preserved.

Reconcile evidence that appears to disagree

Suppose a synthetic test record says “4 of 4 routes passed” and a later note says “the download is missing.” Before choosing which statement to trust, ask whether both refer to the same release, environment and route set. Four HTML routes can pass while a separate download fails; the records may describe different checks rather than a contradiction.

Write an evidence ledger with one row per observation: claim, release, location, method, result and limit. Leave unknown fields unknown. A screenshot of a button, a successful server response and a downloaded file are related evidence, but none is a substitute for the others.

For a draft learning guide, a useful sequence is:

1. Check that the page exists at the intended address
2. Inspect whether the complete method is present
3. Follow the download and compare the relevant content
4. Ask whether a new reader can perform the intended first task

The first three are release checks. The fourth needs a real reader attempt. The sequence is proposed; no results are implied.

Pick the observation that changes a decision

Avoid adding checks merely to increase a total. If release depends on whether a file is downloadable, inspect that file. If use depends on whether a learner can interpret an instruction, observe that reading task. Record what result would make you proceed, revise or stop before running the check. For a fuller comparison design, see Compare two prompts with a fair test.

Public references

• NIST: AI Risk Management Framework