A guardrail that fails open is decoration. In Bounded every write is checked atomically, app code cannot route around the check, and when something breaks the answer is no. Here is what that means mechanically.
Every backend has a failure mode. The question that decides whether you can trust it is which way it fails. When your auth check throws, does the write go through or get rejected? When your rate limiter cannot reach its store, does it allow or deny? Most systems, under pressure, quietly pick allow, because allow keeps the demo green. Bounded picks deny, everywhere, on purpose. Here is what that means in the mechanics.
Fail-open is a default nobody chose
A guardrail that fails open is decoration. A check that only runs when everything is healthy is not a check. It is a check plus a bypass, and the bypass is whatever your infrastructure does when it is degraded.
Notice when that bites. Under load, mid-deploy, when a downstream is slow, is exactly when you most need the limit to hold. It is also exactly when a fail-open limit is most likely to get skipped. The cap works in every condition except the one that produces the incident.
The three ways Bounded says no
A rejection is specific, and it is total. Rejections are fail-closed and nothing partial is ever applied:
403
Rule deniala write or invoke rule refused, with a trace of which rule.
409
Invariant violationa cap or conservation rule would break, named by its declared name.
200
Denied readempty data, not 403, so a caller cannot probe what exists.
The last one is a small detail that matters. A denied read returns 200 with nothing in it rather than a 403, so an attacker cannot use the difference between "forbidden" and "not found" to map your data. And a rolling cap is append-only: a 409 on a capped path is not transient. It means the window is full. Back off until the window moves. Do not retry-storm it.
App code cannot route around the check
The property that makes any of this trustworthy: enforcement does not live in your application code. It lives in the engine that every write passes through. A single-writer cell per project enforces the deployed policy atomically at the edge. Atomic means the batch commits or nothing does, and a rejected leg rolls the whole batch back.
The obvious next question is the escape hatch. Bounded has one: Functions, for when you need to call a third-party API, transform the result, then write. You get arbitrary imperative code. And it still cannot break an invariant.
Two reasons. First, every write a function makes goes through ctx.bounded, so it is re-checked by the same rules and invariants and throws 409 on a violation. There is no side door to the datastore. Second, the runtime policy evaluator checks the caller against the function's auth rule before the body executes, so only an authorized caller reaches the code at all. bounded verify separately proves the supported obligations generated from policy; it does not prove what your function logic does. The function is boxed inside the same boundaries as every other write.
Why this is a feature, not friction
Fail-closed changes what you are able to promise. If your limit fails open, the honest answer in a security review is "the cap holds unless something is wrong, and something is always eventually wrong." If it fails closed and it was proven at deploy, the answer is "the cap holds, and here is the counterexample report that says so." One of those you can hand to an auditor.
I want the worst case to be an outage, not a breach. A fail-closed backend degrades to "nothing happens." A fail-open one degrades to "anything happens." With money on the line I will take the outage every time, and I would rather the choice be made once, in the design, than rediscovered during the incident.
poof.new, our consumer builder, is built on Bounded for exactly this reason. The apps people build on it refuse the illegal write by construction, not by remembering to. If you want the same posture, bounded.sh is where it lives.