Fail Open or Closed

## The missing answer is itself an outcome A policy gate has two halves: something that decides, and something that asked. Fail open and fail closed are properties of the **caller** - the deploy tool, the pipeline step, the enforcement point - not of the engine. They describe what that caller does with silence. ## What counts as "no answer" From the caller's seat these are all the same event: - the call times out; - the connection is refused or the name does not resolve; - the service answers 5xx; - the service answers, but with something the caller cannot interpret; - the engine started, but could not load or parse its rule set, so it has nothing to evaluate against. The last one matters because it does not look like an outage from the outside. Collapse all of these into one class - *no usable decision* - and apply one rule to that class. Splitting behaviour by error type is exactly how a gate ends up failing open on the single error nobody tested. Record the distinct cause for the operators; do not branch policy on it. ## Fail open, and why it is more dangerous than an outage On fail open the change proceeds and the pipeline goes green. Two properties make this the more expensive default. It is **silent**: nobody is paged because nothing appears broken. And it is **indistinguishable from a pass** unless you deliberately made it distinguishable: the same green tick, the same log line, the same "policy: ok" in the run summary. What you lose is not only the one change that would have been denied. You lose the knowledge of *which* changes were never assessed. A week later, asked which deploys went out without a decision, you can only answer if you emitted something at the time. ## Fail closed, and the dependency it creates On fail closed the guardrail holds - nothing unassessed ships. The price is that the decision service becomes a hard dependency of delivery: its availability is now your delivery availability. That includes the awkward case where the change that would fix the engine has to travel through the gate the engine is blocking, so the failure is self-sustaining until someone intervenes. Fail closed also has a social cost. A gate that stops the world when it is sick gets a reputation, and reputations turn into pressure to weaken the gate permanently. ## The trade is per rule, not per system The useful question is: *what does one unassessed change actually cost?* - A rule that denies privilege escalation on a workload: one miss puts something in production with more power than it should have, quietly, possibly for months. That is not recoverable by noticing later. - A rule that requires a cost-allocation label: one miss produces an untagged resource that someone fixes next week. Nobody is harmed by the gap. Same engine, same outage, opposite correct default. A single global switch forces you to be wrong about one of them, which is why mature designs sit between the two extremes rather than picking one. ## Make the three outcomes distinguishable Whichever default you choose, the caller has three outcome classes, not two: 1. allowed by a real decision; 2. denied by a real decision; 3. no decision, default applied. Emit the third as its own thing - its own status, its own metric, its own alert - and keep the list of what shipped under it so it can be reconciled once the service is back. A gate that cannot tell you class 3 happened has already lost the argument with an auditor, and more importantly has lost it with itself. ## What weak answers sound like "We fail open, it is fine, code review catches it" - review is a different control with different coverage, and it was not asked to evaluate the rule. "Fail closed is always the secure choice" - true only if you never have to ship anything, and it ignores that a blocked incident fix is itself a security outcome. "The timeout means it passed" - it means nothing was checked; those are not the same sentence. ## How this is asked Usually as a scenario, not a definition: your gate calls a service, the service is down, what happens and who finds out. The interviewer is listening for whether you treat the missing answer as a first-class outcome with its own handling, or as an edge case the config file happens to decide for you.