Great question — yes, false negatives happen, and the design accepts them deliberately. The auditor's verdicts distinguish unverified (evidence not found where it looked) from unmet, so the case you describe surfaces as the auditor's limitation and costs one round trip to resolve: point at the evidence, re-check. That asymmetry is intentional — a false "not done" costs a round trip; a false "done" corrupts the gate itself. The direction we actually had to iterate on was the opposite: the auditor trusting records produced by the loop it audits (ledgers, checklists). The fix was an evidence hierarchy — "satisfied" may only be grounded in primary evidence (reading the actual code/statements, running the checks), and one mismatch between a record and reality disqualifies that whole document as evidence. Your instinct is right: the auditor went through the same iteration as the loop — several discipline waves, plus an adversarial review that found fail-closed gaps in the auditor itself. The current rules are here if you want the details: prd-loop (https://github.com/iroha1203/AlgebraicArchitectureTheoryV2/blob/main/.codex/skills/prd-loop/SKILL.md)