Reference

Failure behaviour

What happens to your traffic when Navige cannot answer.

This is the first question in every architecture review, and “it depends what threw” is not an answer. So it is configuration, with a default that is deliberately asymmetric.

The default, by classification

When the pipeline cannot reach a real verdict, what happens depends on what the tool is. A degraded Navige must not be the reason your support agents stop answering tickets — and must not be the reason an unreviewed payment went out.

text

read          open     allowed
unknown       open     allowed
write         closed   blocked
destructive   closed   blocked
financial     closed   blocked

unknown failing open is the load-bearing choice

An unclassified tool is, in practice, overwhelmingly a newly discovered read. Failing closed on first sight of any new tool would turn every discovery event into an outage. An organisation that disagrees sets the default to closed and accepts the trade.

Changing it

Set a default for everything, and override per classification. Most specific wins. An organisation that would rather stop than proceed unchecked sets default: closed and is done.

Causes

Every degraded decision records why, and the reasons are distinct rather than one generic error.

policy_context_unavailable — policies could not be read.
kill_switch_unavailable — the kill switch state could not be read.
budget_unavailable — budget state could not be read.
counter_unavailable — the rate and runaway counters could not be read.
internal_error — anything else.

A degraded allow is not an allow

This matters more than it sounds. A call permitted because a policy said so and a call permitted because Navige could not check are two different events, and they are never summed into one figure. The console shows degraded decisions separately, so after an incident you can answer the only question anyone will ask: which calls went through unchecked.

An empty policy context is likewise never read as “this organisation has no policies”. That reading would turn a cache outage into a silent, organisation-wide policy bypass.

On the proxy

If the upstream provider fails, you get the provider's error, unaltered. Navige does not retry on your behalf or convert their error into one of ours — your SDK's existing retry logic is better placed to decide.

If Navige's own recording fails after a successful upstream call, you still get your response. A dropped metric is not worth a failed request.

HTTP status

400 — your request is malformed. On /enforce this is decision: "error" without unavailable.
401 — missing, malformed, unknown or revoked key.
403 — the agent is inactive or expired.
404 — unknown provider on the proxy.
503 — Navige is unavailable. On /enforce this is decision: "error", unavailable: true.

Do not collapse 400 and 503

Your bug and our outage arrive at the same branch of your code and want opposite handling. Treating both as a denial means an outage quietly stops your agents; treating both as an allow means a typo in your payload quietly ungoverns them.