Verification Budget

---
name: verification-budget
description: Decide how much verification an AI agent's output actually needs based on real stakes, instead of checking everything or nothing. Use before trusting or shipping AI-agent output on a task with real consequences.
license: All-Rights-Reserved
metadata:
  author: Zain Haseeb
  version: 1.0.1
  changed: "2026-09-08"
  category: ai-delegation
  tags: [verification, agents, risk, delegation]
---

# Verification Budget

Allocate limited verification time by the material harm each check can prevent, not by difficulty alone. Cheap, decisive checks can deserve priority over expensive, weak ones.

## Critical behavior

1. Rate stakes using impact and reversibility together, not impact alone.
2. Fund mandatory checks for high-impact or irreversible consequences first, including easy checks. Then prioritize credible harm reduction per unit of review time.
3. Permit lighter or no verification only for low-consequence, reversible parts with a stated justification. Easy to check never means safe to skip.
4. Name a concrete check for each high-priority part: a source lookup, a test run, a second reader, a rendered preview, or a small-scale trial.
5. Never treat a confident-sounding output as evidence of correctness on its own.
6. State clearly what confidence level the completed checks actually support, and flag if the output overclaims beyond it.

## When to use

Use this before relying on or shipping work an AI agent produced, especially when the review time available is limited and cannot cover everything equally. It is most useful when a team is tempted to either rubber-stamp agent output because it looks polished, or review every line regardless of how little is at stake.

Do not use it for trivial, fully reversible, low-consequence output where any real verification effort is disproportionate to the risk.

## Build the budget

### 1. List the output's parts

Break the agent's output into distinct parts: claims, calculations, code changes, external actions, formatting, and so on.

### 2. Rate stakes per part

For each part, rate impact if wrong and how reversible that impact is. A high-impact but fully reversible part gets a different budget than a low-impact but irreversible one.

### 3. Rate check difficulty

For each part, estimate check time, plausible error likelihood, and which material failures the check can actually catch. Use qualitative ranges when evidence is weak; do not invent numerical probabilities or detection rates. A false claim buried in fluent prose may be hard to catch, while a quick recalculation can decisively catch a costly error.

### 4. Allocate the budget

Reserve the minimum decisive checks for high-impact or irreversible parts before allocating optional review. Rank remaining checks by plausible harm reduced per minute, using the stated uncertainty rather than false precision. If mandatory checks do not fit, hold the affected release, reduce scope, or obtain more qualified review time; do not silently dilute the checks.

### 5. Name the check method

For each funded part, name the specific check: a source lookup against a named reference, a test run, a second human reader, a rendered preview, or a small-scale trial before full commitment.

## Output format

Return a table with columns: output part, consequence and error likelihood, check effectiveness and uncertainty, mandatory or optional, time allocated, and check method. State what remains unfunded and the resulting hold or scope reduction. Follow it with the single check that would catch the most damaging plausible error and the confidence the checks actually performed support; a planned check is not completed evidence.

## Example

An agent drafts a customer-facing policy update and also reformats an internal spreadsheet. The budget allocates almost all available review time to the policy claims, which are high-stakes and hard to verify without a source lookup, and allows the spreadsheet reformatting, which is low-stakes and easy to visually confirm, to pass with a quick glance.

## Troubleshooting

- If every part looks equally high-stakes, the categories are too coarse; break the output into smaller parts and rate again.
- If review time is fixed and too small for the highest-stakes part, say so explicitly rather than distributing an inadequate check across everything.
- If a part cannot be verified at all within the available methods, mark it as unverified rather than giving it a light pass that implies it was checked.

## What not to do

- Do not verify every part equally regardless of stakes.
- Do not treat fluent or confident output as self-verifying.
- Do not claim a confidence level higher than what the completed checks support.
- Do not skip verification on an irreversible, high-impact part to save time.