Open Innovation Programme Checklist: Submission Terms and Consent, Evaluation and Firewall Records, Prize and Competition Rules, Contributor Assignments, and Commercialisation Handover

By Casey Scott McKay · 2024-12-23

A ten-phase working checklist for any organisation that receives ideas from outside it. Phase one settles the programme's purpose, which determines every subsequent design decision. Phases two and three build the unsolicited submission policy and the submission terms. Phases four and five build the evaluation record and the firewall that actually decide disputes. Phases six and seven cover events, contributor assignments, and prize competition compliance. Phases eight through ten cover retention, commercialisation handover, and defending a claim. Each phase closes with a gate.

IP and Technology > IP and IT in Corporate Transactions | Checklist | Published 23 December 2024 - Updated 8 August 2025 | Casey Scott McKay - marksy.us

How to use this checklist

Two propositions organise everything below.

An idea is not property, and claims about ideas still succeed. 17 U.S.C. § 102(b) excludes ideas on the principle of Baker v. Selden, and the surviving claims run on contract and quasi-contract — the implied-in-fact theory of Desny v. Wilder chief among them. The company will not win by saying the idea was unprotectable.

The facts decide, not the terms. What was received, what was done with it, and what the company can prove about where its own product came from. Which makes Phases 4 and 5 the ones that matter most, and Phase 1 the one that makes them coherent.

The doctrinal background is Ideas Sent to You; the operational treatment with worked engagements is Running an Open Innovation or Prize Competition Programme; the cluster is assembled in the Open Innovation and Prize Competition Toolkit.

Phase 1. Settle the purpose

[ ] Make somebody senior answer the question: is this procurement, scouting, or marketing?
[ ] Procurement means the company intends to acquire and use what it receives. Take real rights, pay for them, contract properly with contributors, treat submissions as supply inputs.
[ ] Scouting means the company intends to identify people and capabilities. Take minimal rights, disclaim everything, evaluate at arm's length, convert anything interesting into a separate negotiated relationship.
[ ] Marketing means the company intends to signal openness. Take no rights, say so clearly, and structure the programme so nothing it builds could be traced to a submission.
[ ] Record the answer and circulate it, since the failure mode is a programme presented as the third, designed as the second, and used as the first.
[ ] Re-test the answer annually, since scouting programmes drift into procurement without anybody deciding.
[ ] [Gate] The purpose is written down and the terms, the rights taken, and the evaluation design all follow from it.

Phase 2. The unsolicited submission policy

[ ] Publish a policy stating whether unsolicited submissions are accepted. The strongest position is that they are not, with an automated response returning them unread.
[ ] Write the arrival protocol for material arriving outside the channel: stop, do not read, isolate with a designated recipient outside the relevant team, return with the policy and a covering letter, record the receipt, firewall anybody exposed.
[ ] Train the people who receive email, since the protocol operates only if the first person to see it knows to stop.
[ ] Record every receipt with date, sender, subject matter at the most general level, and disposition.
[ ] Check the development record whenever one arrives in an active area, since independent development evidence predating the submission is what defeats the claim.
[ ] Do not change the roadmap in response, since a feature dropped because of an unsolicited email is a feature the company has effectively conceded was the sender's. See Running a Competitive Intelligence Programme for the identical discipline applied to a different source.
[ ] [Gate] The policy is published, the protocol is trained, and the last unsolicited submission was handled under it.

Phase 3. The submission terms

[ ] State that submissions are not confidential, which removes the confidential relationship theory.
[ ] State that no obligation arises unless a separate written agreement is executed, which weakens the implied-in-fact contract theory.
[ ] Reserve independent development expressly, which is both a legal reservation and a factual assertion the company must be able to support.
[ ] Take a warranty of ownership and freedom to submit, which addresses the employed-inventor problem without solving it.
[ ] Specify the licence taken, matched to the stated purpose rather than defaulting to a broad grant.
[ ] Describe the evaluation process and who conducts it, since a transparent process is a defensible one.
[ ] State what happens to unselected submissions: destroyed, retained, or returned.
[ ] Present the terms immediately above the submit button with affirmative acceptance, not behind a link at the foot of the page, since enforceability is frequently the whole case.
[ ] Do not over-grant. A broad licence a scouting programme will never use is a term entrants resent and courts scrutinise, and it undermines the company's own characterisation of the programme.
[ ] Tell the client what the terms cannot do: prevent a claim, make a taken idea free, substitute for the evaluation record, or cure a badly designed programme.
[ ] [Gate] The terms match the stated purpose and are presented in a form a court would enforce.

