Template · Loop: per approval
Every approval, frozen at decision time
A copy-paste run card for invoice approvals, payouts, and account actions: one frozen record per decision, keyed to the business key, so a double approval cannot hide inside two green runs.
The question arrives six weeks after the payment: why was this approved? And behind it, the worse one: the workflow that can succeed twice. Every check passed, both executions are green in the log, and the duplicate payment exists only as a business fact, not as an error anywhere. A log can show two approvals. It cannot show that the second one should never have happened.
This template freezes one record per money decision at decision time: the request as submitted, the checks and their verdicts, and the decision itself, all keyed to the business key the money moves under. The twist has a name: the second-record tripwire. If the same invoice, payout, or account is ever decided again, the second decision becomes a second frozen record on the same key, visible beside the first. A double approval stops being silent.
The run card
Copy it, swap the brackets, run it on your next approval.
JOB: Record one money decision, so it can be checked later DECISION: [APPROVE OR REJECT] BUSINESS KEY: [INVOICE NUMBER / PAYOUT ID / ACCOUNT ID] AMOUNT: [AMOUNT AND CURRENCY] Connect your AI to Zambo at https://zambo.dev/mcp (setup guides for your AI client: https://zambo.dev/add/), then run once per decision: 1. Pull the request exactly as submitted: amount, requester, destination, and the note attached. Log it with journal_log as received, not as summarized: the fields ride in the entry, and the entry carries a hash of the full request, binding the exact bytes. (1 call) 2. Run the checks before deciding: [CHECK 1: THE AMOUNT IS INSIDE THE LIMIT FOR THIS KEY] and [CHECK 2: NO EARLIER DECISION EXISTS ON THIS BUSINESS KEY]. Run check 2 as a memory_recall on the business key, and log check 1's verdict with journal_log beside the input it judged. (2 calls) 3. Record the decision manifest with memory_remember: the business key, both verdicts, the decision, and who or what made it. The journal entries and the close below carry the same decision on the standing record; this manifest is the index entry that ties them to the key. (1 call) 4. Close the decision with workflow_close, so the record stands alone, outside the workflow that executed it. (1 call) Once a day: 5. Hand the day's decisions to [THE OWNER] with handover. Summary: [N DECISIONS, TOTAL VALUE, K REJECTIONS]. Next steps: [OWNER REVIEWS THE REJECTIONS FIRST]. Send the owner 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 decision, across 4 tools, plus one free wrap-up per day. Steps 1 to 4 are 1 + 2 + 1 + 1 = 5 calls. Step 5 is the day's free wrap-up handover.
The free day covers the first call on each tool plus 3 continue calls: 4 + 3 = 7. Your first approval fits the free day, and part of a second one. Approvals all day runs past it by design: that volume is exactly what a pass is for.
Run approvals every day and the Day Pass at $0.99 finishes the day's run unlimited. Approve on most days and the $29 Pass covers the month of decision days.
What the owner receives
One daily handover of the day's decisions, and a standing record per decision underneath it. Anyone checking later can see: the request exactly as submitted, the verdict the limit check returned, the verdict the duplicate check returned, the decision, and the key it moved under. If a second record ever appears on the same key, both records sit side by side, and the question answers itself. The standing record stands on the journal entries, the close, and the daily handover, which do not expire; the manifest note is kept 7 days on the free tier and through a pass plus 30 days.
The twist: ordinary audit logs record that an execution happened. This record is keyed to the business fact, so a repeated decision on the same invoice or payout cannot hide inside two green runs. The duplicate becomes visible as a pair of records, not discoverable only in a bank statement.
Related
Frequently asked questions
What happens when the same invoice gets approved twice?
Each approval freezes its own record on the same business key. The second approval's own duplicate check runs against the key, and even if the payment executes, the pair of records sits side by side in the open. The duplicate is provable from the records, not inferred from a bank statement weeks later.
Who can check a decision record later?
Anyone with the record. The saved request, the check verdicts, and the decision are bound by verifiable AER-1 receipts, and any receipt can be recomputed free at zambo.dev/verify. The record stands outside the workflow, so it survives the workflow being edited or deleted.
What does one approval cost to run?
Counted on the card: 5 calls across 4 tools per decision, plus one free wrap-up handover per day for the batch. The free tier (first call per tool plus 3 continues, 7 calls) covers a first approval. A full day of approvals 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.