We already have a receipt for what an agent did, and a receipt for whether it was allowed to do it. What we didn't have was a receipt for how the run actually unfolded — which steps happened, in what order, how long each one took, and where exactly it broke if it broke. That's the piece we just built the format and the plumbing for: a signed span tree, in the same shape most engineering teams already use to trace their own systems.
We shipped a first version of this receipt earlier this year: a flat, signed record saying an agent run happened, took this long overall, and ended in this outcome. That was already useful — provable, not just claimed. But a flat record can't answer the question an incident review actually asks: which stage stalled, which call failed, whether a retry happened before or after the point of no return. Answering that needs structure, not just a total. It's also the exact question DORA and NIS2 incident forensics push toward — being able to reconstruct an automated run after the fact, not just assert it happened.
Instead of inventing our own tracing model, we adopted the one OpenTelemetry already uses: a flat list of spans, each pointing at its parent, each carrying a name, a relative timestamp, a duration, and a status. That data model is deliberate — it's what most tracing tooling already produces, so a receipt can be minted from spans a team is already generating, and any OTel-aware tool can read the skeleton back out. We're not asking anyone to adopt a new mental model for tracing. We're signing the one they already have.
The signature covers the whole tree at once: every span's id, parent, timing, and status, committed and signed together so nothing in the shape can be edited after the fact without breaking the signature.
A span tree can leak a lot if you're not careful — error messages, tool arguments, anything a step touched. So the receipt only ever carries the skeleton in the clear: span name, parent pointer, duration, status. Everything else about a step — the part that might actually contain a client's data — is committed into a Merkle root instead of written out. Nothing sensitive sits in the receipt by default, and any single span's detail can be opened later, on its own, without exposing the rest of the run.
The receipt proves the shape of how something ran. It was never meant to prove the run was safe, correct, or good — that's a different, separate claim, and we're careful not to blur the two.
What exists today: the signed span-tree format itself, and an exporter that plugs into the standard OpenTelemetry SDK and mints one of these receipts per trace, automatically, from spans a service is already recording. What's still ahead is wiring this into our own products as the way every agent run gets instrumented, and a public renderer where anyone holding a receipt can inspect the tree instead of trusting a paragraph of prose. We built the primitive before the product feature, on purpose — same order of operations as the receipts before it.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog