Check where your AI's numbers come from

“Pro brought in $594 last month.” An agent can tell you how it got that, and it may be right. But an explanation is the agent’s account of what it did. A receipt is a record of it: the SQL that actually ran, the exact data it read, and the rows that came back, kept as a link you can open later or send to someone else.

rho makes one when an agent queries a table in rho and asks for a receipt. You don’t have to trust the agent’s calculation: you can look at what it ran.

A real receipt

examples/invoices is a table of made-up invoices: one row each, with its plan, amount, status and the day it was paid. Asked for last month’s revenue by plan, with a receipt, Claude answered:

Claude: Pro brought in the most, $594 from 6 invoices, then Team at $392 and Starter at $150. Receipt

Open the receipt: it’s live, and anyone can open it. It says who ran the query, for which task and when, and that it read examples/invoices v1. Then the query:

SELECT plan, sum(amount_usd) AS revenue, count(*) AS invoices
FROM "examples/invoices"
WHERE status = 'paid'
  AND paid_at >= DATE '2026-10-01' AND paid_at < DATE '2026-11-01'
GROUP BY plan
ORDER BY revenue DESC

And what it answered:

What the receipt records

• The SQL exactly as it ran, so you can see the filter, the date range and how it grouped.
• The version of each table it read, such as examples/invoices v1. A version never changes once it’s made.
• The rows the agent got back, all of them, or the first ones when there were more than it asked for, and the page says so.
• Who ran it and when: the agent by the name its app gives (Claude, ChatGPT, Cursor), and the task label the agent gave the query, if it gave one.

It doesn’t record the question you asked, or what the agent wrote around the figure: those stay in the chat, next to the link.

The original result doesn’t change

The receipt keeps the result as the agent got it, and the versions it read never change. Open it next month and the original answer is exactly what the agent saw, even if the tables have changed since.

Rechecking against updated data

When a table it read has a newer version, the receipt page runs the same SQL on the latest versions as it opens, and shows that below the original:

• Still true: the query gives the same answer on today’s data.
• The answer has changed: it shows what the query answers today, with the cells that read differently marked.
• No longer runs: for example, a column the query reads was removed, and it says why.

After the report, one of October’s Pro invoices was refunded, and examples/invoices got a version 2. Open the receipt now, and it says the answer has changed: below the original, it shows today’s answer, with Pro’s two cells marked. Side by side:

The check runs once for each new version, and the page keeps its answer, so opening a link many times doesn’t run the query many times. A table the SQL names by version, such as "examples/invoices@1", stays that version: a receipt whose tables are all named that way is never rechecked.

If a table it read was itself saved from a query, and the tables under that one had changed by then, the receipt says the rows it read may have been out of date. See Tables saved from a query.

What a receipt can and can’t establish

A receipt makes a calculation inspectable and reproducible: the same SQL on the same versions gives the same rows. That’s not the same as correct. It doesn’t show that:

• the data was right. If an invoice is missing from the table, the sum is wrong, and the receipt faithfully shows the wrong sum;
• the SQL was the right query. “Last month” by paid_at and by issued_at are different numbers, and so are revenue before and after refunds;
• the agent understood the question. You asked for revenue; it may have summed something else;
• outside sources were true, when the table came from research on the web.

What it does is let you, or someone you send it to, check each of these: read the SQL, see which version it read, and run it again. A figure you can check is not yet a figure that’s right, but it’s the one you can find out about.

Sharing and privacy

• Anyone with the link can open it, without signing in, the way a public table’s link works. Links aren’t listed anywhere, so people need the link to find it.
• It shows the SQL, the paths and versions of the tables it read, and the result rows. The result can itself be sensitive, even though the tables stay private: a receipt of revenue by customer shows revenue by customer. Treat it like sending the result.
• The tables’ other rows stay private. Nobody can open the tables through a receipt; only people signed in to your workspace can follow its table names to the tables.
• Revoke it from the receipt’s page, signed in to your workspace, and the link stops working for good. The Receipts page of the rho app lists all of your workspace’s receipts. A receipt also stops working while a table it read is in the trash, and for good once that table is deleted forever.

How to get a receipt

An agent makes one by calling query with receipt on (MCP tools). rho’s instructions to agents ask them to do it for each figure they state from a query, and to put the link beside the figure. That’s a request, not a rule: whether an agent follows it depends on the agent. To be sure, ask:

Using the data in rho, calculate revenue by subscription plan for last month. Include a receipt showing the SQL and input table versions.

The agent’s connection to rho has to be allowed to write, as a receipt is a link anyone can open; a read-only connection can query but not make one. And the data has to be in rho: an agent saves it there, you upload a file, or the agent imports one from a URL. See the Quickstart, and Receipts in the docs.