output_verification v1.0.0

name: "output_verification" description: "Verify an agent's outputs before delivery: calibrated confidence scoring, source-hierarchy claim checks, self-challenge contradiction detection, and risk-based human gates. Use before shipping any agent-produced answer, report, recommendation, or plan where being wrong has a real cost."

Output Verification

Purpose

Agents ship fluent, confident outputs by default. Fluency is not evidence. This skill is the pre-delivery discipline that turns "the model said it confidently" into "the claim survived verification." It gives you four mechanics that combine into a gate decision: triage by risk, challenge by self-attack, verify by source hierarchy, and calibrate confidence honestly.

Workflow

Run these in order. Stop early only at the risk tier's exit gate (step 1); never skip a tier's required checks.

1. Triage by risk

Classify the output before spending effort. Three tiers:

| Tier | What it covers | Cost of being wrong | |---|---|---| | Low | Internal scratch, drafts, brainstorming, reversible suggestions | A few minutes of redo | | Medium | User-facing summaries, recommendations, code review notes, published-but-correctable content | Reputation damage, rework, misled decisions | | High | Money movement, legal or medical claims, irreversible actions, anything published under someone else's name, security decisions | Real harm |

Effort follows risk: Low gets a skim of step 2 only. Medium gets steps 2 and 3. High gets all four steps and a human gate (step 5).

2. Self-challenge (the premortem move)

Assume the output is wrong, then explain how. Gary Klein's premortem research (HBR, 2007, building on Mitchell, Russo & Pennington 1989) shows imagined hindsight surfaces failure reasons that forward-looking "what could go wrong?" misses.

• For each load-bearing claim (a claim the conclusion depends on), write the strongest specific case that it is false. Generic skepticism does not count. "The data might be wrong" is nothing. "The API doc I cited was for v2 and the deploy runs v3, which renamed this endpoint" is a challenge.
• Re-derive the answer from a different angle: a different method, a different source family, or the strongest counter-argument. If the two routes disagree, the output is not shippable until you know why.
• Check internal consistency: do any two claims in the output contradict each other, or contradict context you already hold (files, prior tool results, the user's stated facts)? A self-contradiction is a defect, not a hedge.

3. Source hierarchy and lateral checks

Every factual claim gets an evidence grade based on where it came from, strongest first:

1. Primary: official docs, standards bodies, raw data you fetched, tool output you actually saw.
2. Secondary: reputable reporting or analysis citing a primary source.
3. Model memory: anything the model "knows" without a live check. Treat as unverified until corroborated.

Verification moves (adapted from Mike Caulfield's SIFT method):

• Investigate the source. Who published it, and do other credible parties treat them as reliable? Read laterally: leave the page and see what the rest of the web says about the source.
• Find better coverage. For high-stakes claims, require a second independent source that is not quoting the first.
• Trace to origin. Follow citations back until you reach the primary source or hit a dead end. AI outputs are fluent with provenance blended out; citations that do not exist, do not say what is claimed, or are misattributed are one of the most common failure modes. A traced dead end downgrades the claim to opinion or cuts it.

Apply the consistency-sampling test (the SelfCheckGPT pattern, Manakul et al., EMNLP 2023) to anything you cannot verify externally: ask the same question 3 times in fresh contexts and compare the facts. Consistent facts across samples are probably stable knowledge. Facts that drift or contradict across samples are probably fabricated. Drift is a red flag even when each sample sounds confident.

4. Calibrate confidence honestly

Score confidence per claim, not per answer. One wrong load-bearing claim sinks the whole output.

• Verbalized confidence ("I am 85% sure") is better than gut feel but systematically inflated in RLHF-tuned models (Tian et al., EMNLP 2023: verbalized scores beat token probabilities, cutting expected calibration error roughly in half, but the model still overstates). Shrink your stated confidence on anything important: a felt 90% is closer to 60-70% until you have a personal track record.
• Run the P(True) check (Kadavath et al., Anthropic): re-read your answer and ask "Is this answer correct?" as a fresh True/False judgment. If the honest answer is not a clean True, your confidence was inflated.
• Keep a personal calibration habit: when a verified outcome exists (a check resolved, a human confirmed), compare it to what you claimed. Over many runs this is the only real calibration there is.

See references/calibration-notes.md for the research backing and worked examples.

5. Risk-based gate decision

Combine risk tier and honest confidence into a decision. Use bin/gate_decide.py for the mechanical version:

| Risk \ Confidence | High (verified) | Medium (one source) | Low (unverifiable) | |---|---|---|---| | Low | Ship | Ship | Ship with caveat | | Medium | Ship | Ship with caveat | Re-verify or downgrade to opinion | | High | Ship, still disclose key evidence | Human gate | Human gate or abstain |

Hard rules:

• High tier never ships on model memory alone. If no primary source exists and no human is available, abstain or ship with explicit uncertainty, never with fake confidence.
• A failed self-challenge is a defect, not a footnote. Fix it or downgrade the claim.
• "Passed verification" means "no defects found at this effort level." It is not a guarantee of truth. Say which level you ran.

Output Contract

Every verified output ships with a short verification note (a few lines, or a comment block for code):

Verification: risk=<low|medium|high>
Checks run: self-challenge, source-hierarchy, consistency-sampling (as applicable)
Claims: N total, N verified to primary, N to secondary, N unverifiable (downgraded to opinion)
Confidence: <per load-bearing claim, calibrated>
Decision: ship | ship-with-caveat | human-gate | abstain
Residual risk: <what could still be wrong, in one line>

If the human gate fires, the note is addressed to the human with the specific question that needs their judgment, not a vague "please review."

Operating Rules

1. Unverifiable = cut it or frame as opinion. Never invent numbers, dates, quotes, or events to make a claim shippable.
2. Every factual claim must trace to a real check you ran. Tool output you only half-read does not count.
3. Do not cite a source you did not open. A search-result snippet is not a source.
4. The gate decision is binding inside this run: if it says human-gate, you stop and hand off. You do not re-run the checks hoping for a better mood.
5. When search or tools fail, say so plainly and downgrade accordingly. Missing evidence is never treated as confirming evidence.
6. Write like a person: plain, direct, no hype. Verification notes report facts, not inspiration.