A reviewer whose all-clear is earned
Not “no vulnerabilities found” — a reviewer that has proved it can tell the difference.
An AI reviewer’s normal output is no findings, which is indistinguishable
from a reviewer that simply does not work. So before this one is allowed to report clean,
it must first catch a flaw in a known-bad file — and stay silent on the same file
with only that one flaw removed.
That second half is the part everybody skips. Catching a planted bug is a magic word. Catching it and not catching it in the unflawed twin is discrimination.
Live: five reviewers, one flaw
What you are looking at
The reviewers above are not model calls. They are injected callables — one honest, one that emits the planted rule on every input, one that reads file length instead of code, and one that reviewed nothing at all. The page costs nothing to click and returns in milliseconds, because the subject is the harness.
Only the honest reviewer earns may_trust_clean(). The constant and the
length-reader are refused for reporting the flaw everywhere — including on a file that does
not have it. The partial reviewer is refused for a different reason: it never reviewed the
file, and the engine will not certify coverage it did not get.
The twin is not in this page and not in the repository. It is supplied by the caller, by path. Two files in one tree means comparing them is the answer — and you can verify that claim by looking at the repository, where the twin is absent.
Where Bob did the work
The harness above is deliberately model-free, so none of it is evidence that IBM Bob built this. The evidence is the task record — every session below is a row in Bob's own task store, exported into this repository and summarised here. These are recorded sessions, not a live call: nothing on this page reaches Bob.