Template · Per workflow delivery

“It stopped working.” Check the record.

A copy-paste run card for freelancers who deliver n8n workflows to clients: freeze the workflow exactly as delivered, hand it over with named account owners, and let every later question start from the record instead of from memory.

You deliver the workflow on a Tuesday. It runs clean for three weeks. Then the message lands: it stopped working. What changed? Someone on the client's team added a node. A credential expired. The account the workflow runs under changed hands. You cannot show any of it, because the delivered state was never frozen: the workflow you open today is whatever it has become since, and the delivery you remember is the delivery the client disputes. So the fix starts with archaeology, the blame lands on the freelancer by default, and the hours are yours.

This template freezes the delivery before any of that can happen. The twist has a name: the baseline never moves. What was delivered is written down once, receipted, and signed; every touch after delivery is a new row, so the changes-since-delivery list writes itself.

The run card

Copy it, swap the brackets, run it at every delivery.

JOB: [THE WORKFLOW: ITS NAME AND WHAT IT DOES FOR THE CLIENT]
RUNS: once per delivery, then one log line per touch after
OWNER: [THE CLIENT, WHO SIGNS OFF]

Connect your AI to Zambo at https://zambo.dev/mcp (setup guides for your AI client: https://zambo.dev/add/), then, at delivery:

1. Read the engagement's standing facts with memory_recall: [CLIENT], [WHAT WAS AGREED], and [THE ACCOUNTS THE WORKFLOW TOUCHES]. (1 call)
2. Freeze the delivered state with journal_log: the workflow name, its version or export hash, the trigger, and each node that calls an outside service. This row is the delivery baseline. It is never edited. (1 call)
3. Save the delivery record with memory_remember: every account the workflow uses, with its named owner, where each credential lives (the vault or system name, never the secret itself), and the changes since kickoff the client approved. (1 call)
4. Close the delivery with workflow_close. (1 call)
5. Hand the delivery to the client with handover. Summary: [WORKFLOW NAME, WHAT IT DOES, ITS FROZEN STATE]. Goal: [WHAT THE CLIENT IS ACCEPTING]. Next steps: [HOW THE CLIENT FLAGS A PROBLEM AGAINST THE RECORD]. Send the client the client link from the result: the client signs off or flags inside that link, and the sign-off binds exactly this frozen state. The public link is the read-only record. (1 call: the day's free wrap-up handover)

After delivery, per touch:
6. Every maintenance fix or client-requested change gets one new journal_log row naming what changed and who asked for it. The baseline row is never edited, so the record always answers: delivered state, then every change since, in order. (1 call per touch)

Get the Day Pass, $0.99

The budget, counted

One delivery costs 4 counted calls, plus the free wrap-up handover: recall, the frozen baseline, the delivery record, and the close, each the first call on its own tool.

Counted against the free day, one delivery fits exactly: four tools, four first calls, no continues spent, and the wrap-up is the day's free handover. The second delivery the same day repeats all four tools and needs 4 continues, and the free day holds 3. That gap is the honest shape of a delivery day: the Day Pass at $0.99 makes the day unlimited, and a freelancer delivering every week lives on the $29 Pass.

Retention, stated plainly: journal entries, handovers, and receipts do not expire, so the weeks-later question is answered by the parts that never lapse. The delivery record is a saved note, kept 7 days on the free tier and through a pass plus 30 days, which is one more reason a working freelancer's deliveries sit behind a pass.

What the client receives

A handover they can open without you: the workflow as delivered, frozen; every account it touches with a named owner; the changes approved since kickoff; and a sign-off that binds that exact record. When something breaks three weeks later, the client can see the same record you see. The first row that differs from the baseline is where the conversation starts, and it starts there for both of you.

The twist: an unfrozen delivery drifts, and every drift becomes an argument about whose memory is right. A frozen baseline never moves. What changed stops being a negotiation and becomes a lookup.

Frequently asked questions

What does the client actually sign at delivery?

The frozen state inside the handover, through the client link only they hold: the workflow as delivered, its account owners, and the changes approved since kickoff. Acceptance binds exactly that record, so a later dispute is measured against what was signed, not against either side's memory.

The client says it stopped working three weeks later. What do I open?

The delivery handover. First the frozen baseline row: the workflow exactly as delivered. Then every touch logged after it. The first entry that differs from the baseline is where the answer starts: a changed node, an expired credential, a new account owner. The argument about what changed becomes a lookup.

Do I put the client's credentials in the record?

Never the secrets. The record holds owners and locations: which account, whose name it is in, and where the credential lives, for example the client's own password vault. That is what a handover needs when someone leaves or an access question lands, and it is safe to sign.

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.