Template · Per entry, per build
Prove the work, not the video.
A copy-paste run card for hackathon entrants: journal the build as it happens, wrap the final state as a handover to the judges, and put a checkable receipt chain in your submission where the trust-me paragraph used to go.
Judging runs on evidence nobody can replay. Your demo video shows the happy path, shot on the third take, against the one input that works. A judge who wants to know what you actually built, when you built it, and what broke along the way has nothing to open: a repository whose history can be rewritten, screenshots with no timestamps anyone can check, and your word. Every entrant's word sounds the same, so judging quietly becomes a contest of who presents best, not who built best.
This template gives your entry a build record instead. The twist has a name: prove the work, not the video. Every milestone is journaled as it happens and lands in a chain of verifiable AER-1 receipts, and the submission links the record, not a claim about the record.
The run card
Copy it, swap the brackets, start it with your first build session.
JOB: [YOUR ENTRY, IN ONE LINE: WHAT IT DOES] RUNS: once per build session, wrapped once at submission OWNER: [THE JUDGES READING YOUR SUBMISSION] Connect your AI to Zambo at https://zambo.dev/mcp (setup guides for your AI client: https://zambo.dev/add/), then, each session: 1. Read where the last session stopped with memory_recall: [LAST SAVED STATE], [OPEN BUGS], and [NEXT MILESTONE]. (1 call) 2. At each working milestone, log it as it happens with journal_log: the milestone, what changed, and a hash of the result, for example a passing test run, a live endpoint, a working screen. When a path dies, log the dead end too: it is part of the build, and judges know real builds have them. (1 call per milestone) 3. Save the session's end state with memory_remember: what works now, what does not yet, and the next milestone. Never edit a past state; the next session writes a new one. (1 call) 4. Close the session with workflow_close. (1 call) Once, at submission: 5. Hand the whole build to the judges with handover. Summary: [WHAT THE ENTRY DOES AND ITS FINAL STATE]. Goal: [WHAT THE JUDGES ARE DECIDING]. Next steps: [HOW A JUDGE REPLAYS THE BUILD FROM THE RECORD]. Send the judges the client link from the result: every milestone and its receipt rides in the record behind that link. The public link is the read-only record. (1 call: the wrap-up handover, free once a day, and pickup is always free)
The budget, counted
A focused build day, one session, costs 7 counted calls: 1 recall, 4 journaled milestones, 1 saved end state, 1 close, plus the wrap-up handover at submission.
The free day covers the first call on each of the card's tools plus 3 continue calls shared across tools. Counted across memory_recall, journal_log, memory_remember, and workflow_close: the first milestone spends journal_log's first call, milestones two, three, and four spend the 3 continues, and recall, the end state, and the close each take their own first call. That is 7 calls: a focused build day, one session four milestones deep, fits the free day exactly. A second session the same day spends calls the free day does not have.
A real final day does not stop at four milestones. Past the fourth journal entry, every added milestone needs a pass, and the honest tool for submission day is the Day Pass at $0.99: unlimited for 24 hours, bought to finish the entry already in flight. Retention, stated plainly: journal entries, handovers, and receipts do not expire, so the record a judge opens weeks later is complete; saved working notes are kept 7 days on the free tier and through a pass plus 30 days.
What the judges receive
One link in your submission. Behind it: the build, session by session, each milestone with the receipt that was minted when it happened, the dead ends included, and the final state your entry actually reached. A judge checks any receipt free at zambo.dev/verify and gets the same answer you would: the saved result was not changed since it was saved. Your video can still sell the vision. The record carries the proof.
The twist: a demo shows the best run, edited. The record shows every run, including the failures, each one frozen when it happened. Judges can tell the difference, and an entry that volunteers its dead ends is hard to argue with.
Related
Frequently asked questions
What do I paste into my hackathon submission?
The handover link, plus one line saying what it is: the build record, with a verifiable AER-1 receipt on every milestone, checkable free at zambo.dev/verify. Judges open one link and can replay the build session by session instead of taking the demo video's word for what happened.
Does the free tier cover a whole hackathon?
A focused build day fits exactly: one session, 7 counted calls, recall plus four journaled milestones plus the saved end state plus the close, inside the free day's first calls and 3 shared continues, with the wrap-up handover free. A long final day, more sessions or more milestones, runs past that, and that is what the $0.99 Day Pass is for: one day, unlimited.
My build used several AI tools. Does the record still hold together?
Yes. The journal and the handover follow the job, not the app. Connect each AI you build with to the same Zambo endpoint, and every session adds its milestones to one chain, so the judges see one build, not three apps' separate histories.
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.