Template · Loop: per batch
What left the workflow, provable
A copy-paste run card for lead deliveries: the delivered set frozen row by row, the rejected duplicates listed with reasons, and counts that reconcile on the record itself.
Every node was green. The sync ran, the batch delivered, the counts matched. Weeks later the client opens a row and the score reads 71. The copy that left your workflow said 17. Neither side is lying, and neither side can prove anything, because what was actually delivered was never frozen anywhere. The argument is not about the value. It is about the fact that there is no record of the value.
This template freezes the delivered set at handover: every row, with its values as they left the workflow, plus the rows that did not make it. The twist has a name: the duplicate-rejection receipt. Duplicates and invalid rows are not silently dropped. They are listed inside the delivery record, with the reason, so the count arithmetic (in, rejected, delivered) can be checked by the client row by row.
The run card
Copy it, swap the brackets, run it on your next batch.
JOB: Deliver one lead batch to [YOUR CLIENT] BATCH ID: [SOURCE AND DATE, FOR EXAMPLE: TYPEFORM-EXPORT-2026-11-14] EXPECTED COUNT: [N LEADS IN THE EXPORT] RECIPIENT: [CLIENT NAME] Connect your AI to Zambo at https://zambo.dev/mcp (setup guides for your AI client: https://zambo.dev/add/), then run once per batch: 1. Pull the batch exactly as exported. Log it with journal_log before touching anything: the source, the row count, and a hash of the raw export. The batch itself rides the delivery in step 5, frozen as the record's delivered file beside that hash. (1 call) 2. Validate the batch: [CHECK 1: DUPLICATES ON EMAIL AND PHONE] and [CHECK 2: REQUIRED FIELDS PRESENT]. Log each check's verdict with journal_log: how many rows it accepted, and the rows it rejected, each with its reason. (2 calls) 3. Record the batch manifest with memory_remember: the batch id, the three counts (in, rejected, delivered), and the pull and verdict entries it rests on. The delivered rows themselves freeze as the handover's delivered file in step 5, beside the export hash logged in step 1. (1 call) 4. Close the delivery with workflow_close. (1 call) 5. Hand it to [YOUR CLIENT] with handover: the delivered set rides as the record's delivered file, its hash the one logged in step 1, and the rejected rows ride with their reasons. Summary: [N IN, K REJECTED AS DUPLICATES, M DELIVERED]. Goal: [THE CLIENT IMPORTS THE BATCH]. Recipient: [YOUR CLIENT]. Next steps: [CLIENT CONFIRMS THE IMPORTED COUNT MATCHES M]. Send the client the client link from the result; the public record link is read-only. (1 call: the day's free wrap-up handover)
The budget, counted
5 calls per batch, across 3 tools, plus the wrap-up handover. Steps 1 to 4 are 1 + 2 + 1 + 1 = 5 calls. Step 5 is the day's free wrap-up handover.
Counted against the free day: the pull log and the two verdict logs take journal_log's first call plus 2 of the 3 shared continue calls, and the manifest and the close take their own first calls. Your first batch fits the free day.
A second batch the same day runs past the free day, and a delivery day for several clients is exactly the Day Pass shape: $0.99 finishes the day's batches unlimited. Batches most days means the $29 Pass. The batch manifest is a saved note, kept 7 days on the free tier and through a pass plus 30 days; the pull and verdict entries and the delivery record do not expire.
What your client receives
The handover for the batch: the delivered rows as the record's delivered file, frozen beside the hash logged when the batch was pulled, the rejected rows with their reasons, and the three counts that have to agree (in, rejected, delivered). When a value later differs on the client's side, both sides compare against the frozen copy. The record shows what left the workflow, so the argument moves to where the change happened, which is a question with an answer.
The twist: pipelines usually delete duplicates quietly, which makes the delivered count unexplainable forever. Here the rejections are part of the deliverable. A client who can see what was rejected, and why, never has to wonder what else quietly disappeared.
Related
- All handover templates
- The dispute kit: when agent work is questioned, evidence settles it
- The $0.99 Day Pass
Frequently asked questions
What happens to duplicate leads in a batch?
They are rejected in the open. The validation step saves a verdict per row, and the rejected rows are frozen inside the delivery record with the reason, next to the accepted rows. The counts (in, rejected, delivered) always reconcile on the record itself.
A value differs on the client's side. Now what?
Compare the client's copy against the frozen delivered values in the handover. The frozen copy shows what left the workflow, value by value, so the difference is located: it changed on import, in the client's system, or it never differed. Each answer ends a different argument.
What does one batch cost to run?
Counted on the card: 5 calls across 3 tools plus the free daily wrap-up handover. The free tier covers a first batch: journal_log's first call plus 2 shared continues, with first calls for the manifest and the close. A multi-client delivery day is Day Pass shape: $0.99, unlimited for 24 hours.
Who built Zambo
Brennan Zambo created Zambo, the verifiable work layer for AI, and AER-1, the agent execution receipt standard (IETF Internet-Draft draft-zambo-aer1-26). Every template in this pack runs on that receipt format. A verifiable receipt proves the saved result was not changed since it was saved, and anyone can check one free at zambo.dev/verify. It does not prove the result was right. That boundary is the point: the record settles what happened, so people can argue about the work instead of about memory.