Phase 4. The evaluation record

[ ] Use a structured intake form rather than free-text email, capturing the problem addressed, the approach at a stated level of detail, the submitter's identity, and the ownership warranty.
[ ] Limit the detail requested. A programme asking for full technical disclosure has invited exactly the material that creates exposure. Take the detail later, under a negotiated agreement, if the submission proceeds.
[ ] Record what was received: date, identifier, and a summary sufficient to establish scope without requiring anybody to re-read it.
[ ] Score against published criteria, which is a better evaluation process and a defensible record, converting "we declined it" into "it scored below threshold on these two criteria".
[ ] Use at least two evaluators past the first screen, since a single evaluator concentrates both judgment and exposure.
[ ] Record who evaluated, by name, with dates, because the question in any dispute is who was exposed and when.
[ ] Record the decision and the reason. A submission declined with no recorded reason cannot be distinguished from one quietly used.
[ ] Set and meet a decision deadline, since submissions sitting unanswered for months generate suspicion and the delay itself becomes a fact.
[ ] Communicate the decision with a reason at the level of generality the programme can sustain. Silence is neither honest nor safe.
[ ] Retain the scored record, not only the outcome.
[ ] Review evaluator load, since a programme where one person evaluates everything has concentrated all exposure in one recollection that will be tested years later.
[ ] [Gate] Every submission received in the last year has a date, an evaluator, a decision, and a reason.

Phase 5. The firewall and the development record

[ ] Firewall evaluators from developers where the subject matter overlaps active internal work. This is the most valuable structural control and the most uncomfortable, since the best-qualified evaluators are the people working on the same problem.
[ ] Use the workable compromises: adjacent-domain evaluators, external evaluators under confidentiality, or a two-stage process where a firewalled screener determines overlap before anybody with domain responsibility sees the submission.
[ ] Define the firewall's scope precisely — which projects, which people, for how long — since an indefinite firewall is unworkable and will be breached informally.
[ ] Record the firewall, because one nobody documented did not exist evidentially.
[ ] Handle breaches honestly: record them, firewall the person from the project, and note it. A recorded breach handled properly is far better than an unrecorded one found in disclosure.
[ ] Reassess after reorganisations, which dissolve firewalls silently as people move between teams.
[ ] Accept that some submissions should be returned unread rather than evaluated, where they sit squarely in an area of intensive active development.
[ ] Maintain contemporaneous development records in the engineering organisation: design documents, decision logs, architecture records, version control history — granular enough to match a specific approach to a specific date.
[ ] Verify the engineering documentation before opening the portal. A company that cannot prove what it was doing last quarter, inviting submissions in an area it is actively working on, has created an exposure it cannot answer.
[ ] Review the aggregate, since a programme receiving many submissions in an area of active internal development has a structural problem no individual firewall solves.
[ ] [Gate] The company could prove, from ordinary-course records, what it was building before any submission arrived.

Phase 6. Events and contributor assignments

