Who owns the prompt library you built?
Prompts, reference sets and workflow graphs built on a client job are unassigned in most contracts. Clause language that keeps method and gives outputs.
Six months into a retainer you have a working system: a prompt structure that reliably produces the client's product on the right surface, a reference set that holds the character, a negative-prompt block that kills the three failure modes their category attracts, and a routing decision about which model handles which shot type. That system is most of why the work is fast and none of it is named in the contract.
Then the retainer ends and someone asks for "all work product." The honest answer depends on a definition nobody read at signature.
What the assignment clause actually catches
Production contracts assign either "Deliverables" or "Work Product," and the difference is not cosmetic.
A Deliverables definition is usually a list: the videos, the images, the cutdowns, the source files. It is bounded by what was handed over. A prompt library is not on that list, so it is not assigned, and the ambiguity is manageable.
A Work Product definition is typically much wider. Something like "all materials, documents, designs, processes and other items conceived, created or developed in the course of performing the Services" is standard language, and read literally it swallows the method. Every prompt you wrote while working on that account was conceived in the course of performing the Services. So was the workflow. So, arguably, was the rubric you use on every other client.
Most contracts do not intend that outcome. Most contracts also do not say so. The fix is a background IP clause, which is completely ordinary in software and consulting agreements and strangely absent from creative production agreements, where the method is now a substantial part of what a studio is worth.
Four asset classes, three different answers
Sorting the assets first makes the clause easy to write.
| Class | Examples | Where it should land |
|---|---|---|
| Deliverable | Finished videos, images, audio, source timelines | Client, fully, with all rights you hold |
| Client-derived asset | Brand kit, product reference set, approved character reference, style guide built from their assets | Client, or exclusive to them |
| Method asset | Prompt structures, negative-prompt blocks, scoring rubrics, model routing decisions, workflow graphs | Studio, licensed to the client for the engagement |
| Model artefact | A LoRA or fine-tune | Depends entirely on what it was trained on |
The test that separates the middle two is one question: would this still be useful if every reference to the client and every piece of their material were removed?
A prompt structure that says "product held at 45 degrees, single key light from camera left, shallow depth of field, no hands in frame" survives that deletion intact. It is method. A reference set of their actual product photographed from twelve angles does not survive it at all. It is theirs.
That test also tells you how to write the library. If a prompt only works because the client's trade secrets are inside it, you have built a client-derived asset and you should not be planning to reuse it. If it works because you understood the failure mode of a shot type, it is yours and the deletion test proves it.
Model artefacts are the hard case because they are the one class where the two inputs are baked together. A LoRA trained on a client's product photography is a client-derived asset regardless of how much of your method went into the training recipe. The training recipe is yours; the artefact is not. Say that explicitly, because the alternative is discovering the disagreement while you are trying to reuse a weight file. Licence terms for selling prompts and LoRAs covers the downstream case where you intend to distribute the artefact rather than just keep it.
What legal protection actually exists here
Be realistic about this, because the clause is doing more work than the law is.
Copyright protection for prompts is genuinely unsettled and depends heavily on length, originality and jurisdiction. Nobody should build a business model on the assumption that a one-line prompt is a protected work. The practical protections are contractual and, where you have kept the material properly, confidential: a background IP clause that says the method is yours, plus normal confidentiality handling, gets you further than any assertion about copyright.
This cuts both ways, and it is worth being honest with clients about it. You are not claiming exclusive rights to the idea of describing a lighting setup. You are agreeing that the system you built for producing their work at speed remains your system, and that they get unrestricted rights to everything it produced for them. Framed that way it is rarely controversial, because the client's actual interest is in the outputs and in nobody else getting their brand assets.
Clause text
Adapt the bracketed terms and have a lawyer in your jurisdiction check it against the rest of the agreement, particularly the Work Product definition it needs to override.
Background IP. Supplier retains all right, title and interest in its Background IP, defined as materials, methods, processes, prompt structures, model configurations, evaluation criteria and workflow templates owned or developed by Supplier independently of this Agreement, or developed in the course of the Services but not derived from Client Materials.
Licence to Client. Supplier grants Client a non-exclusive, perpetual, royalty-free licence to use Background IP solely to the extent it is embedded in or necessary to use the Deliverables.
Client Materials and derived assets. Client retains all right, title and interest in Client Materials. Any reference set, brand configuration, character reference, model adaptation or fine-tuned artefact derived from Client Materials is a Client-Derived Asset, is used solely for Client, and is delivered or destroyed at Client's election on termination.
Deliverables. Supplier assigns to Client all right, title and interest Supplier holds in the Deliverables on payment in full.
No restriction on method. Nothing in this Agreement restricts Supplier from using its Background IP, or the skills and knowledge gained in performing the Services, for other clients, provided no Client Materials or Confidential Information are used.
The last paragraph is the one that matters most and the one most likely to be queried. It is also the fairest, because the alternative reading is that every client who hires you buys a partial restraint on your ability to do the same job for anyone else, which nobody actually negotiated for and nobody is paying for.
Building the library so the clause holds up
A clause that describes a separation you have not actually maintained will not survive a serious look. Three practices make it real.
Keep the client-derived layer separate from the method layer. A brand configuration holds colours, type, tone and approved reference imagery. A prompt template holds shot construction and failure-mode language, with the brand-specific values referenced rather than pasted in. Versely's brand kit and reusable characters and products are already this split, which is convenient: the account-specific material lives in one place and the method lives in another, so the deletion test is a fact about your setup rather than an argument you have to make.
Save workflows as workflows, not as chat history. A saved workflow is an artefact you can point at, version and describe in a schedule to the contract. Saving and reusing a video workflow makes the method a named object; a scrollback does not.
Version and date everything. The most common dispute is not about ownership in principle, it is about whether a given template predated the engagement. Dated versions settle that in one look. Asset naming and version discipline is the general practice, and building a prompt library your team actually uses covers the structure of the entries themselves.
If you intend to productise any of this later, the separation matters more, not less. Turning client work into sellable templates only works if the client-specific layer was never inside the template to begin with.
FAQ
Should I show the client the prompt library?
Show the structure, not the contents. Clients asking this usually want reassurance that the process is real and repeatable rather than access to the strings. A one-page description of how a shot gets specified answers the real question. Handing over the library answers a question nobody asked and gives away the retained asset in the same gesture.
What if the client paid specifically for the system?
Then it is a different engagement and should be priced and drafted as one. A build-and-hand-over of a documented production system is legitimate work, and the deliverable is the system. What you should not do is deliver a system at production rates because the Work Product definition was wide enough to reach it.
Does the client get the prompts if they ask on termination?
Under the clause above, they get the Deliverables, the Client Materials, and any Client-Derived Asset. Not the method. Setting that expectation at signature is the entire point, because on termination it reads as a stance and at signature it reads as an ordinary background IP clause, which is what it is.
What about a fine-tune trained on both client and studio material?
Treat the artefact as client-derived and keep the recipe. Mixed training data is why fine-tuning runs deserve a written record of exactly what went into them at the time of the run. Reconstructing a training set from memory a year later in the middle of a disagreement is not a position you want to be in.