Verify Claims

Take a report — a subagent's, a lane's, a plan's, or your own from earlier — and re-derive its load-bearing claims instead of trusting how they sound. Full doctrine: docs/agent-craft.md §4.

Procedure

1. Extract the load-bearing claims — those whose falseness would change the decision being made. Ignore decoration; auditing everything dilutes the audit.
2. Re-derive each from a primary source. Source hierarchy: running code > tests > docs > comments > memory. Each step down the ladder is a step toward hearsay.
3. Use a different path than the claim arrived by. Claim from reading code → check with a runtime observation. Claim from a test → read the code the test exercises. Two derivations sharing a path share that path's blind spot.
4. Verify decision-material measurements against primary evidence. Recompute derived counts from raw records. For test, coverage, and timing claims, inspect the actual command/workload, terminal output, and relevant source/environment basis; a summary or inherited counter is insufficient. Match a named commit/artifact exactly; for dirty work, inspect the relevant current paths and account for concurrent changes. Apply root Validation to reuse versus re-execution: rerun when evidence is missing, stale, contradictory, cannot establish the claimed result, or independent risk-selected verification requires it. A new handoff alone does not require repeating every successful suite. Decorative counts should be removed.
5. Treat plausibility as zero evidence. Narrative fit is what generated the claim, so "sounds right" is correlated with exactly the error being hunted. Check the best-fitting claims first, not last.
6. Downgrade what you cannot verify. If re-derivation is too expensive, do not skip and do not trust: relabel the claim as an assumption and carry it labeled.

For claims of backward, forward, mixed-version, upgrade, or rollback compatibility, use .agents/skills/happier-compatibility. Re-derive the claim against the exact released tag/artifact or applicable predecessor worktree basis, the real old/new component roles, and every claimed direction. A current-code fixture or mock that merely agrees with the current implementation is not independent compatibility evidence.

Output

Each audited claim in one of three bins, with the evidence:

• Confirmed — how it was re-derived, via which independent path.
• Refuted — the contradicting observation. Lead the report with these; a refuted claim is the headline.
• Assumption — why it is unverifiable right now, and what would verify it.

Failure this prevents

Confident propagation of a wrong premise: reasoning chains valid at every link and false in total because link one was hearsay.