Verify our claims
A Bolt audit chain is a sequence of Ed25519-signed Merkle roots over canonically hashed events. The verifier is one binary, bolt-audit-verify, that takes an exported proof bundle and the platform public key and returns a verdict per sealed root. It runs offline, with no database, no KMS and no network. It is the strongest trust signal we can ship: your auditor never has to take our word for it.
The model
A vendor that says “trust us, the audit log is good” is asking the buyer to accept an asymmetry. Bolt's audit chain inverts that: your auditor runs the verifier on hardware you control, against bytes you exported, using a public key whose private half you never need to see. There is no point in the verification path where you have to take Sparcle's word for it.
The verifier runs entirely inside your perimeter. No outbound calls. The platform verifying key is the only thing you need alongside the bundle, it is a public key, and it comes out of your own KMS rather than from us.
The event hash and Merkle root are byte-compatible across Bolt and Aeira, and the canonical encoding is version-tagged so already-sealed roots keep verifying after the encoder moves on. Tests in the shared conformance crate assert the frozen byte shape of each version and fail if it changes. Be precise about what that buys: those tests run in the library's own CI, and they are not a release gate on the shipped product, so treat them as a strong guard against accidental drift rather than as a promise no release can ever break replay.
The chain cannot be silently modified; every tampered byte invalidates downstream signatures. It can, in principle, be deleted, which is why retention is contractually specified and the storage substrate (WORM or audit-replicated Postgres) is the customer's choice, not Sparcle's.
A sealed root is signed with the platform signing key, which is distinct from any tenant CMK. Destroying a tenant CMK therefore does not affect the verifiability of the chain that covers that tenant's events (see /trust/cryptographic-erasure).
The procedure
The verification path is small by design. Each step has a specific failure mode and a structured exit code so it can be wrapped by your auditor's existing tooling without ceremony.
A bundle only carries a signed root for a window that has been sealed, so seal first with POST /api/v1/admin/audit/seal. Then export: bolt-audit-verify export-bundle --from 2026-01-01T00:00:00Z --to 2026-02-01T00:00:00Z --out audit-proof.json, or the equivalent POST /api/v1/admin/audit/export from the running app. Both build byte-identical output from the same code path, both are read-only, and a window is capped at 366 days and 200,000 events per call. Add --tenant to scope the export to one tenant.
The signature over each sealed root is made with the platform Ed25519 signing key, and its public half is supplied to the verifier separately rather than carried inside the bundle: a key shipped inside the artifact being verified proves nothing. On the file-backed KMS, bolt-audit-verify export-key --kms-root <data-dir>/kms --out platform.pub.hex reads the public half and never touches private key material. On AWS KMS it is GetPublicKey; on Vault, a read of the transit signing key. Distribute it through your own trusted path and pin it.
bolt-audit-verify verify audit-proof.json --pubkey-file platform.pub.hex. No database, no KMS, no network. It re-hashes every event from its canonical fields and uses those fresh hashes for the Merkle re-derivation, so the events-to-root binding never trusts the hash column carried in the bundle; it rebuilds each sealed root from the in-window events and compares it to the signed root; and it verifies each root signature against the key you supplied. Omit the key and it still checks the integrity chain, reporting the signatures as not checked.
It prints a step-by-step human report, or machine-readable JSON with --json, and returns a distinct code per finding: 0 verified, 2 integrity failure meaning tampering, 3 signature failure, 4 incomplete export, 5 integrity ok but no key supplied, 6 not sealed, 1 usage or IO error. Only 0 is a full pass. Two secondary fields, event_hash_mismatches and bundle_digest_ok, flag a stale or altered bundle field; a warning there without a Merkle failure is a bundle problem rather than a broken proof.
The full canonical verification, in one block:
# export the sealed range you want to verify
bolt-audit-verify export-bundle \
--from 2026-01-01T00:00:00Z --to 2026-02-01T00:00:00Z \
--out audit-proof.json
# verify it offline: no database, no KMS, no network
bolt-audit-verify verify audit-proof.json \
--pubkey-file platform.pub.hex --json
# 0 verified | 2 integrity | 3 signature | 4 incomplete | 5 no key | 6 not sealed
echo "exit: $?"What's available
The same honest framing the rest of the trust center uses. The sample chain and the verifier are designed to be in your hands well before any contract is signed.
A sample proof bundle with the corresponding platform public key, so you can run bolt-audit-verify end-to-end against a known-good input before installing anything. Available on request.
The same binary the product ships, not a separate build. It is inside the macOS app bundle on Apple Silicon, beside bolt-api in the server container image, and published as a standalone release artifact for Windows. Two gaps worth knowing before you plan an audit around it: the Intel macOS bundle does not carry it, and standalone macOS and Linux builds are not published on every release. If your auditor is on one of those, ask us for the binary rather than assuming it is on the machine.
The verifier is intended for source release under a permissive license so a customer's auditor can build it themselves and confirm there is no Sparcle-only inspection path. Source distribution is gated on the OSS-release sign-off currently in flight.
The byte-stability test suite that gates every Bolt and Aeira release. Lets your auditor confirm that the verifier they ran six months ago is still the correct binary to run today against a fresh chain. Available under NDA during pilot evaluation; intended for public release alongside the verifier source.
What the verifier does not claim
Related trust artifacts
Ask for verifier access. We send a sample chain, the operator-root public key, and the binary for your platform. Your auditor can run it on a laptop in under five minutes. No NDA required for the sample run.