[ ] Take assignments from individuals, not teams, since copyright vests in the individual authors under 17 U.S.C. § 201 and a transfer requires the signed writing at 17 U.S.C. § 204.
[ ] Record acceptance at registration against the participant's identity, timestamped — the practical equivalent most events rely on.
[ ] Cover copyright and patentable subject matter separately, since they transfer differently, and check the work-for-hire categories at 17 U.S.C. § 101 rather than assuming they apply.
[ ] Ask the employer question at registration: are you participating as an employee, and has your employer consented? This surfaces the problem while it can still be solved.
[ ] Require employer consent for corporate participants, which most events do not and should, since a participant cannot grant what their employment agreement already assigned.
[ ] Check institutional policies for student and academic participants. See From Laboratory to Licence and the University and Research Institution IP Toolkit.
[ ] Provide the terms in advance, since a participant reading an assignment clause five minutes before a two-day event has no real choice, which weakens the position.
[ ] Brief participants verbally at the opening, in two minutes, on what they grant and what they keep.
[ ] Provide a cleared asset pack with its licence stated, so participants build on material the sponsor can use.
[ ] Require a dependency declaration at submission, which is the only practical way to audit open source obligations across dozens of entries. See Copyleft and Consequences.
[ ] Record teams and members accurately, since a name on a whiteboard is not a chain of title.
[ ] Take publicity releases at registration, since a winner who declines to be named afterwards is a problem with no solution.
[ ] [Gate] The sponsor could lawfully productise the winning entry tomorrow, and can show why.

Phase 7. Prize competition compliance

[ ] Remove one of the three elements — prize, chance, consideration — since all three together make a lottery. This is a structural design decision, not a drafting one.
[ ] Ensure the skill is genuine, judged against published criteria by identified judges, with outcomes determined by merit.
[ ] Handle tie-breaks carefully, since a random draw reintroduces chance.
[ ] Publish official rules before entry covering eligibility, entry method and period, judging criteria and process, number and value of prizes, notification, sponsor identity, and any publicity release.
[ ] Set eligibility restrictions deliberately: age, jurisdiction, employment by the sponsor or its agencies, and participation as an employee of another organisation.
[ ] Handle prize taxation and reporting at the applicable thresholds, treating international entrants as a separate analysis.
[ ] Check registration and bonding requirements, which apply above value thresholds in some jurisdictions.
[ ] Reconcile the official rules with the submission terms, since a competition publishing two contradictory contracts hands the entrant a choice of which to rely on.
[ ] Announce and apply the judging criteria, since a competition decided on undisclosed criteria generates avoidable complaints.
[ ] [Gate] The rules were published before the first entry and say the same thing as the submission terms.

Phase 8. Retention and destruction

[ ] Set the retention policy before any dispute, so that ordinary-course destruction is not later characterised as spoliation.
[ ] Apply it consistently, since selective retention is worse than either extreme.
[ ] Suspend it on notice of a claim or a reasonably anticipated one, and record the suspension.
[ ] Decide what "destroyed" means for material held in backups, evaluation systems, and evaluators' own files.
[ ] Match the policy to what the terms promised, since a term saying unselected submissions are destroyed and a practice of indefinite retention is a misrepresentation.
[ ] Retain the evaluation record even where the submission is destroyed, since the record is the defence and the submission is the exposure.
[ ] [Gate] The retention practice matches the published terms, and somebody can prove it.

Phase 9. Commercialisation handover

[ ] Check the rights obtained match the use intended, since a licence to evaluate is not a licence to commercialise and the operating business discovers this at launch.
[ ] Negotiate a separate agreement with the selected submitter, which is what the terms contemplated and is cleaner than relying on a click-through.
[ ] Run confirmatory diligence on ownership, employer position, institutional policy, prior disclosures, and existing grants, rather than accepting the warranty.
[ ] Define follow-on rights for improvements the company makes, since the defaults are unattractive to both sides and a paragraph settles it.
[ ] Resolve the contributor relationship: whether the submitter will be involved in what follows, on what basis, with what compensation.
[ ] Transfer the provenance record to the operating business, since the product team building two years later cannot otherwise answer a diligence question.
[ ] Produce a handover document — half a page per selected submission recording rights, provenance, and contributor position — which is the artefact acquirers ask for. See the IP Due Diligence Toolkit.
[ ] Keep acquisition and decline populations visibly separate, since a single process that sometimes results in acquisition supports the inference that every submission was under consideration for it.
[ ] [Gate] Every submission that moved into development has a handover document.

Phase 10. Defending a claim

