The policy check takes 0.024ms. That was never the hard part.

That is the least interesting number we have. We publish it because people ask for it, and because a number without its basis is not a number.

Here is exactly what it measures: one policy decision, evaluated in-process with state already warm, run 2,000 times on a single Apple Silicon machine.

median   0.024 ms
p95      0.026 ms
max      0.11  ms
n = 2,000 · warm state · in-process · Apple Silicon · 28 Aug 2026

Here is what it does not measure. It is not an end-to-end request benchmark. It excludes transport, receipt signing, disk, and everything else between an agent deciding to act and the action landing. It is a microbenchmark of one function on one machine. Cold state will be slower and we have not characterized how much slower. Treat it as evidence that policy evaluation is not your bottleneck, and nothing more.

Where the seconds actually go

We have filmed exactly one production comparison.

n=1 is n=1. One question, one day, one operator. We published the logs so the run can be argued with, not so it can be quoted as a benchmark. But even taken at face value, that 14.4 seconds is roughly six hundred thousand times the policy check (arithmetic, from the two measurements above). The guard is a rounding error inside the call, and the call is a rounding error inside the thing that actually governs throughput.

Once an action changes state, the clock is not measured in milliseconds. It is measured in how long it takes a person to look at it. That might be forty seconds. It might be until Monday. We have not measured that distribution across real installs, and we are not going to invent one.

An approval queue is a throughput problem and a psychology problem

The throughput half is arithmetic you can do on a napkin. If agents generate approvals faster than humans clear them, the queue grows without bound, and the honest responses are fewer approvals or more approvers. There is no third option where the queue handles itself.

The psychology half is harder, and it decides whether a governance product is real. At volume, exact-payload approval degenerates into rubber-stamping. Anyone who has clicked through a hundred near-identical diffs knows how it goes. It does not feel like carelessness while it is happening. It feels like recognizing a shape you already checked, which is the reflex that stops resolving detail.

And a rubber-stamped approval is worse than no approval at all. Not equivalent. Worse. With no approval, everyone knows the action was unreviewed. With a rubber stamp you hold a signed record asserting that a person reviewed it, and that record is true about the click and false about the review. We build a system whose entire output is evidence. A design that manufactures false evidence of review is the most damaging thing we could ship.

What follows if you take that seriously

The work stops being about making the check faster and starts being about reducing the number of decisions without reducing which decisions are decisions.

• Separate risk classes instead of treating every action alike. Reading and analysis should not cost a human decision. Money movement and destructive writes should. In our airlock, state-changing actions never auto-fire over MCP. What draws that line has to be the class of the action, not a hint: readOnlyHint and its siblings are advisory in the protocol, and whoever writes the tool writes the hint.
• Batch by policy class, not by instance. A human should decide once about a category and its bounds, rather than once per member of it. Repeating an identical decision does not repeat the review that went into it.
• Show the resolved payload, not the intent. Approving “delete stale records” and approving the exact statement that will execute are different acts. The intent line is a summary written by the same model whose action you are checking. The screen must show the thing that runs.
• Keep the escape hatches blunt. Dual-control codes for sensitive scopes, where one tired person is not enough. A global freeze switch, for when stopping everything beats adjudicating anything.

What we have not finished

Policy-scoped auto-execution under a floor — an action below an explicit, human-set threshold running without stopping the queue, with the receipt still written — is the obvious next question. We have not shipped it and this is not a date. Until it exists, the honest description of what we sell is that it trades human time for provable review. Plan around that.

We have also not measured queue depth under load, or how often review degrades in practice. Those are the numbers that would settle this argument, and we do not have them. When we do, they will carry an n and a date.

What the signature is actually for

Every governed action emits an Ed25519-signed receipt into a hash-chained log you can verify offline, with no account and no callback to us. The reason we sign the approval into that chain is not to prove the policy ran. A deterministic policy evaluation that finishes in 0.024 ms is the part you can simply re-run and check.

The receipt exists to record which human took responsibility. When someone asks in six months who authorized this, the answer should be a name and a payload and a timestamp, not the shrug of “the system permitted it”. A machine can evaluate a policy in a fraction of a millisecond. A machine cannot accept the consequences of being wrong. That half stays human. The fast number at the top of this post is fast because it is the easy half.