Guardrails and AI Safety
Fail-closed Behavior — Stack
Fail closed behavior › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
This is assembled from general reliability machinery, so the question is which pieces can express "no verdict" as a distinct state rather than collapsing it into success or failure.
- Three-state support. Whether the client library and the call signature can return an explicit indeterminate result, or force a boolean.
- Timeout granularity. Per-check deadlines with a budget for the whole request, rather than one global timeout that the slowest check consumes.
- Degraded-mode distribution. Whether rules, models, and bundles can be cached locally with a declared maximum age, and what the component does when that age is exceeded.
- Instantaneous disable. How fast a check can be turned off without a deploy, and whether the change is itself recorded.
- Independent health signal. Whether the check path reports its own availability separately, including whether a successful response contained a real verdict.
- Shedding behaviour. Whether the infrastructure's overload response drops checks, and whether that is configurable rather than incidental.
- Replay and batch coverage. Whether the same posture applies to offline paths, which are usually wired separately and usually forgotten.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Circuit breakers and bulkheads (resilience4j, Polly, Envoy outlier detection) | Preventing a failing check from exhausting the calling service's resources | A tripped breaker needs a defined posture of its own; the default of returning an error is a decision disguised as a mechanism |
| Deadline propagation at the gateway or mesh | Bounding total request time across several checks so none can consume the whole budget | A deadline exceeded is reported identically to a clean negative unless the application distinguishes them explicitly |
| Policy bundle distribution with declared freshness (Open Policy Agent bundles and similar pull mechanisms) | Running a check locally against rules that keep working through a control-plane outage | Best-effort refresh is the default; an unreachable source often means stale rules serving indefinitely with no alarm |
| Feature flags and kill switches (OpenFeature, LaunchDarkly, Unleash) | Disabling or tightening a specific check in seconds during an incident | The flag platform becomes a dependency of the safety layer; its own outage is now in scope |
| Local sidecar or in-process check deployment | Removing a network hop and a remote failure domain from the hot path | Model and rule updates become a deployment concern, and every replica needs the capacity |
| Queue-based deferral | Work that can wait, where closing means later rather than never | Only applicable to asynchronous surfaces; a user waiting for an answer cannot be deferred |
| Health and verdict telemetry (OpenTelemetry metrics and spans, with indeterminate recorded as its own outcome) | Making the invisible failure visible, which is the precondition for everything else here | Requires discipline at every call site; one component that reports indeterminate as allowed reintroduces the blind spot |
| Synthetic probes that assert a known violation is caught | Continuous proof that the check is not merely responding but still deciding correctly | Probe traffic has to be excluded from quality metrics, and a probe that drifts from real traffic stops proving anything |