[ ] Establish the timeline first: when the submission arrived, when the internal work began, and the documentary evidence for each.
[ ] Produce the intake and evaluation record, showing the submission was handled through a process rather than absorbed.
[ ] Produce the firewall record, showing who was and was not exposed.
[ ] Produce the independent development file, contemporaneous and granular. This is the evidence that wins.
[ ] Plead the terms for what they do, rather than relying on them as a complete answer.
[ ] Assess preemption under 17 U.S.C. § 301 against the specific state-law theory pleaded.
[ ] Assess the novelty and concreteness requirements in the applicable state, which defeat some idea claims at the threshold.
[ ] Consider the jury, since idea claims are sympathetic and technical defences persuade less than a clear account of what the company was already doing.
[ ] Assess settlement early and realistically, since discovery reaches into product development and a modest early settlement is frequently correct even where the defence is strong.
[ ] [Gate] The company can produce a chronology supported by documents created before the claim arose.

Programme variants

[ ] Supplier innovation programmes, where the relationship is already contractual and the supply agreement's terms predate the programme and do not address it.
[ ] Customer co-creation, where the terms of service usually contain a feedback licence — the right instrument, to be checked rather than assumed.
[ ] Corporate venture scouting, a confidentiality problem rather than a submission problem, with identical firewall and development record discipline and higher reputational stakes in a small ecosystem.
[ ] Academic collaboration, bringing institutional policies, publication expectations, and funding conditions. See Negotiating University and Research Institution Agreements and the Technology Transfer Checklist.
[ ] Government challenges, carrying procurement rules, public disclosure, and data rights. See Selling to the Government Without Giving Away the Technology.
[ ] Employee suggestion schemes, interacting with invention assignment agreements and statutory inventor compensation.
[ ] Crowdfunding, where disclosure runs the other way with severe novelty consequences. See the Crowdfunding IP Checklist.
[ ] [Gate] The checklist has been adapted to the variant rather than applied generically.

The proportionate version

[ ] Decide the purpose, which costs nothing.
[ ] Use short, prominent terms: not confidential, no obligation without a separate agreement, we may be working on this already, you warrant you own it.
[ ] Keep an intake log — a spreadsheet with a date, a name, a subject line, and a decision.
[ ] Firewall by default, which in a small organisation usually means the evaluator should not be the builder even where that is inconvenient.
[ ] Take assignments at events, individually, at registration.
[ ] Publish official rules if there is a prize, since that requirement does not scale down.
[ ] [Gate] Six items, achievable in an afternoon, covering the exposure that matters for an organisation of five people.

The eleven artefacts

[ ] A stated purpose, recorded.
[ ] Submission terms matched to it, prominently presented and affirmatively accepted.
[ ] An unsolicited submission policy with an arrival protocol and trained recipients.
[ ] An intake record with dates, identifiers, and summaries.
[ ] An evaluation record with reviewers, dates, decisions, and reasons.
[ ] A firewall log for overlapping areas.
[ ] Contemporaneous development records in the engineering organisation.
[ ] A retention and destruction policy, set in advance and suspended on notice.
[ ] Individual contributor assignments at events, with employer consent where applicable.
[ ] Official rules where prizes are offered.
[ ] A handover protocol for selected submissions.
[ ] [Gate] A programme holding all eleven can defend a claim, commercialise its outputs, and survive diligence. One holding only the terms has documentation for a single theory and no answer at all on the facts.

Six questions before the portal opens

[ ] What is this programme for?
[ ] What are we already working on in this area?
[ ] Can our engineering organisation prove what it was doing last quarter?
[ ] Who evaluates, and are they the same people who build?
[ ] What rights do we actually need?
[ ] What happens to the submissions we decline?
[ ] [Gate] All six answered in one meeting with the right people present, before anything is drafted.

Three worked applications

Designing a programme from nothing

[ ] Week one — Phase 1. Get the purpose decided by somebody senior; do not proceed without it.
[ ] Week two — Phase 5's dependency. Establish what the company is already developing in the target area and whether engineering can prove it. This is the diagnostic that most often changes the plan.
[ ] Weeks three to five — Phases 2 and 3. Terms matched to purpose, plus the unsolicited submission policy, which addresses a different and more common exposure.
[ ] Weeks five to seven — Phases 4 and 5. The evaluation record and firewall design, which is organisational rather than drafting work and needs the innovation function's cooperation.
[ ] Weeks seven to nine — Phases 8 and 9. Retention policy, intake log, handover protocol.
[ ] Weeks nine to twelve. Train evaluators, brief engineering leads on documentation, and run a dry submission through the whole process to find where it breaks.

