Fail-closed

Fail-closed describes a control that denies the action when it can't decide: the check errors, times out, or lacks the data it needs. The opposite, fail-open, lets the action through in those cases.

What it is

Every gate has three outcomes, not two: pass, fail, and "couldn't tell". Fail-closed treats the third like the second. A door lock that stays locked when the power goes is the classic example; a release gate that blocks when its findings query times out is the software one.

The design choice shows up in small places: a .catch(() => null) that later reads as "no problems found" quietly turns a fail-closed check into a fail-open one.

Why it matters

A gate that passes whenever it breaks protects you only when nothing is wrong. Errors often cluster with incidents, so the moment a check is most likely to fail is the moment it matters most.

In AI CodeOps

• Release check from CI: if evaluation throws, POST /api/release/check answers allowed: false with "Evaluation failed".
• Opening a session's pull request: if the release check can't run, the pull request isn't opened. You're asked to try again in a moment.
• Workspace policy: if the policy can't be loaded when a pull request is about to open, the request is refused. A rule that would ask for approval on an action that can't wait for a person becomes a deny.
• Approval: a change with no approval on record isn't treated as approved. A review is requested, and the pull request waits for it.