Block vs. detect: fail-open and fail-closed paths
The Verification Engine can either block a bad model response before it reaches your caller (fail-closed) or log it while still delivering the response (fail-open). Which behavior applies depends on the route the request travels through, so you can enforce on your critical paths while safely observing new ones during rollout.
The two behaviors
- ▸Fail-closed (block): The response is verified synchronously. If it violates a constraint, it is rejected and the caller receives an error instead of the bad output.
- ▸Fail-open (detect): The response is verified and the result is recorded, but the response is still delivered. Nothing is blocked — this is observe-only mode.
Every verification result is stored for audit and analysis in both modes, so you get the same visibility whether or not a route is enforcing.
Which routes block by default
Your highest-risk paths are fail-closed out of the box:
- ▸AI Gateway routes (LLM completions and chat proxied through G8KEPR)
- ▸MCP routes
On these paths, output that fails verification is blocked synchronously — it never reaches the end user or downstream tool.
Which routes only log by default
All other verified routes are fail-open by default during rollout and are configurable per path. This lets you turn on verification, watch what it would have blocked, and confirm your constraints are tuned correctly before you flip a route to fail-closed.
Start any new route in fail-open, review the recorded results, then switch it to fail-closed once the block rate looks right.
What each verdict does
When a response is verified, the highest-priority action across all your constraints wins:
- ▸Allow — the response is compliant and delivered.
- ▸Warn — the violation is logged, and the response is still delivered.
- ▸Suggest — the response is blocked and a proposed compliant alternative is returned.
- ▸Block — the response is rejected and the caller receives an error.
A single Block overrides any Suggest or Warn on the same response.
What happens on a timeout
If verification cannot finish in time, the direction of the failure follows the route's risk level:
- ▸High-risk paths fail closed — the response is blocked.
- ▸Low-risk paths fail open — the response is delivered.
Fail-open records a violation only *after* the response has already been delivered, so it does not stop bad output in-line. Use fail-closed on paths where blocking matters, and reserve fail-open for rollout and low-risk paths.
To review what verification is catching, see Reviewing verification results.