Demo · illustrative sample
Change one thing. Watch the receipt respond.
An origin receipt reads as five lines, each verified, asserted, unavailable or failed. Below is an illustrative sample you can alter, then six short moments that show what Rootz Receipts refuses, records and proves.
The sample
An origin receipt for one answer.
An agent summarised two filings for a board. Each button changes one thing and shows what the verifier reports, and on which line.
- verified
Checked, and it holds.
- asserted
Present, not independently checked here. Reason stated.
- unavailable
Could not be evaluated. Reason stated.
- failed
Checked, and it does not hold.
Six moments
What a demo of Rootz Receipts shows.
Pick a moment, then run it. Each one plays a short script of what happens and shows the result a recipient would see.
1. An unsigned policy is refused
Run it live
Run the demo on our server, now.
Press the button and our demo server runs a fixed script on a real NVIDIA OpenShell gateway: an install with no approval is refused, an officer approves the exact configuration, an agent makes one call, a widening change is refused, and the record is sealed by a key held in the server's TPM. You get the origin receipt for the agent's answer and check it here, in your browser. Then throw the receipt away: from the answer alone, its fingerprint finds the paper trail again, and a single changed letter finds nothing.
The company in this demo, Example Corp, is invented and its keys are demo keys. The run is limited to a few per visitor per hour, and the sandbox is deleted when it ends.
A real origin receipt
Not a mock-up: made and checked by the real code.
The receipt below was produced by the Rootz Receipts packages from a real session log, with real signatures and real Merkle proofs, and checked by the real verifier. The keys are throwaway demo keys and the company, Example Corp, is invented, so it is a sample, not a record of a real transaction. It is the receipt for a board memo that names, as its input, the receipt of the research step it was built from.
$ ask-orders verify receipt.json --request request.txt --answer answer.txt --keys keys.json --chain chain.json
origin receipt sha256:sKvCVSL0FknxizF32KxEPHDmjeuhxZjioZqHy7rXpBE
verified at 2026-10-01T15:00:00.000Z (supplied)
Authorized by verified L2 Signed by an officer authorised by the company root at the instant of signing
Specification verified L2 The exact request, allowed under the controls in force
Materials verified L2 Every fetched source and input receipt is in the record
Process asserted L1 The signed order's policy was in force; part of the process is stated, not checked here (see the reasons)
policy-link-unverified, checkpoint-key-unbound, platform-evidence-declared
Integrity verified L2 The exchange is in the signed session record, complete and unaltered
Check it here. This page loads the real verifier, built for the browser from the same code, and runs it on the files above. Nothing is sent anywhere.
Why Process says asserted: this sample ran with no hardware measurement and an unbound checkpoint key, and the receipt says so rather than claiming more. On a TPM- or confidential-VM-backed host, that line can be verified.
Download the set and check it yourself: receipt.json · receipt-a.json (the research step) · request.txt · answer.txt · keys.json · chain.json. Change one character of answer.txt and Integrity fails. The command-line verifier ships with the pilot.
What comes next
The live demo replaces this sample.
The live demo runs these moments on a real OpenShell sandbox: an unsigned install refused, an order signed, one agent task, the receipt, then the tamper buttons, all checked by the real verifier in your browser. Design partners run it on their own workflow.