The submission the company wants to use

[ ] Read what the terms granted, which is frequently evaluation rather than commercialisation.
[ ] Negotiate a separate agreement, which is what the terms contemplated.
[ ] Check the submitter's own position by asking rather than relying on the warranty.
[ ] Define follow-on rights for improvements.
[ ] Document the handover with rights, provenance, and contributor position.
[ ] Review the declined population, since the retention policy and firewall record defend the company when one of them sues in two years.

The hackathon output nobody can use

[ ] Identify the individual authors and whether the event terms took assignments from each rather than from teams.
[ ] Check each participant's employer position.
[ ] Audit the open source dependencies against the declarations, if any were taken.
[ ] Obtain fresh assignments where the terms were inadequate, from a weak negotiating position after the fact.
[ ] Fix the event terms for next time, since the difference between a usable output and an expensive marketing exercise is one clause accepted at registration.

The annual review

[ ] Re-check the stated purpose against how the programme is actually used.
[ ] Audit evaluation records for completeness, particularly the reason field, which is the one people skip.
[ ] Test the firewall against the current organisational chart.
[ ] Re-check engineering documentation in areas the programme touches.
[ ] Confirm the retention policy is applied consistently.
[ ] Re-read the terms against the rights actually needed, and narrow them if the broad grant has never been used.
[ ] Reconcile official rules with submission terms for any competition run during the year.
[ ] Confirm handover documents exist for everything that moved into development.
[ ] Ask whether the programme is producing value, since a scouting programme that has produced nothing in two years is generating exposure for no return and closing it is a legitimate recommendation.
[ ] [Gate] Nothing in the file is more than twelve months old and unverified.

For the submitter

[ ] File before you submit. A provisional under 35 U.S.C. § 111(b) costs little and converts an unprotectable idea into a priority date.
[ ] Read the terms, which will say the submission is non-confidential, that no obligation arises, and that the recipient may be developing the same thing. They usually mean what they say.
[ ] Do not disclose the enabling detail. Describe the problem solved and the result achieved without the mechanism.
[ ] Keep your own record of what was sent and when.
[ ] Understand the realistic outcome: these claims are difficult, expensive, and frequently unsuccessful.
[ ] Consider the alternative route — a licensing conversation under a negotiated agreement entered before disclosure — and note that a company unwilling to sign one has told you something useful.
[ ] [Gate] Nothing was disclosed that the submitter could not afford to have used.

Borrowing from open source practice

The open source community solved the contribution problem decades ago, and a commercial programme copying the architecture will be better designed than one inventing its own.

[ ] Use a standing contributor agreement, signed once, covering everything contributed thereafter, stating the rights granted and warranting the right to grant them.
[ ] Address the employer problem directly, as contributor licence agreements do, by requiring corporate contributors' employers to sign a parallel agreement.
[ ] Consider an origin attestation as the lighter alternative — a short statement with each contribution that the contributor wrote the material or has the right to submit it.
[ ] Keep a provenance record showing who contributed what, when, and under which agreement, so provenance is never in doubt.
[ ] State the terms in advance and apply them to everything, which removes negotiation and lets contributions flow at speed.
[ ] Note the fifth element that does not transfer: community enforcement, where a project taking a contribution without credit would be publicly criticised within hours. The commercial equivalent is the reputational arithmetic below, which operates less visibly and no less effectively.
[ ] [Gate] The programme's contribution architecture has been compared against a well-run open source project's, and the differences are deliberate.

The reputational arithmetic

