Reliability
The gate sits in your critical path. Here are the numbers.
Every consequential tool call waits on a gate decision, so latency and unavailability are part of the product contract. Two kinds of number appear below and we keep them apart: a measured engine benchmark, and production percentiles from recorded decisions. Production figures stay hidden until there are at least 100 samples in the window, because a percentile over nine calls is a story, not a measurement.
Engine benchmark · decision cost
10,000 evaluations · gate-1.1.0 · 2026-08-25
p50
0.007 ms
p95
0.016 ms
p99
0.035 ms
mean
0.012 ms
This is policy compilation output evaluated against a request: rule matching, condition checks and the decision record shape. It excludes the ledger append, the database round trip and your network — the parts we cannot claim credit for. The published targets below budget for all of them.
Measuring…
Production traffic vs target
0 latency samples in window
Reading the decision log…
- · p50 decision latency — committed target ≤ 25 ms
- · p95 decision latency — committed target ≤ 80 ms
- · p99 decision latency — committed target ≤ 150 ms
- · Decisions served — committed target 99.9% of gate calls answered
These are the targets we will be held to in a pilot, alongside the engine benchmark above. This panel switches to measured percentiles the moment the window holds 100 samples.
Production latency is measured inside the gate handler: policy evaluation, decision record and ledger append. Network time between your runtime and Interlok is not included, because we cannot measure your network honestly.
When Interlok is unreachable
Availability stance is a per-target default in policy, not a client flag buried in configuration. Every target declares what happens when the gate cannot be reached, and the SDK obeys that declaration.
fail_closed — default
The action is refused. Correct for money movement, production data, permissions and anything irreversible: an unreachable authorizer is not an authorization.
availability: fail_closed
fail_open — explicit opt-in
The action proceeds and a governance gap is recorded, then reconciled to the ledger when the gate returns. Only for targets where blocking work is worse than an unproven action.
availability: fail_open