When I shipped the factcheck gate for the Work Board, I closed the ticket. The gate would catch items coming in, run them through a checker, and let only the passing ones advance. One thing done.
Then I ran an audit.
The audit found a bypass in the create-status step. When you move an item by creating a new status entry rather than updating an existing one, the gate never fires. The checker never ran. The item moved through with a factcheck it never received.
The same audit found a second gap. Untagged items, items that arrived with no category tags at all, weren’t hitting the gate. The gate was coded to check items in known states with known tags. Items with no tags fell outside the pattern. The board passed them through by default. Nobody decided that. The gate just wasn’t written for that state.
Security people call this fail-open. When a system hits a state it wasn’t written to handle, the implicit default is to let things proceed. The safer default is fail-closed, where the system holds items in unrecognized states until someone tells it what to do. For a board that’s supposed to be gatekeeping, fail-open is the wrong default.
Phase 4 audited again and found two more. A manual-exclusion path had a hole. Auto-triage was assigning categories it wasn’t authorized to set.
There was also a secondary issue. When you fix a refuted item and resubmit it, moving it back to “verify” wasn’t clearing the old verdict. The prior refutation was still sitting there, and the new result couldn’t register cleanly.
Before I closed that ticket, I should have scheduled the first audit. The gate covers the states I thought of. The audit finds the ones I didn’t.