How it verifies

A finder agent is optimistic by construction. Ask something to hunt for defects and it will find them, including ones that are not there. So nothing a finder produces is a finding yet - it is a candidate.

The refute panel

Each candidate faces N sceptics, and their brief is not “is this real?” but destroy this. It survives only on M of N votes. The shipped default is three sceptics, surviving on at least two.

The framing matters. A verifier asked to confirm will confirm; a verifier asked to refute has to do work to fail. Defaulting to “refuted when uncertain” is what keeps plausible-but-wrong findings out of your backlog.

Caution

A vote that never arrives is not a refutation. If the panel is incomplete, the candidate is marked UNJUDGED - never refuted, never quietly filed. “Two sceptics said no” and “one sceptic did not answer” must not read the same, exactly as elsewhere in the toolchain.

That distinction sounds pedantic until you have shipped on a quorum of one.

Perspective, not just repetition

Three identical sceptics catch a claim that is obviously wrong. They do not catch a claim that is wrong in a way none of them looks for. Where a finding can fail in more than one way, the stronger form gives each verifier a distinct lens - correctness, security, does-it-actually-reproduce - because diversity catches failure modes that redundancy cannot.

Loop until dry

Finders do not run once. Each is re-run until dry: it keeps going until two consecutive rounds produce nothing new.

A fixed number of rounds finds the obvious defects and stops. The interesting ones are in the tail, after the easy surface has been stripped - so the stopping condition is “nothing new twice”, not “we did three rounds”.

Candidates beyond the run’s cap are carried, not silently discarded. A run that hit its cap says so and says how many it carried, because a truncated sweep reported as complete is worse than no sweep.

The pre-flight cost gate

An audit can spend millions of tokens across hundreds of agents. Most harnesses only tell you a workflow was large after it has launched, which is too late to be a decision.

audit_cost.py --lenses 8 --rounds 2 --votes 3

It reports ~agents · ~tokens · ~minutes and a verdict:

• large - roughly 50 or more agents, or a million tokens and up. You see the estimate and the scope, and nothing fans out until you explicitly say go.
• small - a couple of lenses, one round. It just runs. The gate exists for expensive runs, not for every audit.

The seeds are calibrated against a measured reference run: 7 lenses produced 57 candidates across 192 agents, about 6.9M tokens, about 29 minutes.

And the estimate is measured against reality

audit_cost.py record --run-id RUN-xxxx \
  --lenses 5 --est-agents 50 --est-tokens 1000000 \
  --actual-agents 55 --actual-tokens 1200000

Estimates and actuals both go into a committed ledger, and the medians recalibrate the seeds. This is the same discipline the sprint forecast uses: a number that is never checked against what happened is not an estimate, it is a wish.

Note

An honest example from that ledger. One run estimated 209 agents and 7.5M tokens; it spent 282 agents and 14.26M - a 1.9x overrun, because 112 candidates turned up against an estimate of 64. The carry-over run that followed estimated 2M and spent 2.5M. Both rows are in the record, which is the only reason the seeds get better.

Where to next

• The six profiles - what gets asked in the first place.
• Audit overview - the pipeline, end to end.
• Two-role review - the same independence principle, applied to code review.
• Evidence - the measured numbers on this page, with their caveats.