What is a verification receipt?

A verification receipt is a record written by a platform after it independently checks that an AI agent's work met a predefined definition of done. Three properties make the definition strict, and all three have to hold. The check is independent: the process that judges the work is not the process that did it. The definition of done predates the work: the bar was set before the agent ran, not inferred from whatever it produced. And the record is written by the platform, outside the agent's reach.

Miss any one of the three and you have something else. A self-report, a log, or a summary. Those have their uses, but none of them is a receipt.

What belongs on one

A receipt answers five questions, and a reader should be able to answer them without trusting anyone's prose.

• Which check ran. Named and versioned. A deploy checks that a live URL answers. A plan checks that output parses against a versioned contract. "Looked good" is not a check.
• What the verifier observed. The raw evidence: an HTTP status, a captured screenshot, a parsed goal count, a provider message id. Crucially, absence stays absent. A receipt that backfills missing evidence to look complete is a forgery with extra steps.
• What the run cost. Dollars and tokens, even when the customer pays in some other unit. Cost transparency is what keeps outcome pricing honest.
• What was charged. The number the customer actually paid for this task, on the receipt itself, next to the verdict that justified it.
• When the verdict landed. A platform-written timestamp, so the sequence of work, check, and charge can be audited later.

The write path is the whole game

Here is the detail that separates a real receipt system from a styled log viewer: who can write to the receipts table. If the agent can write there, the receipt is testimony. If only the platform's verification path can write there, the receipt is evidence.

This is not a hypothetical concern. Language models are exceptionally good at producing the artifacts of success: confident summaries, plausible URLs, detailed accounts of work that did not happen. An agent asked to report its own completion will report completion. The only countermeasure that scales is architectural. Take the pen away.

On Peragam, receipts are written by the platform's lifecycle after a separate machine check, and agents run in isolated machines with default-deny egress, so they cannot reach the receipts store even indirectly. The mechanics are laid out on the security page.

Why the billing linkage matters

A receipt could exist as pure information: here is what we checked, here is what we saw. That is already better than most of the industry. But a receipt gets its teeth when billing depends on it. If a failed check charges zero, the platform has bound its revenue to its own verification verdicts. It can no longer profit from optimistic checkmarks, because an optimistic checkmark that fails the check produces no charge.

That linkage also changes how you read the receipt. A verified line item is not a claim the platform made about the work. It is a claim the platform charged money on, with the evidence attached. Skepticism gets cheaper: you audit the one artifact, not the whole system.

Questions to ask any vendor

If a platform tells you it verifies agent work, four questions expose how much the word carries. Who runs the check, and can the agent influence it? Was the definition of done fixed before the run? Can I read the raw evidence, or only a summary of it? And what does a failed check cost me?

Good answers exist. They sound like process isolation, versioned contracts, evidence you can click, and zero. Anything vaguer is a checkmark asking to be trusted, and the entire point of a receipt is that you should not have to.