What happens if Decionis is unavailable during execution?

[ocularminds]

If Decionis sits inline between intent and execution, it becomes a dependency of every governed action. So: what happens when it can't be reached? Does the action proceed, or stop?

[ocularminds]

It depends on the consequence of the action — deliberately, and it's written down rather than left to each integration.

The rule is: when policy cannot be evaluated, the default posture is decided by what happens if the action proceeds unevaluated, not by which surface the request arrived on.

• Asymmetric downside, cheap retry → fail closed. An autonomous agent, a wire, a treasury movement, a margin or discount gate. Blocking costs a retry. Allowing costs money that doesn't come back, and produces an action with no evidence behind it.
• Present human, bounded exposure → fail open. A shopper at a retail checkout. The human is themselves a signal, the amount is small and reversible, and blocking a present buyer is direct revenue loss for something they didn't cause.

Where the two pull in opposite directions, consequence wins — a present human buying something large enough to matter still fails closed.

Each surface states its own default in its README, and every posture is configurable. If you're integrating, set it explicitly rather than inheriting a default: a safe default is not the same as a decision you've made.

Three things hold on every surface, whatever the posture

These matter more than the default, because they're the guarantees that keep "fail open" from quietly becoming "policy is optional":

1. Fail-open never overrides a rule that actually ran. It applies only to a degraded evaluation, where no policy could be evaluated at all. If a rule evaluated your action and blocked it, that verdict stands regardless of posture. Opting into fail-open buys availability during an outage, never exemption from policy.

2. No authority is signed for an unevaluated action. An Execution Grant asserts that policy authorized this specific action. A degraded allow has no policy behind it, so no grant is issued — you get the allow, but nothing that claims to be an attestation.

3. Every degraded decision is recorded. No Decision Dossier is minted when the engine is unreachable, so a dedicated degraded-decision event is the only trace that a decision happened without policy. On a fail-open deployment that record is the sole evidence an action went through unevaluated. Treat it as required telemetry and alert on its rate.

Failing open is about availability, not about errors

Worth being precise, because this is where a lot of gates get it wrong. The posture applies only when the decision service is genuinely unreachable — timeouts, transport failures, 5xx/408/429.

A rejected credential, a malformed request, an unparseable response, or a bug in the guard means enforcement is broken, not unavailable. Those always fail closed, on every surface, whatever the posture says, and they're reported with a distinct reason code so you can alert on them. A misconfigured guard must never silently stop enforcing while still reporting success.

Reducing the blast radius

The inline guard evaluates against a pre-synced signed policy snapshot with no network call on the hot path, so a transient outage of the decision service doesn't necessarily mean a degraded decision at all — the guard keeps evaluating against the last verified snapshot until it expires. Circuit breakers and per-endpoint failover bound the rest.

---

Related: Where Decionis sits in the stack · How Decision Dossiers are verified · Can Decionis govern AI agent tool calls?

Have a different architecture or integration question? Start a new discussion — we answer publicly whenever we can.