Ask a model whether it finished the job and it will usually say yes, fluently and with conviction. That answer is worth very little on its own, because a model's confidence is a property of its writing style, not of the world. The fix is not a better-worded prompt asking it to be sure. The fix is to verify outcomes outside the model, against checks it cannot talk its way around. This is the shift from confidence to proof, and it is what lets an agent's actions be trusted.

Confidence is not proof

Language models are trained to produce plausible text, and plausible often reads as confident. But fluency and correctness are different things. A model can explain, in convincing detail, a fix that does not actually work, a query that returns the wrong rows, or a change that breaks a test it never ran.

So the question a dependable system asks is never did the model say it is done. It is can something other than the model demonstrate that it is done. That something is an external check: a test, a scan, a schema validation, a policy evaluation, or a measured acceptance criterion.

The claim and the proof

Picture two sets. One is everything the model claims to be true or complete. The other is everything that has been independently proven. The only region you can safely act on is where they overlap. A claim without proof is a hope; a proof without a claim is just a check that has not been connected to a decision yet.

The goal of verification is to grow the overlap: to make sure that before an action fires, the claim behind it sits inside the proven region, not outside it.

Only where the model's claim overlaps independent proof is an action dependable. Claim vs Proof Model claims self-reported Proven true checked outside Dependable act here
Only where the model's claim overlaps independent proof is an action dependable.

Verify outside the model

External verification means the check runs in something the model does not control and cannot persuade. If the agent claims a bug is fixed, a test suite or a scanner should agree before the fix is accepted. If it claims a record was updated, a read-back should confirm the new value. If it claims an output is safe, a validator should pass it, not a sentence promising it is fine.

The discipline is to attach a concrete, runnable check to every consequential claim, and to treat the check, not the claim, as the source of truth.

  • Tests and builds for code changes, run to green, not described.
  • Scanners and validators for safety and correctness of outputs.
  • Read-backs and schema checks to confirm state actually changed.
  • Policy evaluation to confirm an action was allowed, not just attempted.

A verification lifecycle

Verification is a small state machine the runtime owns. A proposed result starts unverified. It moves into checking while external checks run. If they pass, it becomes verified and may be acted on; if they fail, it is rejected and sent back for revision, never quietly accepted.

Making these states explicit prevents the most common failure: a result that was never actually checked slipping through as if it had been. Nothing reaches verified without passing the checks, and nothing acts before it is verified.

A result is only acted on once external checks move it from checking to verified. Verification States Proposedunverified Checkingchecks run Verifiedmay act Rejectedrevise run checks passed failed revise
A result is only acted on once external checks move it from checking to verified.

Measurable acceptance criteria

Verification only works if done is defined as something you can measure. A finding is closed when the scanner no longer flags it, not when the model says it addressed it. A change is accepted when the tests that guard it pass, not when it looks right. Replacing soft language with a measured threshold is what makes the check meaningful.

The gap this exposes is often uncomfortable and always useful: a model's self-rated completeness routinely sits far above the fraction that actually passes independent checks. That gap is exactly the risk external verification exists to catch.

A model's self-rated success usually sits well above the share that passes real checks. Said vs Proven Model says done 95% Tests pass 62% Scans clean 78%
A model's self-rated success usually sits well above the share that passes real checks.

When verification fails, escalate

A failed check is not a dead end; it is a signal. The runtime should route a rejected result back for another attempt within limits, and escalate to a human when checks keep failing, when the action is irreversible, or when the evidence and the claim disagree. Escalation tied to risk is how verification stays safe without grinding to a halt.

The point is that failure becomes visible and handled, rather than silently overridden by a confident-sounding retry.

✅
Proof over persuasion. Accept an action when an independent check passes, not when the model argues convincingly that it should.

What a practitioner decides

External verification turns squishy trust into concrete engineering. The decisions: which claims require proof, what runnable check proves each one, what measured threshold counts as done, and when repeated failure escalates to a human.

Make the check the source of truth, and the model becomes free to be creative precisely because nothing it merely asserts can act without being proven first.

Key takeaways

  • A model's confidence reflects its writing, not the world; treat it as unverified by default.
  • Attach a concrete, runnable check to every consequential claim and trust the check, not the claim.
  • Run verification outside the model, in something it cannot persuade or control.
  • Model verification as explicit states so nothing unchecked slips through as if verified.
  • Define done as a measured threshold: scanner clean, tests green, state confirmed.
  • Treat a failed check as a signal to retry within limits or escalate by risk, never to override.

Glossary

External verification
Confirming an outcome with a check that runs outside the model and cannot be talked around.
Acceptance criteria
The concrete, measurable conditions that must hold before a result is considered done.
Read-back
Re-reading a record after a change to confirm the new value actually took effect.
Policy evaluation
A deterministic check that an action was permitted under the rules, independent of the model's intent.
State machine
A model of the distinct states something can be in and the transitions allowed between them.
Escalation
Routing a decision to a human when checks fail repeatedly, the action is irreversible, or evidence conflicts.
Regression test
A check that confirms a previously working behavior still holds after a change.