When your software acts for you, the receipt service writes the action down: what was asked, what came back, and when. It signs that record under a published key, and the signed record is the receipt.

It is for the company that runs the agent. When an auditor, a client or the other side of a dispute asks what your software did, you hand them the receipt instead of your word.

Your software mints a receipt with an API key, or an agent with no account pays for its receipt at the door from a wallet. Either way, the signed receipt comes back in the response.

Every receipt's fingerprint joins a public log, never the receipt's content. The log is append-only: each new state must extend the state before it, so a rewritten history shows.

The log signs a statement of its state hourly, and an independent witness that we do not run countersigns it, vouching that the log only grew. Each statement is also sent for a Bitcoin timestamp, which shows the log existed no later than that point.

Anyone can fetch an inclusion proof for a receipt and check it offline. A log proves what is in it, never what was left out, and it says nothing about whether a receipt's claim is true.

The free checkers let anyone holding a receipt confirm that it is byte-for-byte what our published key signed. If a single character of the receipt were altered, the check fails.

They are for the person a receipt is handed to: an auditor, an insurer, a counterparty or any developer. Checking needs no account and no permission from us, and verification is always free.

Check a receipt in the browser in one click, or run the checker in Python or JavaScript on your own computer against the published keys. The checker prints what was proved and what was not.

The flight recorder rebuilds what an agent did, in order, from its receipts. It works offline, from files you export, and any gap in the record shows.

It is for the company that runs the agent and its risk team, on the morning after something goes wrong. It gives them the ordered, checkable record of what the agent did.

It proves what was receipted, in what order, and that nothing was altered. It does not prove that everything the agent did was receipted.

The case file gathers the receipts behind a dispute or a review into a folder that someone else can check. Inside are the receipts, a receipted record of what was spent, the mandate the agent acted under, the checkers and a plain exhibit.

It is for the moment someone else asks: a merchant, an auditor or a court, or the client who hands the folder over. The reviewer checks it offline, without an account.

A gate is the software that approves or blocks an agent's action. Decision receipts record a gate's decision after it is made, in its place in the chain of receipts.

The gate belongs to the company that runs it, never to us, and the receipt never grants a permit. It records a digest of what the gate decided, so the decision can be checked later.

It is for the company that runs a gate, and for whoever later asks whether the gate ran and what it decided.

The kit is the engine a developer installs to check receipts and to run recipes. Every recipe runs on it as a profile.

It is for a developer building with receipts, who gets the checking and the recipes in the same install.

A recipe is a ready-made job that an agent, or the person it acts for, does with receipts. Each recipe is a profile on the kit's engine, sometimes with commands of its own.

Recipes cover jobs such as receipting a window of tool calls, recording a refusal, or writing a manifest for a dataset. A developer picks the recipe that fits the job instead of building it from scratch.

They are for developers, and for the people their agents act for.

The verification domains check a claim against reference data through one API: claims about a brand, a price, a policy, compliance, brand safety and more. Every answer is minted as a signed receipt.

They are for an agent, and the developer who runs it, when a claim needs checking and the answer belongs on the record. Some domains return a verdict with a confidence score and the evidence behind it.

Send the claim to that domain's check with an API key, and the answer comes back in the response. The brand catalogue that the checks are measured against can be read without a key.

The ops feeds are the agent's operational briefing: structured intelligence events that an agent reads as part of its operating loop. Every event carries a priority, a headline, evidence and source links.

The feeds cover security, commerce, models, protocols, trust and regulation. They tell an agent what has changed: new threats to the tools it uses, shifts in brand, price and policy data, changes in the models and protocols it depends on, changes in trust scores, and new compliance deadlines.

They are for an agent and the developer who runs it. With an API key, list the feeds, then read the events of any feed, filtered by time, priority or event type.