Does a UKDI innovation contract let your company retain its intellectual property?

UKDI’s published guidance says intellectual property generated under the Innovation Standard Contract generally belongs to the contractor under DEFCON 705. The funding authority receives rights to use the delivered technical information and associated intellectual property for specified purposes. Ownership therefore answers only part of a founder’s commercial question. The other part is what the customer may do with the results.

The UKDI Standard Terms and Conditions expressly direct applicants to the competition-specific contract. A company should read that document before treating its existing licensing model as compatible with the proposed research. The guidance describes a usual arrangement, not every possible contract.

A useful internal review begins by separating three things. First is the technology the business already possesses before the project. Second is the new work it expects to create. Third is the information, software, reports or other material it promises to deliver. These categories can overlap commercially, but a proposal should not leave their boundaries implicit.

Imagine a company with a civil maintenance analytics product. It proposes a research project to validate a new method using authorised sample data. The commercial team should identify whether its deliverable is a report, a prototype, source code, trained parameters, an interface specification or some combination. A vague promise to deliver “the platform” can create a substantially larger commitment than a precisely described research output. The R-Cloud version 5 transition review identifies the transition steps that affect the supplier's current preparation.

Then ask what rights are needed to execute the work. Does the company own all relevant inputs? Are components licensed from others? Can a research partner authorise the proposed use? Does any input licence limit transfer, disclosure or downstream use? These are diligence questions to resolve against the actual agreements, not assumptions about what government funding automatically overrides. The R-Cloud and R-Cloud+ IP comparison keeps the product's existing rights separate from the proposed research work.

The financial implications follow from the deliverables. Documentation, support and integration work consume time even when they produce no new product feature. Include that effort in project planning. If a deliverable creates continuing maintenance expectations, distinguish the funded project period from any later service obligation before accepting the contract.

Keep the future sales story equally precise. Retaining ownership can preserve an opportunity to commercialise a result, but it does not establish exclusive access to a market or a subsequent purchase. A customer’s permitted use may also affect the company’s commercial position. Both need to be understood when explaining the project to directors, investors or commercial partners.

Full Rights and Limited Rights versions concern the information delivered

The September guidance gives a concrete instruction for competitions using the Innovation Standard Contract and DEFCON 705. It distinguishes a Full Rights version containing information generated under the contracted work from a Limited Rights version that also contains background information. A coherent Full Rights version of each deliverable is required; an additional Limited Rights version can be supplied where agreed to aid understanding. The proposal must also identify relevant third-party rights and prior MOD-funded background information. UKDI deliverable versions and markings

These categories should not be reduced to a choice between disclosing everything and providing an unusable result. The commercial task is to define a research output that can stand on its own while identifying the background material needed to explain or evaluate it. That requires technical judgement about the structure of the report, software or other deliverable as well as review of the applicable rights.

For a product company, the distinction can affect development architecture before the project begins. If the experimental work is inseparable from a proprietary platform, the team may struggle to produce an independently coherent account of the funded result. If it separates every component without considering the customer's purpose, it may create a technically neat output that is difficult to use. The proposal needs a practical answer to both concerns.

Work through one research deliverable before pricing the whole project

Return to the hypothetical maintenance analytics company. Its existing product contains a commercial interface, data connectors and a method developed with private investment. The proposed research evaluates a new approach to resolving inconsistent identifiers. A useful deliverable description would identify what the funded work produces: for example, an evaluation report, a documented experimental method and the supporting material agreed for that assessment.

The team should then ask whether the report explains its conclusions without requiring the reader to inspect undisclosed parts of the existing product. If a comparison depends on an existing component, the role and relevant restrictions of that component need to be understood. If a third-party dataset supports the findings, the company must establish what can be delivered or described under the input licence. These questions influence the research design and the contents of the handover package.

A practical commercial discussion may reveal an alternative that satisfies the customer's purpose more clearly. An evaluation report could distinguish the new method from the platform that hosts it. A documented interface could explain how an experimental module connects to authorised inputs. The point is to produce a usable funded result with accurately described dependencies, rather than rely on a broad assurance that the company retains ownership of its technology.

The cost follows from that design. Preparing a coherent report, separating background material and documenting dependencies can require effort beyond the experiment itself. If those activities are essential to the promised deliverable, they belong in the proposed work and price. Leaving them until the end risks discovering that the team has created an interesting result but has not budgeted to deliver it in the agreed form.

Proposal confidentiality and publication are separate from IP ownership

UKDI also requires a title, value proposition and short abstract that it may publish and use freely. Its guidance describes confidential handling arrangements for other proposal information and identifies transparency provisions for funded contracts. A company should therefore review its public summary separately from the detailed technical submission. The ownership of an invention does not determine whether every sentence describing it should appear in material prepared for unrestricted publication. UKDI proposal information and transparency

This is a useful division of work between technical and commercial staff. The public summary can explain the user problem, the proposed research and its potential value without exposing unnecessary implementation detail. The technical submission can then provide the evidence assessors need under the stated process. Both should describe the same project accurately; they serve different audiences and should not be assembled by simply shortening one document mechanically.

The company's later investor narrative should use the same distinctions. It can explain that a research contract funds specified work and describe the rights arrangement that actually applies. It should separate the existing product, the newly generated result and the customer's permitted uses. That account helps investors understand the commercial asset the company expects to retain and the obligations attached to it. The strongest IP story is a precise description of a usable result and a workable rights allocation, supported by the actual documents and reflected in the delivery plan.

The most useful outcome of this review is a short rights-and-deliverables schedule that engineering and commercial staff both understand. It should identify unresolved questions for the contracting authority or specialist adviser before submission. UKDI’s public guidance gives a starting point; the executed contract establishes the actual arrangement. A funding announcement alone cannot tell a reader that a company has either surrendered its technology or preserved every commercial right unchanged. The UKDI fundable but not funded review explains why a positive assessment still differs from a funded project.