Co-development agreements for AI products: structure, IP allocation, and milestone gating

What a co-development agreement is actually for

A co-development agreement is what two companies sign when neither one can build the product alone and neither one is willing to be the other's vendor. One side holds the domain knowledge, the proprietary data, the regulatory relationship, or the hardware. The other side holds the modeling, the data engineering, the evaluation discipline, and the cloud build. The thing that comes out the far end belongs to both of them in some proportion. The entire document exists to say what that proportion is, how it is measured, who pays for what along the way, and what happens on the day one side wants to stop.

The word people reach for at the start is "partnership," which carries no legal content at all. A partnership in the technical sense creates joint and several liability, which is almost never what either side means. What they mean is a contract with shared upside. Naming it correctly in the first meeting saves a month of confusion later, because the moment you say "joint development agreement" or "collaboration agreement," everyone's counsel knows which shelf to pull the template from.

Our team writes and receives these on both sides of the table. We build production AI, ML, data, and cloud systems as a prime and as a subcontractor, and a good share of that work arrives as a joint build with a software firm, an integrator, a hardware manufacturer, or a research institution. The pattern below is what holds up when the product succeeds, which is the only case that actually tests the paper. Failed projects settle quietly. Successful ones get litigated.

The four structures that get used

Almost every joint AI build lands in one of four shapes. Picking the shape first makes the rest of the drafting mechanical, because each shape carries its own default answers on ownership, payment, and exit.

Structure	Who pays	Who owns the output	Best when
Fee-for-service build	Sponsor pays cash against milestones	Sponsor owns foreground, builder keeps background and a license back	The sponsor has a funded program and a defined customer
Cost-share co-development	Both fund; often cash on one side, labor and tooling on the other	Split by field of use, or joint with an allocation schedule	Both sides want the product and neither will fund it alone
Royalty or revenue share	Builder funds part of the build against future revenue	Builder often retains the platform; sponsor gets an exclusive field	The product has a repeatable market beyond the first customer
License plus services	Sponsor licenses an existing component and pays for integration	Builder owns the component; sponsor owns the integration layer	Most of the technology already exists and the work is fit
Federal prime and sub	Government funds through the prime contract	Set by the FAR or DFARS data clauses, not by the parties alone	The end customer is an agency and the vehicle is already in place

The fifth row is the one people get wrong most often. When federal money funds the work, the two companies do not get to allocate rights however they please. The government's rights come in through the prime contract clauses and flow down. Any private allocation the parties write has to sit underneath those clauses, not on top of them. More on that below.

Background IP and foreground IP: draw the line before the first commit

Background IP is what each side brings in the door. Foreground IP is what gets created under the agreement. Every dispute we have ever seen in a joint build traces to a sentence about the boundary that nobody wrote before work started.

The fix is an exhibit, not a paragraph. Each side lists its background items by name and date on the day of signature: repositories, model architectures, prompt libraries, evaluation suites, feature stores, ontologies, ingest connectors, deployment templates. Anything on the list is presumed background even if it is improved during the project. Anything not on the list, created after the effective date, is foreground. That single exhibit resolves roughly three quarters of the arguments that otherwise arrive eighteen months later, when a repository has been refactored and nobody can tell what came from where.

Improvements to background need their own line. The common and workable answer: improvements to a party's background IP are owned by the party that owns the underlying background, with a perpetual license to the other side for use inside the joint product. Without that line, an engineer who spends two weeks improving the other side's ingest library has just created an ownership question with no answer.

The joint-ownership trap

"We will own it jointly" sounds fair and is usually the worst available answer. Under U.S. patent law, 35 U.S.C. 262 says that in the absence of an agreement to the contrary, each joint owner of a patent may make, use, sell, and license the invention without the consent of the other co-owners and without accounting to them for profits. Your co-owner can license your shared patent to your largest competitor, keep every dollar, and owe you nothing. Worse, all co-owners generally have to join a patent infringement suit, so an uncooperative co-owner can make the patent effectively unenforceable.

