§ BENCHMARKS
Enforcement latency, measured honestly
Governance only works if it is fast enough to sit in the request path. This page documents how we measure Execlave's enforcement latency and throughput — and publishes the numbers once they are measured under this methodology.
The pattern-tier, lab and production enforce figures and the kill-switch figures below are measured by checked-in harnesses (see methodology). The semantic tier and scaled throughput are marked not yet published — we publish only figures measured under the methodology on this page, never estimates or marketing round-numbers.
§ RESULTS
Pattern tier — measured
In-process policy evaluation latency (parse-cached CEL), excluding network and database time.
§ RESULTS
Server-side enforce decision — lab (local Postgres)
The real PolicyService.enforcePreExecution path: agent-status lookup + policy load + evaluation, DB-inclusive, against a local Postgres. Excludes HTTP/auth framing and the model-backed semantic tier.
§ RESULTS
Enforce decision in production — api.execlave.com
Measured on 29 October 2026 against the managed cloud (EU West, Amsterdam): 300 sequential enforce calls after 5 warm-up calls, for one agent evaluated against the two org-wide injection-scan policies of our own production organization. Server-side time is read from each response's Server-Timing header and is the sum of API-key authentication and the enforce handler; it excludes the network between client and API. No model-backed semantic check ran in these calls.
§ RESULTS
Kill switch — lab (local Postgres)
Server-side cost of the pause taking effect: the real AgentService.pause transaction (BEGIN + SET LOCAL + status SELECT/UPDATE + COMMIT), DB-inclusive, under the app_user role with RLS enforced. Propagation is synchronous — the first policy check after the pause commits is already blocked. Excludes HTTP/auth framing and network; a client over HTTP additionally pays per-request auth and round-trip latency.
§ RESULTS
Kill switch in production — api.execlave.com
Measured on 30 October 2026 against the managed cloud (EU West, Amsterdam): 30 pauses of a temporary agent through PATCH /api/v1/agents/:id/status with an API key, each followed by enforce calls until one was blocked. Server-side time is read from each pause response's Server-Timing header: API-key authentication plus the transaction that sets the agent to paused and appends its hash-chained audit record. The pause is in force when that transaction commits. The figure excludes the network between client and API and the notifications sent after the commit (dashboard event, SDK control channel, webhook dispatch).
§ RESULTS
Semantic tier & scaled throughput — pending
Dominated by the chosen LLM (semantic tier) and worker fan-out (throughput). Measured on representative infrastructure before publication — never estimated.
§ METHODOLOGY
How we measure
So the published numbers are reproducible and comparable across releases.
What the measured figures cover
The pattern-tier numbers are the in-process cost of evaluating a trace against a set of policies in the enforcement engine (parse-cached CEL expression evaluation), excluding network and database time. This is the part of enforcement latency Execlave controls directly; it is reported as p50/p95/p99, not an average, because tail latency is what governance SLAs care about.
Measurement provenance
Measured on Node.js v22.20.0, single process, one core, caches warmed. Each "pass" evaluates a representative set of 5 expression policies (cost/size/environment comparisons) against one trace, over 200,000 iterations after a 20,000-iteration warmup. The harness is checked in at backend/scripts/bench-enforcement.ts and calls the same evaluateExpression path the runtime uses — re-run it to reproduce these figures on your own hardware.
End-to-end measurement
The server-side figures drive the real PolicyService.enforcePreExecution path against a live Postgres — agent-status lookup, policy load, and expression evaluation, every database round-trip the SDK enforce endpoint makes, under the least-privilege app role with row-level security on. Measured on Node.js v22.20.0 against a local Postgres (sub-millisecond network), 5,000 calls after a 500-call warmup; the harness is checked in at backend/scripts/bench-enforce-e2e.ts. It excludes the HTTP/auth framing (sub-millisecond, not "enforcement") and the model-backed semantic tier. Production database round-trips are slower than localhost, so treat these as a floor, not a ceiling.
Production measurement
The production figures come from the harness checked in at backend/scripts/bench-enforce-prod.mjs. It creates a temporary agent, sends warm-up and measured enforce calls one at a time from a single client, reads the Server-Timing header of every response, reports percentiles of each request's authentication plus handler time, and deletes the agent. Inside our hosting region each database or Redis round trip currently takes about 5 ms, so the server-side figure is made up mostly of its three remaining round trips (key lookup, tenant context, quota plus agent read), not of policy evaluation. The client round trip depends on the client's distance to Amsterdam; a client inside the same region still passes through the public API edge. A second run the same day, from inside the region, measured 21.2 ms server-side at the median (p99 25.4 ms), so expect a millisecond or two of variation between runs. When the infrastructure changes, the table is measured again and re-dated.
Kill-switch measurement
The production kill-switch figures come from backend/scripts/bench-killswitch-prod.mjs. In each round it resumes a temporary agent, pauses it with one API call, sends enforce calls until one is blocked and reads the pause response's Server-Timing header; at the end it deletes the agent. The transaction is the larger share because it makes about eight sequential database round trips at about 5 ms each: it reads and updates the agent and appends the audit record to the organization's hash chain under a lock. A pause from the dashboard runs through the same service but authenticates with a session instead of an API key; its authentication time was not measured here.
What is NOT in these numbers
The semantic tier (model-backed checks via the Python processing service) depends on the chosen LLM and is not yet published. Horizontally-scaled throughput (traces/sec across workers) is likewise not yet published. We do not blend the microsecond evaluation, the millisecond server-side decision, and the model-backed tier into one headline figure, and we do not estimate the tiers we have not measured. The lab server-side figures run against a local Postgres; the production figures add managed-database round trips and API-key authentication, which is why they are higher. Every production enforce response reports its own server-side cost in a Server-Timing header.
Why per-tier, never blended
Pattern-tier (in-process, microsecond-scale) and semantic-tier (model-backed, millisecond-to-second-scale) enforcement differ by orders of magnitude. Collapsing them into a single "enforcement latency" number would be misleading, so each tier is reported separately and labelled with exactly what it includes.