Verify a doubtful answer

# Apply the “Verify a doubtful answer” guide in your agent

## Objective
Split the answer into checkable claims. Open their sources, find the supporting passage and check date, scope and exceptions. When evidence is missing, retain “unverified” and pause the decision that depends on it. Keep a record of corrections and remaining unknowns so the decision can be checked.

## Prerequisites
- Inspect the repository, documentation, and existing conventions.
- Confirm the need matches the guide scope: Check claims and citations before relying on your agent’s answer.
- Preserve the correct decisions already in place.

## Guide steps
- 1. Identify what needs evidence — A hallucination here is generated information presented as factual when it is false or inconsistent with the supplied material. Confident wording or a well-formatted citation proves nothing. A creative proposal clearly labeled fictional is not, by itself, a hallucination.
- 2. Create one line per useful claim — Start with claims that could change your decision. Record the exact claim, expected source, date or version, passage found, verdict and next action. A long answer is no reason to accept everything as a block.
- 3. Open and check the source — Open the cited link; check the author, title, date and full document. Find the relevant passage and read its surrounding conditions. A real page on the same topic may not support the claim. An inaccessible source remains inaccessible: request a usable document or record the limitation.
- 4. Decide with an explicit boundary — Classify each claim: supported within the checked scope, contradicted, or unverified. Recalculate operations from source values. If sources disagree, retain the disagreement and seek the applicable version; do not turn a vote among AI responses into evidence.
- 5. Correct the answer without losing the record — Request a corrected version that retains supported facts, removes contradicted claims and names remaining unknowns. Compare it with your verification rows so that rephrasing does not reintroduce an unsupported date, figure or condition.
- 6. Check whether the cited passage supports the condition — For a claim that a feature works offline, open the cited passage and locate the offline condition explicitly. Record supported, contradicted or not established. A page that merely mentions the feature cannot settle that condition.

## Acceptance criteria — Checklist
- The corrected version does not reintroduce a removed or unverified claim.
- Decision-critical claims are isolated.
- Every link was opened and its passage checked.
- Date, version and exceptions match the case.
- Calculations were repeated where needed.
- Unknowns and stop criteria are visible.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Anchor the guide in the project

## Objective
Turn the applied steps into durable repository conventions.

## Checks
- Link each decision made to the guide step that justifies it.
- Add the checklist to the relevant reviews.
- Record out-of-scope cases for the neighboring guides.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:89bc61121e471e7394a29113d65932a849f44a960e579ad6765d9d71a2e195f1

# Diagnose a failed application of the “Verify a doubtful answer” guide

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Replay the steps in order and note the first one that diverges:
- 1. Identify what needs evidence — A hallucination here is generated information presented as factual when it is false or inconsistent with the supplied material. Confident wording or a well-formatted citation proves nothing. A creative proposal clearly labeled fictional is not, by itself, a hallucination.
- 2. Create one line per useful claim — Start with claims that could change your decision. Record the exact claim, expected source, date or version, passage found, verdict and next action. A long answer is no reason to accept everything as a block.
- 3. Open and check the source — Open the cited link; check the author, title, date and full document. Find the relevant passage and read its surrounding conditions. A real page on the same topic may not support the claim. An inaccessible source remains inaccessible: request a usable document or record the limitation.
- 4. Decide with an explicit boundary — Classify each claim: supported within the checked scope, contradicted, or unverified. Recalculate operations from source values. If sources disagree, retain the disagreement and seek the applicable version; do not turn a vote among AI responses into evidence.
- 5. Correct the answer without losing the record — Request a corrected version that retains supported facts, removes contradicted claims and names remaining unknowns. Compare it with your verification rows so that rephrasing does not reintroduce an unsupported date, figure or condition.
- 6. Check whether the cited passage supports the condition — For a claim that a feature works offline, open the cited passage and locate the offline condition explicitly. Record supported, contradicted or not established. A page that merely mentions the feature cannot settle that condition.

## Possible causes
- A step was skipped or executed out of order.
- The actual need falls outside the guide scope.
- A checklist criterion was never verified.

## Bounded fixes
- Redo only the diverging step and what depends on it.
- Document the gap if the guide scope does not cover the need.

## Final verification — Checklist
- The corrected version does not reintroduce a removed or unverified claim.
- Decision-critical claims are isolated.
- Every link was opened and its passage checked.
- Date, version and exceptions match the case.
- Calculations were repeated where needed.
- Unknowns and stop criteria are visible.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Prevent the next drift

## Objective
Turn the first diverging step into an explicit project check.

## Checks
- Add a focused check on the step that diverged.
- Verify the checklist on a second real case.
- Document the scope limit you hit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:b8c94d25d487f57eebc7013cef0fbc7247e329bdffa7c5ad1b3f45f5a798a43b