Copyright runs on a different default and that difference catches people. Under 17 U.S.C. 201(a), joint authors are co-owners of the copyright, each may grant non-exclusive licenses, and each does have a duty to account to the other for profits. So the same jointly built product can carry one default rule for the patented method and a different default rule for the source code implementing it. Two owners, two rulebooks, one repository.

The practical answer in most AI co-development is to avoid joint title entirely. Give one party title to the foreground and give the other party a broad, irrevocable, royalty-free license in a defined field of use, with the right to sublicense to its customers. That structure produces the same commercial outcome as joint ownership and none of the enforcement problems. If joint title is unavoidable for board or investor reasons, write the accounting, consent, enforcement, and license-approval terms into the agreement so the statutory defaults never govern.

When federal money is in the room

Federally funded work brings a rights framework that the parties do not control. Under the Bayh-Dole Act at 35 U.S.C. 200 through 212, implemented at 37 CFR Part 401, a contractor may elect to retain title to subject inventions, but must disclose each invention within two months of the inventor's written disclosure to company personnel responsible for patent matters, elect title within two years of that disclosure, and file within the statutory bar period. The government keeps a nonexclusive, nontransferable, irrevocable, paid-up license worldwide. Section 203 gives the agency march-in rights, and 35 U.S.C. 204 requires that products sold in the United States under an exclusive license be substantially manufactured here. That last one constrains exit structures more than most parties expect.

On the data and software side, DoD work runs on the DFARS 252.227-70xx family. Noncommercial technical data falls under 252.227-7013 and noncommercial computer software under 252.227-7014, with government purpose rights running five years from execution of the contract that required the development before converting to unlimited rights. Civilian agencies use FAR 52.227-14. The clause people miss is DFARS 252.227-7017: the assertions table listing every restriction, submitted with the offer. Restrictions not asserted at award are, with narrow exceptions, gone. A joint build that never produced an assertions list has handed the government unlimited rights in the whole delivery.

SBIR and STTR work adds a stronger shield. Data developed under an SBIR or STTR award carries a protection period of twenty years from the date of award under the current SBIR/STTR Policy Directive, with DFARS 252.227-7018 carrying the DoD implementation. STTR goes further and requires a written allocation-of-rights agreement between the small business and the research institution as a condition of award, alongside the minimum work split of 40 percent to the small business and 30 percent to the institution. That required agreement is a co-development agreement by another name, and it is worth writing well rather than pasting from a template. Our guide to structuring STTR university partnerships covers the negotiation in detail, and data rights in federal AI contracts covers the clause mechanics.

Two other federal shapes are worth naming. Prototype other transaction agreements under 10 U.S.C. 4022 carry no default data-rights clause at all, so every right is negotiated on the page, which is freedom and risk in the same sentence. Cooperative research and development agreements under 15 U.S.C. 3710a let a federal laboratory collaborate with a company and grant an option for an exclusive license in a field of use, with no federal funds flowing to the company.

Fee-for-service versus revenue share

The payment structure is a risk-allocation question wearing a finance costume. Fee-for-service moves the risk to the sponsor: the builder gets paid for the work whether or not the product sells. Revenue share moves risk to the builder: cheaper up front for the sponsor, far more expensive if the product wins.

Three practical rules. First, price the discount honestly. If a builder cuts its rate by 40 percent to take a royalty, the royalty has to be worth more than the cash foregone within a defined horizon, or it is a donation with paperwork. Second, define the royalty base with a stated formula rather than a word. "Net revenue" means nothing until the agreement says which deductions apply: returns, taxes, third-party pass-through, hosting, channel discounts. Software co-development royalties commonly sit anywhere from low single digits to the mid teens as a percentage of net revenue, driven almost entirely by who funded the build and who owns the customer. Third, put a buyout in. A stated formula that lets the sponsor convert the royalty to a lump sum, often a multiple of trailing twelve-month royalties, keeps the arrangement from blocking an acquisition three years out.

Revenue share also changes the accounting on both sides. When two parties are active participants in an activity and share in its risks and rewards, the arrangement falls under ASC 808 on collaborative arrangements rather than ASC 606, unless the counterparty is acting as a customer for a distinct unit of account. The classification changes how revenue is presented in the financial statements, which matters if either side is raising, being audited, or approaching a diligence process. Ask the question during drafting, when the answer is still cheap.

