Proof and verification
Do not take our word for it. Re-verify the audit yourself.
Here is a real run. An agent prepared an action and was structurally blocked from signing off its own work, the decision held for a named human who signed, and the whole run exported as a signed evidence pack. The hash chain recomputes in your browser, the same check a regulator runs offline with no access to our systems. Change one character in the record and verify again: the chain breaks, and the verifier points at the exact altered row. You do not trust the audit because we wrote it. You trust it because you can re-derive it from a published spec, in any language, with us nowhere in the loop.
A real run
One maker step. One blocked self-approval. One human sign-off.
The agent did the work, then tried to approve it, and the engine refused before the approval could run. The decision waited for a named human, who signed with a recorded reason. Every prompt, response, grant state, and signature lands in the chain that footer verifies.
The green badge is not a status light we control. It is the result of recomputing the chain and checking the signature, the identical computation an inspector runs offline. When it turns green in your browser, the record is internally consistent and signed.
Run
pay-2026-06-13 · supplier payment
Prepared payment: $48,500 to Northwind Ltd
09:14:02
agent · accounts payable
Tried to approve its own payment
09:14:03
agent · accounts payable
Blocked: maker cannot be checker
An agent can’t sign off work it prepared. Refused, not flagged.
Approved by Dana Okafor
09:21:47
finance lead · human
“Vendor and amount verified against the purchase order. Approved.”
Change one row and verification breaks
The proof is a command you run, not a portal you log into.
You hand the auditor the exported pack and the published public key. They run the verifier offline, with no access to us. It re-derives the hash chain, checks the Ed25519 signature, confirms every state change has its audit row, and confirms the identity that processed a case never signed it. Then they tamper with one character and run it again.
offline verify
# Hand the auditor only the exported pack and the published public key.# No access to our systems, no network, no account.$ makerchecker verify ./run-P-4003.evidence.json --pubkey ./mc.pubchain 228 entries, head hash recomputed ........ OKsignature Ed25519 over chain head ................... OKco-commit every state change has its audit row ...... OKduties processor identity never signed its case .. OKVERIFIED the record is internally consistent and signed.# Now change one character in the pack and run it again.$ makerchecker verify ./run-P-4003.tampered.json --pubkey ./mc.pubchain BROKEN at entry 141: hash does not matchexpected 9f2c... got 0b7e...signature Ed25519 over chain head ................... FAILREJECTED altered at entry 141. The verifier names the row.
The verifier does not just say the record is bad. It names the row. A reviewer who has never seen our code can reproduce that result from the published spec, which is the difference between a log you are asked to trust and evidence you can check.
What the pack guarantees
Attributable, append-only, signed, and atomic.
Four properties, each one a thing a QA or CSV reviewer asks for, each one structural rather than promised.
Attributable
Every action is bound to a named identity
Each step carries who acted, what they did, and the timestamp, including the awareness timestamp that starts a reporting clock. The maker is named, the checker is named, and the agent that processed a case is barred in code from signing it off.
Append-only
Hash-chained, so an edit cannot hide
Each entry commits the hash of the one before it. The record is a chain, not a table you can quietly correct. Insert, delete, or alter a row and every hash downstream stops matching.
Signed
Ed25519, so the chain is yours to check
The chain head is signed with an Ed25519 key. A verifier recomputes the chain and checks the signature against the published public key, so a forged or replayed record fails the signature, not just the hash.
Atomic
The state change and its audit row co-commit
The case-state change and the audit event commit in a single database transaction. There is no path where the action lands without the record, so "acted but did not log" cannot happen by construction.
The published spec
Open format, open verifier, re-implementable from scratch.
The audit format is documented and the verifier is open source, so the check is not a black box. A team that wanted to could write their own verifier in their own language against the spec and get the same verdict on the same pack. That is the test of a format you can trust: someone other than the vendor can confirm it.
The hash chain goes beyond what most predicate rules require. We produce the evidence those rules ask for, and we never claim a rule demands the chain.
- Record
- Hash-chained, append-only
- Signature
- Ed25519 over the chain head
- Verify
- Offline, no network, no account
- Co-commit
- State and audit in one transaction
- Format
- Published and open
- Verifier
- Open source, re-implementable
Produces evidence for the rules your auditors already enforce. Never compliant, validated, or certified for you, designed against them.
Keep reading
See it for yourself
Hand the inspector a file they can verify themselves.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.