Skip to content

V.E.R.I.F.Y. verification protocol

Validate intent · Examine output · Run tests · Inspect side-effects · Fact-check sources · Yield decision

V.E.R.I.F.Y. is the protocol the developer runs before accepting AI-generated code into a working branch. It is paired with S.C.A.F.F.: the prompt makes a draft cheap, the protocol makes acceptance safe.

It is not a code review process. Code review (see C.L.E.A.R.) happens when someone other than the author looks at the result. V.E.R.I.F.Y. is the author's check, before anyone else sees it.

From the framework's principles

"AI-generated code does not get a presumption of correctness." Philosophy: Verify before trust

When to use V.E.R.I.F.Y.

Always. The depth depends on the risk classification of the system and the change:

Risk tier Depth Time budget
Low (typo, comment, log line) 30-second VERIFY < 1 minute
Medium (Tier Low/Medium systems, non-critical paths) Standard VERIFY 5–10 minutes
High (Tier High systems, security-sensitive paths) Standard VERIFY + S.E.C.U.R.E. 15–30 minutes
Critical (Tier Critical systems, payments, identity, regulated data) Full VERIFY + S.E.C.U.R.E. + paired review 30+ minutes

The mapping from risk tier to verification depth is the contract that governance enforces. The framework's risk matrix is what tells you which column you are in1.

The 30-second VERIFY (trivial changes)

For changes that cannot plausibly affect behavior (comment edits, log line text, dead-code removal that the diff makes obvious) the protocol collapses to three quick questions:

  1. Did it do what I asked, and only what I asked?
  2. Did the test suite pass unchanged?
  3. Am I willing to put my name on it?

If any answer is "no" or "not sure," escalate to standard VERIFY.

The standard VERIFY (most changes)

V. Validate intent

Re-read the prompt and re-read the diff side by side. Ask:

  • Does the diff match what the prompt asked for, and only that?
  • Did the model add anything you didn't ask for? (A new dependency, a refactor of adjacent code, a "while I was here" change.)
  • Did the model not do something you asked for? (Silent omission is more common than silent addition.)

Drift between intent and output is the single most common AI-defect shape. Catch it here, not in review.

E. Examine output

Read every changed line. Not skim; read.

  • Do you understand each line? If not, you cannot own it.
  • Does the structure fit the codebase, or did the model produce an out-of-style island?
  • Are the names sensible? AI-generated names tend toward generic (process_data, handle_event); rename for the codebase.
  • Is there anything that looks like a placeholder, a stub, or a "TODO" the model invented? Treat them as bugs, not breadcrumbs.

If the diff is too large to read carefully in the time available, the diff is too large. Split the prompt next time.

R. Run tests

  • Run the existing test suite, locally if possible, before the diff leaves your machine.
  • Run the new tests the model produced (if any). Models routinely produce tests that pass against the model's own output and fail against the actual contract. If a new test only confirms what was already obvious from the diff, write a real one.
  • For every changed function, ask: what test is missing? Models generate tests for the happy path; edge cases and error paths are consistently under-tested.

If you skipped this step because "it looks right" and "CI will catch it," stop. CI catches a fraction of the defects that local verification catches, and catches them later when context-switching is expensive.

I. Inspect side-effects

Things that are not in the diff but might be affected:

  • Database: did the change introduce a new query pattern? An N+1? An index requirement?
  • Network: new outbound calls? New endpoints? Cross-region traffic?
  • Filesystem: new files written? Temp files cleaned up?
  • State: globals, caches, singletons touched?
  • Concurrency: new locks, new threads, new async boundaries?
  • Configuration: new env vars, secrets, feature flags?

Models do not reason reliably about side-effects because side-effects are not in the local context the model can see. The author has to.

F. Fact-check sources

If the model cited an API, a library, a standard, or a paper:

  • Open the documentation and confirm the function exists with the signature claimed.
  • Check the version. Models have training cutoffs; an API that existed in v3 may have moved or been removed in v5.
  • Check license compatibility if a new dependency is proposed.
  • If the model produced a regulatory or compliance assertion ("this is GDPR-compliant", "this satisfies PCI DSS 4.0"), do not accept it without a primary source. Models hallucinate regulations with the same confidence as code.

A 30-second documentation check here saves hours of debugging later.

Y. Yield decision

Make the accept / revise / reject decision explicitly. Do not default-accept by silence.

  • Accept: the diff matches intent, you understand every line, tests pass, side-effects are accounted for, sources check out. Apply.
  • Revise: send the model back with a sharper S.C.A.F.F. prompt citing the specific problem. Do not patch the model's output by hand if a better prompt would produce a cleaner draft.
  • Reject: the model is not the right tool for this change. Write it yourself. This is sometimes the right answer, especially for highly idiomatic codebases or unusual constraints.

Record the decision in the commit message or the PR description. "Used S.C.A.F.F. + V.E.R.I.F.Y., one revise round" is more useful in six months than no record at all, and is auditable evidence for higher-tier systems.

How VERIFY composes with the other practices

graph LR
    P[S.C.A.F.F.<br/>prompt] --> D[draft]
    D --> V[V.E.R.I.F.Y.<br/>author check]
    V -- security-sensitive --> SE[S.E.C.U.R.E.<br/>security check]
    V --> C[commit]
    SE --> C
    C --> R[C.L.E.A.R.<br/>reviewer check]

V.E.R.I.F.Y. is the author's check. S.E.C.U.R.E. is invoked when the diff touches sensitive surface area. C.L.E.A.R. is what the reviewer does next. Each catches different defect classes.

Sizing guidance

Sizing guide

  • Small (< 50). Standard VERIFY for everything that touches production code; 30-second VERIFY for typo-class changes. Skip formal recording; use commit messages.
  • Mid (50–500). Document the depth-by-tier mapping in the AUP. Add a PR-template line ("Verification depth applied:") so the reviewer knows what was checked already.
  • Enterprise (500+). Tie verification depth to the risk classification programmatically; pre-commit checks or CI labels enforce Enhanced/Critical paths.
  • Regulated. Verification evidence (which checks ran, which sources were fact-checked) is part of the audit trail. Critical-tier changes require dual sign-off, not single-author VERIFY.

Common verification failures

Failure What it looks like Fix
Confidence over-rides verification "It looks right" without reading every line Read every line. No exceptions on Tier High/Critical.
Test theater New tests pass but only re-assert what the model wrote Write the test from the contract, not the implementation
Missed side-effect New DB query, new outbound call, new env var slipped past Add side-effect inspection to the PR template
Hallucinated source Cited API or regulation does not exist Open the doc; if no link, no citation
Silent omission Asked for X+Y, got X only, didn't notice Read the prompt and the diff side by side, every time

Anti-patterns

Don't

  • Don't trust confidence. Models produce confident, fluent output regardless of correctness. Confidence is not a verification signal.
  • Don't skip tests because "it looks right." Looks-right is the most common precursor to a production incident.
  • Don't accept cited APIs, libraries, or regulations on the model's word. Open the documentation. If the citation can't be found, the claim does not stand.
  • Don't collapse VERIFY into "I read the diff." Reading is one of six steps. The other five catch defect classes that reading misses.
  • Don't VERIFY a diff so large you can't read every line. The diff is too large; the prompt was too large; split it and reprompt.

Next

  1. Google Cloud / DORA, "2024 Accelerate State of DevOps Report", Oct 2024. Found that AI-tool use correlated with throughput and stability drops without proportionate verification practice. [primary] ↩