TreeshipSigned is not trueBlogDocsGitHub

Perspective · 2026-09-18

Signed is not true

The sharpest attack on a receipt is that a signature proves nothing about the world. It is correct. Here is exactly what a Treeship receipt proves, what it does not, and the three mechanisms that turn a signed report into something you can grade.

perspective#receipts#trust#verification#identity6 min readAll posts

Signed is not true

Someone will make this argument about Treeship, in a diligence call or a comment thread, and they will be right: a signature proves who signed and that the bytes have not changed. It proves nothing about whether the thing signed is true. An agent that signs its own report card has proven that it holds a key.

We agree, and we would rather write it up ourselves than have it written up for us. Here is the claim a receipt makes, the claims it does not, and what we built so that "signed" is not where the story ends.

What a receipt proves

A Treeship receipt is a narrow instrument, and the narrowness is what makes it hold.

What it does not prove

Three mechanisms that close the gap

Stating the limit is table stakes. The product is what sits on the other side of it.

Custody grades on hand-offs. When one agent hands work to another, the receiving side mints a fresh nonce and the sender must answer it with its own key, right now. A hand-off that passed that check records custody: live. One that did not records custody: asserted, with the reason. The word is inside the signed statement, and a verifier refuses to upgrade an asserted hand-off to live no matter what the payload claims. The homepage demo shows the asserted case on purpose.

Actor proof. By default every receipt in a workspace is signed by the workspace key, and the actor name is a label. Register the agent with its own key, certified by the workspace, and the receipt's signer is that key: the verifier prints actor proof: proven (key-bound) instead of asserted. Same receipt format, a different grade, and the grade is what a reader is meant to read.

Capability provenance. An agent's capability card can declare tools. Declaring proves nothing. The verifier cross-checks the card against the session's signed action receipts and grades each capability exercised (backed by receipts), captured (wired in the harness config), discovered (from the agent's own published descriptor) or declared-only. A capability the agent claims and never used is visibly weaker than one it used ten times. This is the self-reporting problem attacked from the other side: the agent does not get to grade itself.

The pattern

Each mechanism does the same thing. It takes a claim that a signature alone would leave as an assertion, adds a check that the signer cannot perform on its own behalf, and writes the result of that check into the signed record as a grade rather than a boolean. live versus asserted. proven versus asserted. exercised versus declared-only.

A grade is honest in a way a checkmark is not. It tells the reader which question was answered and which was left open. And it means the answer to "signed is not true" is not a rebuttal. It is: correct, and here is the field that says how far past signed this particular record got.

Why we state it this way

A verification tool that oversells becomes a liability precisely when it matters. If "verified" is read as "correct", then the first time a signed receipt records something false, the whole apparatus loses credibility, and the people who relied on it were misled by us, not by the agent. Narrow claims that always hold beat broad claims that usually do.

The reference page is What a receipt proves. The mechanisms are in the agent handshake, agent identity and capability cards.