Verdict
ALLOW, DENY, or ESCALATE for the proposed action.
MINDBURN LABS
Inspect surfaceProof
A log says traffic moved. A receipt proves it was authorized.
Observability describes what an AI agent did. A HELM receipt is a signed verdict bound to the effect it permitted, so you can prove the action was authorized under policy, not just observe that it ran.
A log is a message. A receipt is evidence. Evidence verifies without trusting the source.
The distinction
Description is not authorization.
A log line tells you something occurred. It does not tell you whether the action was allowed, under which policy, or by whom. When an AI agent can change a record, move money, or alter access, the question is not what happened. It is whether it was authorized, and whether you can prove it later.
A log line
- A timestamped message.
- Lives in a vendor console.
- Editable after the fact.
- Shows that traffic moved.
A HELM receipt
- A signed verdict bound to the effect.
- Verifiable offline by anyone.
- Tamper-evident content hash.
- Shows the action was authorized under policy.
What a receipt contains
Five fields, one signed record.
A receipt binds the decision to the effect it permitted. Each field is part of a canonical record that is hashed and signed, so the receipt stands as evidence on its own.
Policy hash
The exact policy the action was checked against.
Principal
The identity that proposed the effect, and its delegation chain.
Effect
The bound side effect and its scope, with before and after state hashes.
Signature
A signature over the canonical record, so the receipt is tamper-evident.
Verifies offline
Check the content hash and the signature with the public key. No dashboard, no live service.
Why it holds
Evidence you do not have to trust the source for.
A receipt is designed to be checked by someone who was not there and does not run your systems.
- The verdict is bound to the exact policy hash it was checked against.
- The effect is bound to the verdict that authorized it, with scope and state hashes.
- The record is canonicalized, hashed, and signed, so any change is detectable.
- A reviewer verifies the signature with the public key, outside any console.
Questions
Receipts and logs, in plain terms.
Isn’t my audit log already proof?
A log records that a message was written. It does not bind the action to the policy that authorized it, and it can be edited where it is stored. A receipt is a signed record of the verdict and the bound effect, so it stands as evidence on its own.
What is in a HELM receipt?
The verdict, the policy hash the action was checked against, the principal and its delegation chain, the bound effect with its scope and state hashes, and a signature over the canonical record. Anyone with the public key can verify it.
How do I verify a receipt without HELM running?
A receipt carries a content hash and a signature over a canonical form. You verify the hash and the signature offline, with no dashboard and no live service. That is what separates a receipt from a log line you have to trust.
Does this replace observability?
No. Observability reconstructs what happened across systems. A receipt proves a single consequential action was authorized under a known policy. They answer different questions; HELM records the proof at the moment of execution.
Keep reading
Follow the proof path.
Stop trusting the log. Verify the receipt.
Bring one consequential action to the boundary and check the signed verdict yourself.