DEV Community

rambo
rambo

Posted on

Build for a Friend: Receipt Lens

Build for a Friend: Receipt Lens

Entered in the Best Use of Sentry Agent Tracing category: tooling that shows an agent's work, with traces.

Receipt Lens architecture diagram

The problem

A friend of mine runs AI agents to do real work: research, data pulls, summaries. The agents are useful. The problem is what happens after. The agent says "done," hands over an answer, and everything in between is a black box.

He asked me the simplest question in the world: what did the agent actually do?

I didn't have a good answer. If a step was slow, skipped, or faked, nobody would know. If the agent claimed it called five tools and called two, there was no way to check. The output looked right, so we trusted it. That's not verification. That's hope.

This weekend I built him something real.

What Receipt Lens does

Receipt Lens takes an AER-1 verifiable receipt (JSON) and shows you the agent's execution trace: every step it ran, in order, how long each took, and whether the receipt checks out cryptographically.

Receipt Lens landing page

Paste a receipt, and you get:

  • A verdict. Valid or invalid, with a per-check breakdown. No ambiguity.

Valid workflow verification result

  • An execution timeline. Every step the agent ran, in order, with per-step latency bars. Slow steps are visible. Skipped steps are visible.
  • Cryptographic verification. Not a heuristic, not a guess. The receipt's Merkle root gets recomputed from the step sequence and compared against what's published. If they don't match, something changed after the fact, and the tool tells you exactly which check caught it.
  • Honest limits. The page shows what the check does not prove, like the fact that network resolution steps can't be verified offline. A verifier that admits its limits is more trustworthy than one that doesn't.

There are three demo buttons. Click "Demo: tampered workflow" and watch it work: the same valid five-step receipt, one step id altered, and the Merkle root check catches it with the exact published vs. recomputed mismatch shown on screen.

Tampered workflow detected

New: swarm graphs and shareable links

Two additions since the first version.

Swarm graph. Receipts from multi-agent runs now get a delegation view: one node per agent, arrows for handoffs, and per-agent swimlanes that expose parallel branches as overlapping lanes instead of a flattened list. Click "Demo: agent swarm" to see a 3-agent crew (coordinator, researcher, writer) verify 15/15, then switch to the Swarm graph tab.

Swarm graph delegation view

Shareable links. Every verification now has a "Copy share link" button. The receipt JSON is gzipped and base64url-encoded into the URL fragment, so opening the link re-runs the full verification automatically. Nothing is uploaded anywhere: URL fragments never reach a server, so the receipt bytes stay between you and whoever you send the link to.

Why open innovation matters

This project exists because of an open standard.

AER-1 is an open IETF draft: a specification for verifiable execution receipts, readable by anyone, implementable by anyone. There is no permission to ask, no license to buy, no vendor to negotiate with. The draft text is public on the IETF Datatracker. The conformance test vectors are public. I wrote Receipt Lens's entire verification engine fresh from the draft text this weekend, in one session, with zero dependencies beyond Python's standard library.

That is what open innovation buys you. A closed ecosystem would have made this weekend impossible. I would have needed API keys, SDK agreements, a partnership call. Instead I needed the spec, the spec was public, and the tool exists now.

Openness also compounds. Because the format is open, anyone can mint these receipts. Because the verification is open, anyone can check them. Because the tool is open (MIT license), anyone can run it, fork it, or build something better on top of it. Every layer feeds the next. Closed formats extract value. Open formats multiply it.

How it works

The backend is one Python file, standard library only (http.server, hashlib, json). It handles three receipt shapes:

  • Workflow receipts: 15 checks, including every Section 8 Table 2/3 member rule, sequence ordering with no gaps, the no-duplicate-receipt-id rule, and a full recomputation of the Section 8.1 Merkle root over the step sequence.
  • Hash-chained job timelines: 7 checks, including genesis, sequencing, and per-entry digest plus link recomputation down the whole chain.

Hash-chained job timeline verification

  • Single execution receipts: 9 checks, including the output_hash commitment over the canonical bytes.

The Merkle implementation reproduces the draft's published example root from its five step ids, so I know the construction matches the spec byte for byte. Timestamps are validated strictly (February 30 gets rejected). The server fails closed: any inspection error reports "not verified," never "valid."

The frontend is a single HTML page: paste box, demo loaders, verdict banner, timeline visualization, check list, honest-limits panel.

click a demo.

Try it

No install needed: https://receipt-lens-7c4fed.gitlab.io/. Open it, paste a receipt or click a demo, get the verdict. Verification runs entirely in your browser.

Or run it locally:

git clone https://gitlab.com/rambozambodotdev/receipt-lens.git
cd receipt-lens
python3 app.py
Enter fullscreen mode Exit fullscreen mode

Open http://localhost:8137. No dependencies. Paste a receipt or click a demo.

What's next

The demos cover the verifier's correctness. The next step is volume: pointing Receipt Lens at real agent runs, finding the receipts that don't verify, and figuring out why. The interesting bugs are always in production traces, not demos.

If you run agents for real work, try it on your own receipts. If something comes back invalid, that's the tool doing its job.


Built October 2, 2026, within the Hacktoberfest Weekend Challenge window. New code, written for this challenge. The AER-1 specification it implements is an open IETF draft, free for anyone to read, implement, and build on.

Top comments (0)