[ ] Recognise that ecosystems are small. A startup that pitched a corporate venture arm and later saw a similar feature ship will tell the others, and a company with that reputation stops seeing good submissions.
[ ] Recognise that competitions are watched, and that a sponsor using a winner's work without a licence produces an account reaching exactly the audience it was courting.
[ ] Decline well. A prompt, courteous decline with a clear reason produces goodwill; a submission that disappears produces suspicion, and suspicion precedes claims.
[ ] Pay occasionally. A company that takes a genuinely useful submission and negotiates a modest payment has bought certainty, goodwill, and a case study.
[ ] Be transparent about the purpose, since an organisation that says clearly it is scouting rather than procuring, and behaves accordingly, is not accused of taking what it said it would not take.
[ ] [Gate] The commercial recommendation has been considered alongside the legal one, since "pay them" is sometimes the correct answer to "can we use this".

The posture to adopt

[ ] Do not over-protect. Terms broader than the purpose requires attract scrutiny, undermine the company's own characterisation of the programme, and deter exactly the submitters whose ideas are worth having.
[ ] Match rights precisely to purpose: narrow for scouting, real and paid for procurement, absent for marketing.
[ ] Invest in the record rather than the drafting, since the record decides disputes and the drafting addresses theories.
[ ] Get into the design conversation early, since a programme designed with counsel present produces records and one designed without produces submissions.
[ ] [Gate] The programme is one people are willing to submit to, which is the point of running it.

The intake form, item by item

The structured intake form is where several of the controls in this checklist are actually implemented, and it repays specific attention.

[ ] Submitter identity and contact, since an anonymous submission cannot be declined, cleared, or contracted with, and creates exposure with no counterparty.
[ ] The problem addressed, in the submitter's own words, which is the field that determines whether the submission overlaps active internal work.
[ ] The proposed approach at a stated level of detail, with an explicit instruction not to include confidential technical detail. This protects both sides and it is the field most programmes get wrong by asking for everything.
[ ] Whether the submitter has filed any application covering the submission, which tells the company a great deal about how to handle it.
[ ] The ownership warranty, as a tick box with the text visible rather than incorporated by reference.
[ ] The employer question: is the submitter employed, and does any agreement assign this? A single question surfacing the problem while it can be solved.
[ ] Acknowledgement of the terms, as a separate affirmative action with the terms displayed.
[ ] A field for the submitter's own reference, since submitters who can cite a reference number in follow-up correspondence generate fewer disputes about whether a submission was received.
[ ] And no free-text attachment field by default, or a clearly bounded one, since attachments are where the unwanted enabling disclosure arrives.
[ ] [Gate] The form collects enough to evaluate, no more than that, and produces a comparable record across every submission.

Evidence habits

[ ] Timestamp the intake automatically, since the arrival date is the pivot of every later chronology.
[ ] Record the evaluator assignment at the moment it is made, not retrospectively.
[ ] Complete the reason field before the decision is communicated, which is the only reliable way to ensure it is completed at all.
[ ] Log firewall assignments on the day teams are formed, with the scope and duration.
[ ] Keep engineering documentation as ordinary practice, not as a legal exercise, since a file created for legal reasons carries its own date and its own inference.
[ ] Photograph or screenshot the terms as presented, periodically, since the enforceability question turns on presentation and web pages change.
[ ] Archive the whole submission cycle at programme close, indexed, since disputes arrive years later and the people who ran the programme will have moved on.
[ ] [Gate] Seven habits, each taking seconds, producing the chronology that decides any claim.

Working with the innovation function

[ ] Acknowledge the incentive conflict openly. The programme owner's success metric is submissions received, which pulls against every control here. Pretending the interests align produces a policy nobody follows.
[ ] Give them something they want. A structured intake form produces better data than free-text email; a published decision timeline improves the programme's reputation; a clear statement of purpose makes it easier to promote. Each is also a control.
[ ] Do not make legal the bottleneck. Design so that ordinary submissions flow without legal involvement and only defined categories escalate, since a programme requiring review of everything will stop or route around counsel.
[ ] Attend the review meetings occasionally, since drift from scouting into procurement is visible in how the team talks about submissions long before it appears in any document.
[ ] Be useful about outcomes, not only about risk, since a practitioner who helps convert a good submission into a workable commercial relationship gets brought in early.
[ ] [Gate] The programme was designed with counsel in the room, which is the difference between one that produces records and one that produces only submissions.

Common failures

