Fail-closed & degrade-closed

If the policy engine errors, if the audit write fails, if a required cloud state service is unreachable, if a warrant's consume-once counter can't be confirmed — none of those produce a permit. They all produce a deny, with a reason code that names exactly what broke:

deny.eval_error                    the policy engine raised an internal error
deny.audit_error                   the audit write failed before the decision was returned
deny.control_plane_unreachable     a state-bearing decision needed the control plane, which was down
deny.warrant_state_unavailable     the shared warrant counter couldn't be reached; never upgrade under uncertainty
deny.credential_error              the credential broker failed to mint a short-lived credential

The mental model: every error is more restrictive, never less

raxit's rule is simple to state and easy to verify by reading the reason codes above: every failure mode narrows what's allowed, never widens it. A broken dependency, a timeout, an unreachable service, a malformed config value — none of these are ever interpreted as "when in doubt, let it through." The system has exactly one direction it fails in.

This shows up at three different layers:

1. Cedar evaluation. A policy-condition error is deny.eval_error, not a fallthrough to permit — see step 2 of the decision resolution chain.
2. Audit-before-execute. The Decision Provenance Record is fsync'd before the decision returns. If that write fails, the decision flips to deny.audit_error — an action can never run without a corresponding audit record already committed. See Audit & the DPR chain.
3. Warrant/state consistency. A warrant that would upgrade a defer to permit only does so if the shared, cross-replica consume-once counter gives a definitive answer. If that state authority is unreachable or ambiguous, the upgrade is refused (deny.warrant_state_unavailable) rather than guessed at — never "assume it wasn't used yet."

Degrade-closed: what happens when the control plane goes away

Some decisions need shared state that only the control plane can answer — cross-replica taint, warrant consumption, saga journaling. When that control plane is unreachable, the call denies (deny.control_plane_unreachable) rather than falling back to a local, possibly-stale answer that could under-count a budget or miss a taint label. This is "degrade-closed": losing connectivity to a dependency degrades the system toward more restrictive behavior, not less.

There is no permissive kill switch

RAXIT_GOVERNANCE is the one deliberate bypass — and it's intentionally narrow. It accepts exactly two values, "on" or "off" (case/whitespace-insensitive); anything else, including plausible-looking typos like "1" or "true", raises an error synchronously rather than silently defaulting to either state:

RAXIT_GOVERNANCE=on    # governed (default when unset)
RAXIT_GOVERNANCE=off   # governance disabled — calls return a synthetic bypass permit
RAXIT_GOVERNANCE=1     # error: not "on" or "off"

There is no third value that means "govern, but permissively" — off is a full, explicit bypass you have to opt into with an exact string, not a dial you can nudge toward permissive.

fail_open is a dev-only, explicit opt-in

Some lower-level autopatch/drift machinery exposes a fail_open-shaped knob for local development — e.g. RAXIT_DRIFT_MODE=warn downgrades an autopatch drift/tamper signal from a hard abort to a logged warning that continues ungoverned. This exists for iterating on integration code locally; it is not the production default (RAXIT_DRIFT_MODE defaults to "fail-closed"), and it never appears in security.yaml itself — there's no default: allow or equivalent authored-policy escape hatch. See Rules & effects for the corresponding security.yaml rejection: default allow is not supported; use enforce.