What a receipt can prove

Hello again from the engineering team.

When an agent asks before it acts, there are two records worth keeping: what was agreed, and what was done. The first one is easy to keep, because we are part of it. The second one is hard, and this post is about how hard. It covers what a receipt in Deliverd claims, what it does not, and why the evidence pack says the same thing in its own words.

The shape of a gated action

An agent wants to do something consequential: publish a report to a client, send a payment instruction, delete a batch of records. It calls the gate with the action, the input, where it is going and, if there is a file involved, the file's SHA-256 hash.

Policy answers, or sends it to a person. If the answer is yes, the agent gets a permission. A permission is narrower than "yes, go ahead". It covers exactly that destination and that artifact. It is valid until a time, and usually for one use.

Then the agent acts, and reports what it did. That report is the receipt.

What we check

When the receipt arrives, we hold it against the permission:

• A different hash is refused (approval_invalidated). The thing that was approved is not the thing being reported.
• A different destination is refused (destination_mismatch).
• A second use is refused (gate_used). A permission for one use is spent.

In every one of those cases, nothing is recorded as done.

An agent that might be retried can claim the use before it acts, with phase: "started". A second copy of the same agent is then told the permission is already spent before it does anything. It finishes with completed or failed.

Three levels of truth

Every receipt states how much we actually checked, because they are not all the same:

Receipt	What it means
Verified	Deliverd carried the act out itself, for example by making a staged report version live. We saw it happen because we did it.
Hash matched	The agent reported doing it, and the hash it reported matches the one that was approved. The right thing was named; we did not see the act.
Reported	The agent's word. Nothing was approved by hash, so there was nothing to compare it with beyond the destination and the uses left.

We could have put a green tick on all three. It would look better on a dashboard, and it would be untrue for two of them. An auditor reading the record a year from now needs to know which receipts we witnessed and which we were told about.

Where the boundary sits

Your agent reports what it intends to do, policy answers, and your agent then performs the action itself. We hold what it reports to what was agreed, and refuse a report that differs. But except for the acts we carry out ourselves, we do not see the act.

An agent that lies is lying to its own runtime. That is the boundary every client library already has. It is still a boundary, though, and we would rather say where it is than let anyone assume it isn't there. What the gate gives you is a question asked before the act, answered by someone other than the caller, and written down either way.

The platform your agent runs on keeps its own confirmations and safety checks. A permission from us adds to those. It never replaces them.

Revoking, and what cannot be undone

An administrator, or somebody who approved it, can revoke a permission that has not been used yet. They must give a reason, the agent is told, and any later report of acting on it is refused.

A permission that has been used cannot be revoked. What was done stands in the record. Revoking it afterwards would not undo the payment or unsend the report. It would only make the record disagree with what happened.

The evidence pack says it too

Owners and administrators can download everything recorded about a flow, a report or a gate as an evidence pack, in PDF, JSON or CSV. It includes:

• who asked, who decided and under what authority
• what scope they saw
• the receipts, each at its level
• what was not checked

It also carries an integrity block, a SHA-256 digest of the pack itself. We are careful about what that digest claims. It shows the pack has not been changed since it left Deliverd. It says nothing about the records inside it. What stands behind the records is that our audit log refuses updates and deletions at the database level. The history is tamper-evident, not "immutable" (a word we do not use, because a database administrator with enough access can always do more than an application can stop).

The pack states both of those things in its own words, so anybody reading it without us in the room is not left to guess.

What the record does not show

Each gate's page ends with a section called What this record does not show. It lists the milestones the record reached and greys out the ones it did not. Under that, it says in a sentence what we did not check, for this gate in particular:

• The agent reported acting on the artifact whose hash was approved, and Deliverd checked the hash. The act itself took place outside Deliverd and is the agent's report.
• The agent reported carrying out the act. Deliverd had nothing to check the report against.
• The artifact is not held by Deliverd: its hash and classification are as the agent declared them.
• No policy rule matched, so the organisation's default applied: a person was asked.

Only the sentences that apply appear. One appears on every gate: Deliverd records the organisation's authorisation. The platform the agent runs on applies its own safety and confirmation controls, which this record does not describe.

We would rather the record were shorter and true than longer and reassuring. If you are building on the gate and the levels above are not enough for what you need to prove, tell us. Moving more acts into "verified", by carrying them out ourselves, is the obvious next step, and we would like to know which ones matter to you first.

Deliverd is the human layer for AI agents. The gate is documented in full in the developer docs.