The Verification Loop: Evidence Before Confidence

“It looks right” is not a test. It is a first impression. A change can look perfect in one viewport while breaking a keyboard path, an asset URL, a cache rule, a second page, or the production build. The verification loop exists to close that gap without turning every small change into a ceremony.

The loop has five moves: name the claim, establish the baseline, test the behaviour, scan the blast radius, and inspect the rendered result. Each move answers a different question. Together they turn confidence into evidence.

§1Name the claim

Before testing anything, write down what is supposed to be true. Keep it concrete enough to fail. “Improve the page” is not testable; “the first screen remains visually unchanged while scrolling and interaction work use less main-thread time” is.

PATTERN — ONE SENTENCE, ONE FAILURE MODE

State the outcome, the surface it applies to, and what must stay unchanged. If the sentence cannot be disproved, it is not yet a useful claim.

a compact acceptance contract

OUTCOME
The interaction feels immediate on desktop and touch devices.

SCOPE
The public page and its shared assets.

MUST STAY TRUE
The content, visual hierarchy, keyboard path, and URLs do not regress.

EVIDENCE
Build passes; browser checks pass; performance stays inside budget.

§2Establish the baseline

Measure before editing. A baseline does two jobs: it tells you where the problem actually is, and it prevents a later “improvement” from being judged against memory. Capture only what the claim needs — a metric, a screenshot, a response header, a link count, or the current behaviour of one interaction.

For performance: record the same device profile, throttling, route, and run conditions.
For layout: capture representative desktop and mobile widths.
For behaviour: write the exact action and the expected response.
For content: record the public source that owns the fact.

A baseline is not a giant audit. It is the smallest reliable “before” picture.

§3Test the narrow behaviour

Start with the exact thing that changed. Build the project, run the closest automated check, then exercise the interaction in a real browser. This catches syntax and logic failures early, while the context is still small.

01 · NARROW PASS

Prove the edited path first

Run the production build, not only the development server.
Run the smallest relevant automated check.
Open the exact route in a real browser.
Use the feature with pointer, keyboard, and touch assumptions in mind.
Check the console and network panel for silent failures.

If the narrow pass fails, stop there. Expanding the test surface before the changed path works only produces more noise.

§4Scan the blast radius

Most regressions happen one layer away from the edited file. A shared stylesheet touches every page that imports it. A renamed asset touches the page, the cache version, the social image, and perhaps a security rule. A content page touches navigation, sitemap, structured data, and internal links.

Ask one question: what else consumes the thing I changed? Then verify those consumers, not the whole universe.

BLAST-RADIUS CHECK

Search for every reference to the changed asset, selector, route, field, or identifier. Confirm that all consumers either move together or intentionally stay put. One producer and one forgotten consumer is the classic “worked locally” bug.

↑ contents

§5Inspect the rendered result

Source code is not the product. The browser, generated output, deployed headers, and actual network responses are. Finish the loop on the rendered surface:

Compare desktop and mobile screenshots at the same dimensions.
Follow every newly added link and confirm the final status and destination.
Check heading order, focus visibility, tap targets, and overflow.
Re-run the same performance profile used for the baseline.
If a preview exists, verify the preview URL rather than assuming the local build represents it.

The last check should answer the original claim directly. If the claim was about lag, report interaction and rendering evidence — not a list of files changed.

§6Leave a state packet

A good verification loop ends in a handoff another person or agent can resume without reconstructing the whole session. Keep it short and factual.

the five-line handoff

OUTCOME: what is now true
CHANGED: the surfaces that moved
VERIFIED: the checks and evidence that passed
OPEN: anything deliberately left unresolved
NEXT: the safest useful continuation

Do not turn the handoff into a diary. The next run needs current state, evidence, and a clear next move.

§7Know when to stop

A loop also needs hard stop conditions. Stop and report instead of improvising when the source of truth conflicts with the requested change, when the working surface contains unrelated edits, when a check cannot be run honestly, or when the next step would publish beyond the agreed scope.

This is not hesitation. A stop condition prevents confidence from outrunning authority.

Steal this

Turn the request into one falsifiable claim before editing.
Capture the smallest reliable baseline.
Prove the changed path before widening the test surface.
Scan consumers of the changed asset, selector, route, field, or identifier.
Finish on the rendered output, not the source file.
Leave a five-line state packet and explicit stop conditions.