# Verification Budget

**Purpose:** Require sufficient verification while prohibiting compulsive reassurance repetition and equivalent checks without new evidence.

Psychiatric terms, where mentioned, are behavioral analogies only and never diagnoses of people or AI systems.

## Trigger

A required condition needs proof, previous proof may be stale, or checks repeat after valid unchanged evidence.

## Mandatory control

1. Map each acceptance condition to the smallest sufficient proof.
2. Run targeted proof before broader required gates.
3. Record command, scope, result, and source state.
4. Check whether later relevant change invalidated proof.
5. Reject equivalent reruns when proof remains complete and current.
6. Mark verification sufficient and move to the next condition or completion.

## Limits

At most two equivalent verification passes without relevant change; repository mandatory gates still apply.

## Evidence

Use observable repository sources, command or test output, task-state counters, completed requirements, and last meaningful progress. Store conclusions and results, never chain-of-thought.

## Escalation

Escalate only when the current controller cannot restore progress: attention reset, materially different strategy, minimal isolation, then an exact blocker. Recovery must reduce branches and assumptions.

## Forbidden behavior

Do not rename commands, switch runners, or recursively inspect unrelated code for reassurance. Necessary verification is not optional.

## Deep guidance

Read [Verification Budget guide](../guides/compulsive-verification.md) only when this rule triggers. Keep ordinary boot context small.

## Stop condition

Every required condition has current sufficient proof or one exact missing proof is named.

