Match Code Review Evidence to the Claim

Code reviews become confusing when evidence is presented without saying what it proves. A screenshot can show a layout. A unit test can establish behavior under controlled inputs. A deployment log can show that a platform accepted an artifact. None of these automatically proves the others.

Begin the review by identifying the claims made by the change. Then ask what evidence supports each claim.

Separate implementation from behavior

Reading the code can confirm that a branch exists or a permission check is called. It may not reveal whether the user reaches that branch in the real flow. A focused test or reproduction can connect the implementation to the trigger.

Conversely, a single successful click does not establish that every authorization path is correct. The appropriate evidence depends on the failure modes being considered.

Inspect the consumer

When an interface changes, review at least the relevant caller and callee together. A response field that looks correct in the server can still be misread by the client. A renamed prop can compile in one package while another consumer relies on the old name.

The review boundary should follow the contract, not stop at the edited file.

Interpret test results narrowly

A passing suite means the executed checks passed in that environment. It does not establish coverage of a scenario that the suite never exercises. Ask whether the test would fail for the reported bug and whether its setup resembles the relevant state.

Avoid adding a test that merely repeats the implementation’s calculation. Prefer an assertion at a meaningful behavior boundary.

Keep live claims separate

If the change is deployed, verify the revision and the affected action in the target environment. Local success cannot establish which revision is running elsewhere.

When live verification is unavailable, say so. “Implementation reviewed and local checks passed; deployment unverified” is a useful handoff. It does not need an optimistic final sentence that erases the limitation.

Write findings with consequences

A useful review finding names the trigger, the faulty behavior, and the consequence. Include enough location detail for the author to act, then explain the smallest correction or the contract that needs clarification.

Evidence makes a review more than an opinion exchange. Matching it to the claim keeps both approval and criticism proportionate to what was actually observed.