[ ] No stated purpose, so the terms, the rights taken, and the evaluation design all point different ways. Phase 1.
[ ] No unsolicited submission policy, which addresses the claim most organisations will actually face. Phase 2.
[ ] Terms behind a link at the foot of the page, where enforceability is frequently the whole case. Phase 3.
[ ] An empty reason field on declined submissions. Phase 4.
[ ] The evaluator who is also the builder. Phase 5.
[ ] Engineering that cannot prove what it was doing last quarter. Phase 5.
[ ] Team-level rather than individual assignments at events. Phase 6.
[ ] Official rules published after the first entry, or contradicting the submission terms. Phase 7.
[ ] Selective retention, which is worse than either consistent extreme. Phase 8.
[ ] A licence to evaluate relied on as a licence to commercialise. Phase 9.
[ ] [Gate] None of the ten is currently true of this programme.

A note on proportion and on cost

[ ] Scope by volume and overlap. An organisation receiving a handful of submissions a year in areas it does not develop needs Phases 1, 2, and 3. One receiving hundreds in areas of active development needs everything.
[ ] Never defer Phase 1, which costs one meeting and makes every other decision coherent.
[ ] Never defer Phase 2, which addresses the exposure that arrives without any programme at all.
[ ] Price the terms as drafting and the rest as process design, since the record-keeping is where the actual protection is built and clients expect to pay only for the document.
[ ] Treat the engineering documentation review as a dependency rather than an optional extra, and be willing to say that a programme should not open until it is fixed.
[ ] Reuse the event terms, drafted once and used at every subsequent event.
[ ] Budget a day a year for maintenance, which catches the drift Phase 1 exists to prevent.
[ ] [Gate] Client and adviser have agreed in writing which phases are in scope, and the reasons are recorded rather than assumed.

A closing note

Almost every dispute in this area resolves to a chronology and a record: who sent what and when, who read it, what the company was already doing, and whether any of that was written down at the time.

The doctrine matters and decides very few cases. What decides them is whether the organisation built a process that produced records as a by-product of operating normally.

Which is why the most valuable work happens before any submission arrives — making somebody decide what the programme is for, confirming the engineering organisation documents its own work, and designing an evaluation process that leaves a trail. Do those three and the terms are nearly a formality. Skip them and no terms will be enough.

Key Authorities at a Glance

The foundation is negative: ideas are excluded from copyright by 17 U.S.C. § 102(b) on the principle of Baker v. Selden, and are patentable only as inventions satisfying 35 U.S.C. § 101, § 102, § 103, and § 112. Trade secret protection under 18 U.S.C. § 1836 and § 1839 requires reasonable measures that an unsolicited disclosure undermines.

The surviving claims run on contract and quasi-contract, with Desny v. Wilder the foundational implied-in-fact authority and preemption turning on 17 U.S.C. § 301. Ownership of contributions runs through 17 U.S.C. § 101, § 201, and § 204, with the submitter's own filing option at 35 U.S.C. § 111(b).

| Authority | Phase | | --- | --- | | 17 U.S.C. § 102(b) | Intro — ideas and systems excluded | | Baker v. Selden | Intro — description protected, idea not | | Desny v. Wilder | Intro — implied-in-fact contract | | 17 U.S.C. § 301 | 10 — preemption of state idea claims | | 18 U.S.C. § 1836 | 2 — trade secret claim | | 18 U.S.C. § 1839 | 2 — reasonable measures | | 35 U.S.C. § 101 | Intro — eligibility | | 35 U.S.C. § 102 | Intro — the submission as prior art | | 35 U.S.C. § 103 | Intro — obviousness | | 35 U.S.C. § 112 | Intro — enabling disclosure | | 17 U.S.C. § 101 | 6 — work made for hire categories | | 17 U.S.C. § 201 | 6 — contributors own absent assignment | | 17 U.S.C. § 204 | 6 — signed writing for transfers | | 35 U.S.C. § 111(b) | Submitter — the provisional route |

Further reading is collected at open innovation submission terms, evaluation firewall record, hackathon contributor assignment, prize competition official rules, and independent development evidence.