Frequently Asked Questions — Proving an AI Safeguard Actually Ran
Direct answers, no pitch. Every answer below is drawn from AgenticRail's published docs and specs — nothing here is a new claim.
What does it mean for an AI safeguard to be provable rather than just claimed?
There are three tiers. Asserted: a policy or press release states the check happens, but the system doesn't require it and no independent record exists. Enforced: the system structurally cannot proceed past a skipped or out-of-order step — a decision with a missing safeguard is denied before execution, not flagged. Provable: every decision leaves a cryptographically signed, sealed, tamper-evident receipt of the steps that ran, in order, verifiable by a party outside the operator, offline, against published keys, without trusting the operator's servers. Most deployed safeguards today sit at tier one.
How is this different from a normal system log?
A log written by the same system whose conduct is in question answers a narrower thing than people assume. "We logged it" is not the same as "we can prove it" — a log that can still be added to, edited, or tidied after the fact cannot establish that what it shows is the complete account as it stood at the time. A provable record is created before the action, independent of the system being recorded, cryptographically signed, and irreversibly sealed, so the account is fixed at the moment it happened.
Do I have to trust the company that built this?
Not to verify a receipt. Verification runs entirely offline, against public keys published at agenticrail.nz/spec/receipt-public-keys.json, with standard Ed25519 verification code you run yourself — no network call to AgenticRail required. A sealed sequence also cannot be reopened without leaving a detectable break in its hash chain, and sealed sequences are additionally copied to an independently held write-once archive at the moment of sealing, so even a rewrite by the operator is detectable against the witness copy.
Does this work with any AI system, or only a specific vendor's?
The gate sits between an agent and its downstream actions and evaluates the request payload against a declared policy — it does not care which model or vendor produced the request. Any agent, on any model, can be wired to call the gate before it acts. It is an independent enforcement layer, not a feature of one AI provider's stack.
What does it actually take to implement this?
An agent declares its own step order and calls the gate before each action with a small payload — sequence_id, step, function, action_type, action, inputs, a fresh nonce, and a timestamp. The gate returns ALLOW or DENY before the action runs. Python and JavaScript SDKs wrap this contract directly. Full payload contract and API reference: agenticrail.nz/docs/.
Is this specific to New Zealand, or could any country or agency use it?
The mechanism itself is not jurisdiction-locked — the receipt chain is citable as evidence under frameworks including EU AI Act Article 12, ISO/IEC 42001 A.6.1.6, and NIST AI RMF Measure 2.4. The company's current outreach is focused on Aotearoa New Zealand, but nothing about the enforcement mechanism or the receipt format restricts it to any one country or agency.
How do you verify a receipt without contacting AgenticRail?
Fetch the published public keys, take a receipt's signed_canonical preimage and its signature, and run ed25519_verify(public_key, signed_canonical, signature) in your own code. That's the whole check — no account, no callback, no dependency on AgenticRail's servers being up. Flip one character in the signed content and the verification fails.
If the company disappeared tomorrow, would verification still work?
For any receipt and public key you already hold a copy of: yes, permanently — Ed25519 verification is pure offline math, it does not call home. The honest limit is upstream of that: fetching a receipt from the live report tool, or fetching the keys fresh from the live site, needs the company's infrastructure to be running. Anyone who wants verification to survive the company should save the receipt and the public keys themselves. This is also the exact gap the independently held archive exists to narrow, not fully close — it protects against the operator quietly rewriting history, but the archive is not yet run by a separate custodian, so that residual case is disclosed, not hidden.
Full enforcement spec — agenticrail.nz/spec/
Asserted vs. enforced vs. provable, with Robodebt as the case study — agenticrail.nz/spec/enforceable-safeguards/
Verify a real sealed record — report.agenticrail.nz/report
API documentation — agenticrail.nz/docs/