Home / Checking what it gives back
The remedy against invention can invent too
A verification device is a deliverable like any other, produced by the same kind of mechanism as what it checks: replaying that mechanism a second time does not make it independent, only a genuinely different method proves it.
A verification device, script or agent, is a deliverable like any other: it is produced by the same kind of mechanism as what it checks, and nothing exempts it from the risk it is supposed to cover. A check that returns a reassuring verdict has proven nothing more than a check that returns a worrying verdict, until its own method has been put to the test in a genuinely different way.
Replaying is not verifying
Running a check a second time feels like confirmation. It is not, as soon as the bug is deterministic: the same code, on the same input, produces the same error twice, and agreement between the two passes only proves the bug is stable, not that it is absent. A script written to count occurrences of the field name ADMIN_PASSWORD in a configuration file, through a case sensitive substring search, returns a single occurrence on the first run, then a single occurrence again on the second.
node compteA.js fixture.txt
occurrences trouvees : 1
node compteA.js fixture.txt
occurrences trouvees : 1The checked file nonetheless contains two lines that affect this password, one written in capitals, the other in lower case. The repetition reassures without adding anything: it is a different method, not a second run of the same method, that changes the result. A second script, built differently, splits each line on the equals sign and compares the resulting field name in lower case, rather than searching for an exact substring.
node compteB.js fixture.txt
occurrences trouvees : 2Two instances of the same mechanism are not independent
This confusion shows up on a larger scale with an agent tasked with reviewing another agent. Two models, even under different names, often share the same training blind spots: their agreement is not proof of a truth, it is proof of a similarity of method. The independence that matters is not that of the instance, a second run, a second AI of the same kind. It is that of the method: a different counting algorithm, a manual reading of a sample, a source that was not produced by the device being checked.
The practical rule comes down to one question, asked before trusting any check verdict: does this second result come from a method that could fail in a different way, or only from the same method replayed. In the first case, the agreement counts. In the second, it proves nothing more than the first run.
This principle carries on from test the checker before trusting its verdict: a self test with a known case is enough to spot a broken check, but only a genuinely different method then lets you trust a check that already seems to work. It also ties back to a green result proves nothing until it has itself been proven: a positive witness proves a check can detect, a second run of the same check never proves it twice.
Replaying the same check, or changing method
The same script runs a second time on the same input, with the same bug: the result does not move, it confirms its own error without learning anything new.
A second mechanism, built differently, runs on the same input: the gap between the two results reveals what the first method could not see on its own.
A script searches for the field name ADMIN_PASSWORD in a file through a case sensitive substring search. It runs a first time and counts one occurrence. It runs a second time on the same version of the file and the same version of the script, and again counts one occurrence.
Write, in one sentence, what this result establishes, and in one sentence what it does not establish.
What this establishes: The second run confirms the result returned by this precise method is stable, run after run.
What this does not establish: It does not establish that this count of one occurrence is the correct count, since the same method, replayed identically, cannot reveal an error it was already making on the first run.
The three most common miscalibrations
- Too broad The two identical runs confirm that the count of one occurrence is exact and complete.
- Too narrow Two identical runs give no information at all, not even about the stability of the method used.
- Beside the point The two runs show that the script executes quickly on this file.
- A verification device is produced by the same kind of mechanism as what it checks, and is never exempt from the risk it is supposed to cover.
- A deterministic bug replayed on the same input, with the same method, produces the same error twice: agreement between the two passes proves nothing new.
- Two instances of the same kind of mechanism, two models or two runs of the same script, often share the same blind spots and do not verify each other.
- The independence that matters is that of the method, a different algorithm or an independent reading, never that of the instance running it.
Take an automated check you already use, and validate its latest verdict with a genuinely different method, another algorithm or a manual check on a sample, before continuing to trust it on an important case.