Template · Loop: per release

No acceptance on this revision, no release

A copy-paste run card for gating releases on recorded acceptance: claims frozen beside their receipts, a plain-words change note, and an acceptance that binds this revision's root and no other.

The release went out, and then the question: who approved this version? Someone had approved a version, an earlier one. The work changed after the approval, the approval got treated as covering whatever the work had become, and the release shipped on consent nobody gave for what actually shipped. Held releases are annoying. Unheld ones are how the wrong thing reaches production with a signature on it.

This template makes acceptance revision-shaped. The twist has a name: acceptance binds the root. An acceptance receipt names the exact chain root of the revision it accepts. A new revision has a new root, so it needs a new acceptance, earned on its own record.

This is not theory. In the public Verisuff handover pilot, Revision A was accepted by the client, and that acceptance (receipt 14cb8b21) binds Revision A's root only. Hop 2 changed one claim's evidence, a Bitcoin price that moved from $82,212.68 to $73,804.35, and the changed claim was marked REASSESS while the unchanged claims carried as REUSE_SCOPED. Hop 2's release is still BLOCK_RELEASE, because Hop 2 has no acceptance of its own. The old signature did not stretch.

The run card

Copy it, swap the brackets, run it on your next release.

JOB: Gate one release on recorded acceptance
DELIVERABLE: [THE DELIVERABLE]
REVISION: [REVISION LABEL, FOR EXAMPLE: REV B]
APPROVER: [CLIENT OR OWNER 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 revision:

1. Freeze this revision's claim set. For each claim, log the claim with journal_log, naming the receipt that supports it: [CLAIM 1 AND ITS EVIDENCE RECEIPT], [CLAIM 2 AND ITS EVIDENCE RECEIPT], [CLAIM 3 AND ITS EVIDENCE RECEIPT]. A claim whose evidence changed since the last accepted revision is marked for fresh review, never quietly carried. (3 calls)
2. Save the release note with memory_remember: what changed since the last accepted revision, in plain words, including anything that got worse. (1 call)
3. Close the revision with workflow_close. The close produces this revision's chain root, which is the identity of this exact revision and no other. (1 call)
4. Hand it over with handover. Summary: [WHAT THIS REVISION IS]. Goal: [A RELEASE DECISION]. Recipient: [THE APPROVER]. Next steps: [CHECK THE CLAIMS, THEN ACCEPT OR FLAG ON THE RECORD]. Send the approver the client link from the result: acceptance and flags happen there. The public record link is read-only. (1 call: the day's free wrap-up handover)
5. Approver side: the approver opens the client link, checks the claims against their receipts, and taps Accept or Flag. The acceptance is recorded on the record and binds this revision's root.

RELEASE RULE: no acceptance on this root, no release. A changed revision starts again at step 1 and earns its own acceptance. Pickup is not acceptance, and an earlier revision's acceptance releases nothing here.

Get the Day Pass, $0.99

The budget, counted

5 calls per revision, plus the wrap-up handover. Steps 1 to 3 are 3 + 1 + 1 = 5 calls. Step 4 is the day's free wrap-up handover, and the approver's side sits on the free pickup side.

Counted against the free day: the three claim logs take journal_log's first call and 2 of the 3 shared continue calls, and the release note and the close take their own first calls. Either way, your first release gate fits the free day, with a continue to spare.

A release day with several revisions runs past it, and the Day Pass at $0.99 finishes the day's run unlimited. Teams releasing most days land on the $29 Pass. The release note is a saved note, kept 7 days on the free tier and through a pass plus 30 days; the claim entries, the close, and the acceptance record do not expire.

What the approver receives

The handover for that revision: the claim set with the receipt behind each claim, the plain-words change note, and the accept-or-flag step. They can check any claim's receipt free at zambo.dev/verify before deciding. Their acceptance, when it comes, names this revision's root. If the work changes the next day, the changed revision arrives as its own handover, and the release stays held until its own acceptance lands.

The twist: approvals usually attach to a project, a version name, or a thread. Names get reused and threads get long. A chain root cannot be reused: it is computed from this revision's exact record, so acceptance can only ever mean this one.

Frequently asked questions

Why doesn't the old acceptance cover the new revision?

Because the acceptance is a receipt bound to the earlier revision's chain root, and the new revision has a different root. In the Verisuff pilot, Revision A's acceptance (receipt 14cb8b21) binds Revision A only, so Hop 2, with one claim's evidence replaced, remains BLOCK_RELEASE until it earns its own acceptance.

Is picking up a handover the same as accepting it?

No. Pickup is free and means the record changed hands; it records continuation, not consent. Acceptance is a separate recorded act by the approver on that revision's record, and only acceptance releases the gate.

What does one release gate cost to run?

Counted on the card: 5 calls plus the free daily wrap-up handover. With the claim logs sharing journal_log it fits with a continue to spare; with steps on separate tools it fits with more room. A day of several releases 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.