What should I archive when an AI project ends?
Archive five things under one manifest: the project's job records with their exports, the final handover and its recorded acceptance, the financial set (contract, change notes, invoices), the access changes made at close (connections revoked or transferred), and a one-page map naming where each item lives and how long it is kept.
Project archives fail in the gap between saving everything and finding anything. Drives fill with unsorted exports while the three items a future question actually needs, the final acceptance, the money trail, and the record map, exist nowhere in particular. The manifest-first method inverts the work: write the one-page map first, then archive exactly what it names.
The records themselves export from the job system: every job's steps and receipts, with the final handover at the top of the pile because it is the artefact clients, auditors, and future colleagues will ask for first. The financial set ties the archive to the money: the agreement, every change note, and the invoices matched to their jobs, which is the set your accountant and any payment dispute will draw on. The access set is the one most often forgotten and most painfully missed: which agents and connections touched the project's systems, and what was revoked, transferred, or left live at close, with the decision recorded.
Set the retention per class from your schedule, name the archive's owner, and store it in two places the project team does not have to be alive to access. An archive with a map, an owner, and a retention date is an asset. A folder named "final" is a hope.
Template: the project closeout manifest
Project, client, close date, archive owner. Item 1: final handover link plus export location. Item 2: all job records, export location, count. Item 3: financial set (agreement, change notes, invoices), location. Item 4: access changes at close (revoked, transferred, left live with reason), recorded by name. Item 5: retention per class, with review or deletion dates. Item 6: open items carried forward, if any, with owners. Storage: two locations named. The manifest is page one of the archive; everything else is an appendix to it.
Worked example
Item 1 in its live form: a final handover like https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , accepted and complete, is the artefact the future asks for. The manifest's job is to make sure a stranger can find that link, and its export, three years from now, without knowing anyone who worked on the project.
Frequently asked questions
Should the client get a copy of the archive?
The client gets the deliverables, the final handover, and their export as the delivery standard provides. The full internal archive, with its financial and access sets, is yours; sharing beyond the delivery set is a contract question, decided per engagement.
How long do we keep project archives?
Per class, from your retention schedule: delivery records on the contract's clock, financials on the tax clock, access records on your risk horizon. The manifest records the dates so the archive can be pruned on schedule instead of kept forever by default.
What is the most commonly missed item?
Item 4, the access changes. Projects end socially before they end technically, and agent connections granted for the work linger into other contexts. The closeout is the last cheap moment to revoke them deliberately.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai