ZAMBO.

Direct answer

They paid for the work. Your tools are how you make work for everyone, and that is a separate asset.

The deliverables are agreed, the price is agreed, and then a wider claim arrives: the client wants ownership of your templates, your scripts, your checklists, your whole way of producing the work, as well as the finished pieces themselves. Handing that over casually can quietly end your practice, because those tools are the accumulated capital of every job you have ever done, and they are what the next ten clients are really hiring. Refusing flatly can also be wrong, because some of what sits in the project genuinely was created for this client at their expense. This page makes the split that resolves it: project specific work transfers as agreed, background tools stay yours with a license covering everything embedded in their deliverables, a true buyout is possible but priced as the separate purchase it is, and the handover records exactly what changed hands.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated November 14, 2026. First published November 14, 2026. The records quoted below are real and public, read back from the live service on November 14, 2026.

Step 1. Split everything into project work and background tools before you answer

Two piles, judged by one test: was this thing created for this project, at this client's expense, or did it exist before the project and serve your wider practice? Pile one, project work: the deliverables themselves, plus anything made specifically for this job that has no real use beyond it, a bespoke configuration for their systems, content written about their business, designs built from their brand assets. Pile one is what the fee was buying, and the client's claim on it is fair in the shape the agreement describes. Pile two, background tools: your templates, scripts, libraries, prompts, checklists, and methods, refined across many clients, which this project used but did not create. Pile two is your means of production. A useful analogy to hold in the conversation: a client who commissions a portrait owns the portrait, not the brushes, the studio, or the painter's trained hand. Write both piles down as an actual inventory before you reply. A demand that feels enormous in the abstract usually shrinks to two or three named items once listed, and named items can be negotiated one by one.

Step 2. Give full value on pile one, and license pile two where it is embedded

The strongest answer is generous in the right pile and firm in the other, in the same sentence. On project work, deliver the rights the agreement promises, completely and without holding pieces back as leverage; a client who has paid should be able to use their deliverables fully, forever, without coming back to you. On background tools, the client needs something real too, and naming it defuses most demands: where your templates or code are embedded inside their deliverables, they get a license to use those deliverables as delivered, including the embedded parts, for their business, without owing you anything further. What the license does not transfer is the tool itself as a standalone asset: the right to extract your template, resell it, hand it to another supplier as their starting kit, or use it to produce work beyond the deliverables. Most clients pressing for ownership actually want certainty that they can use what they bought without future claims, and the license gives them exactly that certainty, which is why most of these demands settle at this step once the two rights are separated in plain words.

Step 3. Record the handover inventory, so what changed hands is a list, not a memory

Ownership fights later are inventory fights: which files, which version, transferred or only licensed, nobody can reconstruct. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), created by Brennan Zambo, and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the decision carrying shape an ownership handover wants:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

Read the accepted record as the template for the close of a job: steps as named items, each checked, one dated decision by the client over the whole set. Your delivery wants the same discipline in its inventory: every item handed over listed by name, marked owned by the client under the agreement or licensed as embedded background material, and the client accepting that exact list. The pending record shows the state to avoid at transfer time: items checked, nothing decided, release on hold, which in ownership terms is a delivery floating without agreed terms. Get the decision recorded over the list itself, and a later claim that the tools were included meets a document the client already accepted, line by line.

Step 4. If they truly need to own a tool, price it as the separate purchase it is

Sometimes the demand is genuine: the client is building an internal team, an acquirer is doing diligence, their whole operation will run on your system. Then ownership is possible, and it is a buyout, priced nothing like a deliverable. Value it honestly from what it replaces: the years the tool took to develop, the advantage it gives them over starting from scratch, and the cost to you of losing exclusive use of your own production kit, including the future work that kit would have produced. A buyout at that scale is its own agreement, with its own number, its own list of exactly which assets transfer, and a license back to you where you still need to use general techniques that live in your head, because knowledge and general skill cannot sensibly be sold out of a person. Presented this way, the conversation clarifies itself: clients who only wanted certainty take the license from step 2, and clients who truly need the asset see its real price and decide as buyers, not as claimants to something the project fee already covered.

Step 5. Put the split in the next agreement, in one short clause

The clause that prevents this entire argument reads roughly like this: deliverables created for the client transfer as stated; tools, templates, and methods the supplier brought to the work remain the supplier's, with a license covering their use as embedded in the deliverables; anything beyond that is agreed and priced separately in writing. Raise it at agreement time, when it reads as standard professionalism, rather than at delivery time, when the identical words read as suspicion. Pair it with one practice on your side: keep project work and background tools visibly separate as you work, project files in the project, your kit in your kit, so the inventory in step 1 is a listing job of minutes, not a forensic exercise. Suppliers who never lose their tools are not more combative than you; they just wrote the split down while nobody wanted anything yet.

What this page cannot settle

This page cannot tell you what your current agreement already signed away; work for hire wording, assignment clauses, and employment versus contractor status change the answer by place and by contract, and this is general information, not legal advice, so a signed agreement with a broad assignment deserves a lawyer's reading before you rely on any general split. It also cannot value a specific buyout for you, which depends on the asset and the market. A verifiable receipt proves the saved result was not changed since it was saved; it does not decide who owns anything. What the record settles is the inventory the ownership question is actually about: what was delivered, item by item, and what the client accepted, on a date.

Frequently asked questions

My client wants to own my tools and templates as well as the final work. Should I agree?

Agree to the first half fully and the second half only as a license or a separately priced buyout. Split the inventory before answering: project work, created for this client at their expense, transfers in the shape the agreement promises, completely, so they can use their deliverables forever without you. Background tools, your templates, scripts, and methods that existed before the job and serve your whole practice, stay yours; where they are embedded in the deliverables, the client gets a license to use the deliverables as delivered, which covers the certainty most clients are actually asking for. If they genuinely need to own a tool itself, that is a buyout: its own agreement, its own price reflecting what the tool cost to build and what losing it costs your future work. Record the handover as an itemised list the client accepts, marked owned or licensed per item, and put the split in your next agreement at signing time, when it reads as standard practice.

The client says they paid for everything produced during the project. Are my templates included?

Payment for a project's work buys what the agreement says it buys, and the useful distinction is between things produced for the project and tools the project merely used. A template you refined over years and applied to this job was used during the project in the same sense as your software and your training: present in the work, not created by the fee. Unless your agreement specifically assigns pre existing materials, the ordinary reading most professionals work to is that background material stays with its maker, licensed where embedded, while project specific output transfers. That is a general pattern, not a ruling on your contract: if you signed a broad assignment clause, get it read properly before acting on any general page, this one included. Either way, the practical move is the same: produce the two pile inventory and negotiate item by item, because named items settle and blanket claims do not.

What if my template is inside the deliverable the client now owns?

That is normal, and it is exactly what the embedded license is for. Ownership of the deliverable and ownership of every ingredient inside it are different things: the client owns their finished piece and can use it, reproduce it, and build on it as the agreement allows, while the template as a reusable tool remains yours, licensed to them as part of that deliverable. The boundary to state plainly is extraction: using the deliverable whole is theirs; pulling your template out as a standalone asset to resell, distribute, or hand to another supplier as a production kit is a further right that was not in the fee. State the boundary once, in writing, at handover, alongside the itemised list. In practice most clients accept it immediately, because what they needed was confidence about the deliverable itself, which they now have in writing.

How do I say no without losing the client?

Say yes first, to the large part they are entitled to, and make the no specific, small, and explained. Open with the transfer: their deliverables and the project specific work are theirs as agreed, delivered completely. Then name the handful of background items at issue, not your tools in general but these templates and this script, explain in one line what they are, the kit your practice runs on for every client, and give the license that covers their use inside the deliverables. Offer the buyout door without defensiveness if they truly need more. Clients accept boundaries that arrive with generosity on everything else and a visible reason; what loses clients is a flat refusal that sounds like you are holding their own work hostage, which is why the inventory and the order of the conversation matter more than firmness of tone.

How does a job record help when ownership of tools is disputed?

It fixes the inventory the dispute is about. When the work runs through Zambo, built by Brennan Zambo, every job lands on its own record with a verifiable receipt for each step under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, the client accepts on that record, and the acceptance view shows status, decider, date, and release state, so the exact list of items delivered and accepted is a link both sides can open when a later claim tries to widen what changed hands. Every tool free once a day, plus 3 continue calls. One free wrap-up handover per day, and pickup is always free. For $0.99, run your next delivery on one record with the owned and licensed items listed at handover, so ownership questions are answered by the accepted list, not argued from memory: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, $19 a month for $ZAMBO holders, or Lifetime at $250 one time.

Related