A prompt library belongs to the party whose rights were clearly assigned for each contribution, not automatically to the company that stores it. Employee work, contractor work and client-specific work can carry different rights, so a buyer needs an answer at the prompt level before treating the library as an asset.
In 1999, NASA lost the Mars Climate Orbiter after a mismatch between systems built by teams using different units of measurement. The spacecraft reached Mars, but navigation data produced in pound-seconds was used where newton-seconds were expected. NASA’s Mars Climate Orbiter Mishap Investigation Board documented the failure as a breakdown in interface control, verification and communication.
The problem was not that either team lacked a unit system. The problem was that the boundary between them had not been managed well enough for the systems to work together.
A buyer asking, “Who owns the prompt library?” is looking at a similar boundary. The prompts may sit in one repository and power one product, but the rights behind them may have entered through several different doors.
The question that changes a diligence call
A buyer can see a prompt library as part of the product: hundreds of instructions shaped through testing, edge cases, failed outputs and customer feedback. That is a reasonable view. It can also be wrong in ways that become expensive after a deal closes.
The first answer often sounds simple: “The company owns it.”
Then the buyer asks who wrote it.
An employee may have created a set of prompts while building the company’s product. A contractor may have written another set during a short engagement. A client may have supplied workflow instructions, examples, documents or an initial prompt that became the basis for a production workflow. Those are three different situations. A shared folder does not resolve them.
This matters most when the library contains the accumulated judgment of the business. A generic prompt to summarize a document is easy to replace. A prompt that reflects months of handling exceptions in a customer’s approval flow, tuning output for a regulated use case, or translating a messy internal process into steps has a different value. It may be the part of the product a buyer actually wants to keep.
Separate the library before someone else does
I would avoid asking who owns “the prompt library” as a single object. Start by separating what is inside it.
There is the company’s reusable material: prompts written for its own product, maintained in its own systems, and used across customers. There is contractor-created work, where the assignment language matters. Then there is client-specific material: prompts, source documents, examples, rules and workflow knowledge that may have been provided by the client or created for that client’s account.
The distinction can be uncomfortable because real work is messy. A contractor may adapt a client’s instructions into a reusable template. An employee may improve that template after seeing failures across several deployments. A client may expect the resulting workflow to be exclusive even when the agreement says little about it.
That is why diligence should not rely on memory or a founder’s broad assurance. Build a simple record showing where each important prompt family came from, who contributed to it, which agreement governed the work, and whether it is reused outside one customer account.
The process resembles the practical accountability issue in What Happens When Everyone Approves the Code but Nobody Owns the Workflow?. Approval can be distributed. Responsibility still needs a named owner.
Contracts decide more than repository access
Repository access tells you who can edit a prompt today. It does not reliably establish who can use, sell, modify or transfer it later.
For employees, confirm that employment terms cover intellectual-property assignment and the jurisdictions where the work was done. For contractors, check the signed scope and assignment language rather than assuming payment transferred rights. For client work, read the customer agreement alongside the statement of work. The client may own the delivered workflow, retain rights to its materials, receive a licence, or have negotiated limits on reuse.
These details can affect product decisions before an acquisition ever happens. If a strong workflow is tied to one client’s confidential process, treating it as a general product feature can create a conflict. If the company has a durable right to reuse the underlying pattern without client data, it can build a broader capability with clearer boundaries.
This is a legal and commercial review, not a prompt-engineering exercise. A founder should involve counsel where the contracts or jurisdictional position are unclear. The useful operational step is to make the underlying evidence easy to inspect.
Build the record while the work is still fresh
The Mars Climate Orbiter did not fail because engineers had never heard of measurement units. The failure came from an interface that was assumed rather than controlled. Prompt ownership breaks in the same quiet way when a team assumes that authorship, payment, access and rights all mean the same thing.
They do not.
Keep a contribution register for material prompt families. Mark whether each is employee-created, contractor-created, client-provided or jointly developed. Link it to the governing agreement. Keep client data and client-specific instructions separate from reusable patterns. When a contractor finishes, confirm the work product and rights transfer before the next release turns that work into a dependency.
A buyer who asks the ordinary diligence question is testing whether the company can show its work. The strongest answer is a short, honest map of what the business owns, what it may use, and what must stay with a client.
Comments
No comments yet.