Template · Loop: per client, per week
Freeze the inputs, not the PDF
A copy-paste run card for weekly client reporting: pull the sources, freeze the exact input set, build only from the freeze, and hand over an edition whose numbers stay recheckable after the live data moves on.
The client relies on the weekly report. It is how they decide what to reorder, what to stop advertising, what the week was worth. Three weeks after an edition goes out, one number looks wrong, and the PDF says what it says, but the inputs are gone: the store has new orders, the ad account has new spend, and the exact numbers that produced that edition no longer exist anywhere. The report cannot be rechecked, so it cannot be trusted, and the doubt spreads to every edition before it.
This template freezes the inputs, not the PDF. The twist has a name: freeze the inputs, not the PDF. Every edition carries the raw pulls it was built from, frozen at pull time, so any figure in the report can be recomputed later, by the client, without you.
The run card
Copy it, swap the brackets, run it on this week's edition.
JOB: [THE REPORT NAME] for [YOUR CLIENT] EDITION KEY: [CLIENT]-[WEEK START DATE] 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 edition: 1. Pull each input source as it stands right now, and log each pull with journal_log as it lands: the source, the pull time, the row count, and a hash of the raw export. [SOURCE 1: ORDERS EXPORT], [SOURCE 2: REFUNDS], [SOURCE 3: AD SPEND], [SOURCE 4: STOCK OR INVENTORY]. (4 calls) 2. Record the edition manifest with memory_remember under the edition key: the four pull entries, the pull times, and the exact filters and date ranges used. The journal entries are the freeze; this manifest is the index that ties them to the edition. (1 call) 3. Build the report from the frozen pulls only, never from a fresh pull. The report and its headline numbers ride the handover in step 5 as the edition's delivery, so this step spends no call of its own. (0 calls) 4. Close the edition with workflow_close. (1 call) 5. Hand it to [YOUR CLIENT] with handover: the report rides as the delivery on the record, and the four raw pulls are named as its delivered files, each tied to the hash its pull logged in step 1. Summary: [THE THREE HEADLINE NUMBERS]. Goal: [WHAT THE CLIENT DECIDES FROM THIS REPORT]. Recipient: [YOUR CLIENT]. Next steps: [THE CLIENT'S NEXT DECISION OR QUESTION]. 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
6 calls per edition, plus the wrap-up handover. The metered steps are 1, 2, and 4: 4 + 1 + 1 = 6 calls. Step 3 builds from the freeze and spends no call, because the report rides the handover itself. Step 5 is the day's free wrap-up handover.
Counted against the free day, the first edition fits, exactly: the four pull logs take journal_log's first call plus all 3 shared continue calls, and the manifest and the close take their own first calls, so the free day is spent exactly and nothing is owed. If your pulls run through separate source tools instead of one log, the same edition fits with room to spare. Your first client's first report fits the free day.
Run it for every client, every week, and the Day Pass at $0.99 finishes report day unlimited. A full book reporting weekly is $29 Pass shape.
What your client receives
The handover for that edition: the report and its headline numbers, and underneath them the frozen input set: each pull logged at pull time with its hash, its row count, and its filters, and the raw pulls carried as the record's delivered files. When a number is questioned three weeks later, the client recomputes it from those delivered pulls, or you do, on the same record, and the logged hashes prove the copies on the record are the pulls the edition was built from. Editions chain side by side, so a quarter of reports is a quarter of frozen input sets, each one recheckable on its own. The edition manifest is a saved note, kept 7 days on the free tier and through a pass plus 30 days; the pull entries, the receipts, and the edition's record do not expire.
The twist: a saved PDF proves what the report said. Frozen inputs prove what the report was built from. Only the second one lets anyone recheck a number after the live data has moved on, and live data always moves on.
Related
Frequently asked questions
Why freeze the inputs instead of just saving the PDF?
The PDF preserves the conclusion. The inputs preserve the ability to check it. Once the store, the ad account, or the stock sheet changes, an unfrozen report can never be recomputed. A frozen input set can, at any later date, by either side.
Can a client recheck a number from three weeks ago?
Yes. The edition's handover carries the raw pulls, the pull time, and the filters, bound by verifiable AER-1 receipts. Recompute the figure from those inputs, or check any receipt free at zambo.dev/verify. The number either reproduces or the difference is locatable.
What does one weekly report cost to run?
Counted on the card: 6 calls plus a free wrap-up handover. The first edition fits the free tier exactly: the four pull logs spend journal_log's first call and the 3 shared continues, and the manifest and the close take their own first calls. Report day for several clients 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.