The operating record

Every enforcement decision AgenticRail has made, permits and refusals alike, written to a signed receipt at the moment it was made.

Measured 19 August 2026. Receipt store created 22 February 2026.

The receipt count is read from the store itself. The refusal and seal counts come from a counter that only began on 28 April 2026, so both undercount, and the two are not a ratio.

What the number counts

A receipt is written for every decision the gate makes, whether the step was permitted or refused. That is the difference between this record and an audit log. A log contains what happened. This contains what was not allowed to happen, which is the half that matters when someone asks whether a control was actually in force.

Of the decisions made since the counter was introduced on 28 April 2026: 1,199,005 decisions, 1,124,707 permitted, 74,298 refused, 123,724 sequences sealed at completion. The stored receipt count is higher than the decision count because receipts were being written for nine weeks before that counter existed. The stored receipts are the artifacts; the counter is a tally that started late.

Not everything AgenticRail refuses appears here. A malformed, unauthenticated or poisoned request is turned away at the boundary before it reaches enforcement, and a request that never reaches enforcement produces no receipt. Those refusals are real and are counted elsewhere; this page counts decisions the gate actually made.

What the number does not establish

It is not a customer count, a user count, or a deployment count. The overwhelming majority of this volume is our own: load runs, adversarial testing, internal sequence writing, and public demo traffic. One operator, not a market.

It is also not a throughput claim. The traffic is bursty rather than steady, and a single month, May 2026, accounts for most of the last ninety days at 379,748 gate calls. Read this as a soak record: the code path has been executed more than 1.6 million times. What can be measured of its error record is set out below, and over that window it is zero. That is a durability statement, and it is the only statement being made.

Verify one yourself

None of the above is worth anything if you have to take our word for it. Below is a real sealed sequence, driven by a third-party model through the public MCP server. It needs no account and no key.

Paste that sequence id into the public verifier, or request the report directly:

curl -X POST https://report.agenticrail.nz/report \
  -H "content-type: application/json" \
  -d '{"sequence_id":"demo-mcp-payment-workflow-001","format":"json"}'

The response carries the raw signature, the byte-exact signed_canonical preimage, and the public key bytes inline. You do not have to call back to us to check it:

ed25519_verify(public_key[key_id], utf8_bytes(signed_canonical), base64_decode(signature))

That sequence opens with a refusal, and the chain resolves across it correctly. The two links reported with no predecessor are not a gap: a receipt is anchored to the last permitted step that durably stored, so the opening refusal and the retry immediately after it both legitimately have nothing behind them. The report says not_verifiable for those two, and it is right to. A chain that only survives when everything succeeds is not a chain worth having.

The correctness record

On 5 July 2026 the gate was given 1,995 requests on the production key, with attack payloads mixed into legitimate traffic in a single run. Every denial class landed correctly, 525 of 525 poison payloads were rejected, and rejections resolved fast because the gate refuses malformed input before it reaches enforcement. There were no failures.

The error record, and where it cannot be read

Over the thirty days to 19 August 2026, the enforcement core handled 3,022 invocations and returned zero errors. Across the whole estate, 75,136 invocations produced 30 errors, all of them in the operator dashboard, which sits outside the enforcement path.

The platform will not return an analytics window wider than four weeks and four days. A longer claim is therefore not available to us, and would not be available to anyone auditing us either. Thirty days at zero is what can be shown, so thirty days is what this page says.

What a decision costs

Between 1.6 and 3.6 milliseconds of compute per decision. Almost all of the wall time is storage and network wait rather than cryptography, which is why signing every decision is not the expensive part of doing this.

On the seal

A sealed sequence cannot be reopened or rewritten without leaving a detectable break in the receipt chain. A single altered receipt is caught immediately. A wholesale rewrite by a holder of the signing key is not caught by the chain alone, which is why sealed receipts are copied to a separate archive under a different credential, and why the report above states whether that archive agrees.

We hold the signing keys. We say so on the FAQ, and it is the reason the archive exists.