Verification Gate: Fail-Closed Design

"A gate that breaks silently is worse than no gate."

Overview

A verification gate that silently passes when the verification tool breaks is not a gate—it's a security vulnerability.

Core principle: Verification tools can fail. When they do, you must mark results as UNVERIFIED and report the failure clearly. Silent pass-through creates false confidence.

Violating the letter of fail-closed design is violating the spirit of safety.

When to Use

• Building orchestrators, pipelines, or gates that check work before marking it complete
• Integrating verification tools (OCR validators, cross-model checkers, fact-check services)
• Any place where "tool passed" becomes a claim in a manifest, report, or downstream decision
• When tool failure (network error, timeout, API limit, parsing failure) is possible
• Marking batches or manifests as "verified" based on tool output

When NOT to use:

• Simple linear validation (if [check], then [proceed]) - use error handling instead
• Verification where tool failure causes immediate hard stop (use try/catch + propagate error)
• Cases where unverified results cannot flow downstream

---

The Gate Function (5 Steps)

BEFORE marking any output as "verified" or "passed":

1. INVOKE: Call verification tool with full context
2. WAIT: Let tool finish completely (no timeouts before completion)
3. PARSE: Extract result AND error codes/messages (not just final status)
4. DECIDE: 
   - If tool succeeded: Mark as VERIFIED + record evidence
   - If tool failed: Mark as UNVERIFIED + record failure reason
5. REPORT: Always distinguish verified/unverified/skipped/failed in output

Skip or hide any step = hidden vulnerability, not efficiency

---

Red Flags — STOP

Watch for these patterns when designing gates.