Milestone gating that actually gates

A milestone that cannot fail is a calendar entry. A gate has three parts: an objective criterion measured on data neither side can tune against, a payment or right that turns on the result, and a stated consequence when the criterion is missed. Most joint AI builds have the first part and skip the other two.

The holdout set deserves its own sentence in the agreement. Name who holds it, when it is frozen, and that it is not visible to the modeling team. An acceptance test run on data the builder has already seen proves nothing and both sides know it during the argument that follows. We wrote about the discipline separately in blind benchmarks and testing on someone else's instrument.

Tie the gate to a number the sponsor's own operation cares about. Precision at a fixed recall on the classes that carry consequence. Cost per processed document. Median and 95th-percentile latency under production load. Reviewer minutes saved per case. A gate written as "model performs well" is an invitation to disagree in month nine with money already spent.

The parts a 2005 template does not name

Most joint development templates in circulation predate modern machine learning and are silent on the assets that carry the value. Add these by name.

• Trained weights. Say who owns the checkpoints, whether they may be used to serve other customers, and what happens to them at termination.
• Training and fine-tuning data. The license the sponsor grants, whether derived and synthetic data is in or out, and whether the builder may retain aggregate statistics.
• Evaluation sets and scoring code. Usually the most reusable asset in the whole build, and almost never mentioned.
• Prompts, adapters, and configuration. Small artifacts that encode months of tuning. Assign them explicitly.
• Third-party model terms. The provider's terms flow through to the product, including any restriction on training competing models.
• Provenance and indemnity. Who warrants the lawful origin of the training data, and what the cap on that indemnity is.
• Export control. Technical data release to foreign persons inside the United States is a deemed export under 15 CFR 734.13(b), and defense articles bring 22 CFR 120 through 130 into scope.
• Model cards and documentation. A deliverable, not a courtesy, and the difference between a transferable system and a dependency.

The three failure modes

Unclear ownership. The agreement says the parties "will negotiate in good faith regarding intellectual property arising from the collaboration." That sentence is a promise to have the fight later, at the moment when the product is working and both sides have the most to lose. Ownership gets decided before the first sprint, in an exhibit, or it gets decided by lawyers at ten times the cost.

No exit. Many joint agreements describe a beginning and a middle and stop. Both parties need a defined way out at each gate, and both need to know what survives the exit: which licenses continue, who may keep serving the customer already signed, what happens to the deployed instance, how long support runs during a wind-down, and whether an exclusivity term releases on termination. Exclusivity that outlives the collaboration is a trap; the terms that make it survivable are covered in exclusivity in teaming agreements.

Mismatched timelines. A prime is running a capture calendar with a proposal due in five weeks. A product company is running a release train. A university is running a semester and a graduate student's thesis. A federal customer is running an appropriation that expires on 30 September. These four clocks do not line up on their own. Write the joint schedule against the tightest external deadline in the room, name that deadline in the agreement, and give the party that owns it the right to pull the gate forward.

The term sheet, on one page

• Background IP exhibit for each party, dated at signature
• Foreground ownership named to one party, with a field-of-use license to the other
• Explicit treatment of weights, evaluation sets, prompts, and training data
• Payment structure with the royalty base defined by formula and a buyout multiple
• Gates with objective criteria, a frozen holdout, and an exit at every gate
• Federal clause stack identified, with the assertions table prepared before submission
• Exclusivity scope, term, and the release conditions on termination
• Survival clause listing exactly which licenses and obligations outlive the agreement

Eight lines. A workable structure fits on one page and takes about an hour to draft once the commercial intent is clear. The long-form agreement that follows is mostly the ordinary machinery of confidentiality, warranty, limitation of liability, and dispute resolution, and counsel handles that quickly when the eight lines above are already settled. The reason these deals take four months is almost never legal complexity. It is that the two sides never wrote down what they actually wanted.

Common questions on structuring a joint build

Frequently asked questions