The short answer
A pipeline is a chain of saves: extract saves a batch, transform saves a cleaned batch, load saves rows. The question after a bad run is never whether the job ran; the logs say it ran. The question is what each stage saved, and a log line saying "stage complete" is a claim, not a record. A receipt is the record: the exact saved bytes, their sha-256 digest, and the time the call ran, issued by the endpoint at the moment of the call, in the AER-1 format specified by the IETF Internet-Draft draft-zambo-aer1-26.
Scope, stated once: an agent receipt is a record of one ai agent tool call that anyone can check: it keeps the exact saved bytes and their sha-256 digest, and it proves the result was not changed since it was saved, not that it was right.
With a receipt per stage, a wrong downstream count stops being an argument. Walk the stages in time order, recompute each digest, and compare what each stage saved against what the next stage received. The stage where the records stop matching, or where a receipt is missing, is where the records went.
Where records quietly disappear
| Stage habit | What it does to records | What the run reports | What a per-stage receipt shows |
|---|---|---|---|
| A transform skips malformed rows | Bad rows vanish instead of failing the run | Success, with a smaller output than input | The saved output itself, so the shortfall is countable |
| A join drops unmatched keys | Rows with no match never reach the next stage | Success | Both sides of the join as saved records, comparable after the fact |
| A retry writes a partial batch twice | Duplicates land, or the second write overwrites the first | Success after retry | Every attempt receipted, including rejected calls, in time order |
| An agent summarizes the stage in chat | The summary replaces the data as the only record | A confident paragraph | The saved bytes behind the summary, checkable by anyone |
The pattern is the same in every row: the job-level signal stays green because nothing was assigned to keep the record-level truth. Receipts assign it, mechanically, at the moment each call runs.
Worked example: one stage, one saved record, checked
Here is a real stage save from the public Zambo stream on October 25, 2026. The call ran the write tool, the stage that persists a result, at 2026-10-25T17:19:16Z. Its receipt sits at zambo.dev/run/4bf92401-3bcd-4bea-a1f7-77021cec71be and carries the saved result digest sha256:2fb3445d55dca400769e0ff10332f774a5f605d75430b70bd60fb5b05c85a525.
Checked before this page was published: the verification endpoint at zambo.dev returned verified for this receipt, with the recomputed digest matching the saved digest. That is the whole pipeline habit in miniature. If a later stage, a teammate, or an auditor asks what this stage saved, the answer is not a recollection. It is this record, and it either recomputes or it does not.
Read it honestly: this receipt covers one stage's saved record. A full pipeline gets one receipt per stage, and the chain of them is what makes a lost batch findable. One receipt proves one save; the sequence proves the pipeline.
How to receipt a pipeline, stage by stage
- Route each stage through the endpoint. Add Zambo to the AI or agent running the stage, one MCP connection at zambo.dev/add. The endpoint is https://zambo.dev/mcp, with 153 tools total and 35 on the default surface.
- Let every call receipt itself. There is no extra step to remember: the receipt is issued as the call runs, including calls that fail or are rejected, so retries show up as their own records.
- Keep the receipt links with the run. The links are the run's evidence. Attach them to the job record, the ticket, or the delivery, the same way you would attach a build number.
- When a count comes out wrong, walk the chain. Recompute each stage digest at zambo.dev/verify in time order. The first stage whose saved record does not match what the next stage consumed is the stage to fix.
Starting costs nothing: 20 free calls per day, then you upgrade. A Day Pass is $0.99 USDC on Base for 24 hours when a single heavy run needs full access.
What the receipt does not do
A receipt proves the saved result was not changed since it was saved. It does not prove the transform logic was right, the source data was complete, or the schema was the one you wanted. Those stay engineering questions, answered by tests and review. What changes is the order of operations: first confirm you are looking at what the stage actually saved, then judge whether what it saved was correct. Without the receipt, teams routinely debug a summary of the data instead of the data.
Questions, answered
How do I check what a data pipeline stage actually saved?
Open the receipt for that stage and recompute the sha-256 digest of the saved result, or paste the receipt link into zambo.dev/verify. If the digest matches, the record you are reading is the record the stage saved. If a stage has no receipt, that stage is the gap to investigate.
Why do data pipelines lose records silently?
Most pipeline stages report success at the job level, not the record level. A transform can skip malformed rows, a join can drop unmatched keys, and a retry can write a partial batch, while the run still ends green. Without a saved record per stage, there is nothing to compare against when the counts come out wrong downstream.
What does a pipeline receipt prove, and what does it not prove?
It proves the saved result was not changed since it was saved, because anyone can recompute the digest of the exact saved bytes. It does not prove the transform was correct. Correctness still takes tests and review; the receipt makes sure the thing you are reviewing is the thing the stage actually produced.
Do failed or rejected stage calls get receipts too?
Yes. On Zambo every call issues a receipt, including calls that were rejected, so a pipeline run shows its failed attempts alongside its successes. A stage that retried three times leaves four records, not one tidy success.