Summary. This toolkit collects the working documents for a clean-room software development project, each with its purpose, owner, timing, a fill-in template, and drafting commentary tied to the governing authority. It includes a master clean-room protocol, a project charter, an element list worksheet, an exposure interview script, clean-team and dirty-team certifications, a former-employee wall memo, lab notebook and specification entry formats, the gatekeeper review standard and log, a question and answer log, communications rules, AI coding tool rules, test reports, an exposure incident record, a closing certification, and a litigation-ready file index. The templates follow one invented project, a robotics company building a driver compatible with a competitor's motion-controller protocol. The commentary explains why each record matters to proving independent creation and defeating trade secret and contract claims, and where privilege and production decisions should be made. A short FAQ and practical takeaways close the toolkit.
How to use this toolkit
A clean room is a process for producing evidence. Copyright infringement requires copying, and independent creation is a complete defense, Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991). The documents below are how a company proves, years later, that the people who wrote its code never had access to the protected expression in the product it was built to work with, and that the people who did have access obtained it lawfully and passed along only functional requirements. They also answer the trade secret and contract claims that usually accompany a copyright claim in these disputes.
The sample entries follow one invented project. Brightwater Robotics, Inc., a Pittsburgh maker of collaborative robot arms, is building firmware that lets its arms exchange motion commands with Kestrel Motion Systems' KX-series controllers over Kestrel's proprietary serial protocol. Brightwater's sources are Kestrel's public product manuals, a used KX-400 controller, observation at a customer site (Halvorsen Packaging), and serial captures in Brightwater's lab. Brightwater recently hired a firmware engineer who worked at Kestrel for six years.
The step-by-step narrative is in Running a Clean Room Software Development Project: A Practical Guide; clearance before the project starts is in Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist; and the doctrine is in Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering.
| Template | Owner | Stage |
|---|---|---|
| 1. Master clean-room protocol | Project counsel; signed by executive sponsor | Before staffing |
| 2. Project charter and objective | Executive sponsor, counsel | Before staffing |
| 3. Element list worksheet | Dirty-team lead, counsel | Start of investigation |
| 4. Exposure interview script and record | Counsel or HR, with counsel | Before assignment |
| 5. Clean-team certification and undertaking | Each clean-team member | Before access to any specification |
| 6. Dirty-team undertaking | Each dirty-team member | Before investigation |
| 7. Former-employee acknowledgment and wall memo | Counsel, HR, the employee | On hire or on identification |
| 8. Lab notebook and source log | Dirty team | Throughout investigation |
| 9. Specification entry record | Dirty team, then gatekeeper | Throughout |
| 10. Gatekeeper review standard and review log | Gatekeeper | Throughout |
| 11. Clean-team question and answer log | Gatekeeper | Throughout |
| 12. Communications rules | Counsel; posted for all staff | Before staffing |
| 13. AI coding tool rules | Counsel, engineering, IT | Before staffing |
| 14. Compatibility test report | Test team | Through release |
| 15. Exposure incident report and remediation record | Counsel, records custodian | On any breach |
| 16. Closing certification | Each team member | At release and on departure |
| 17. Litigation-ready file index | Records custodian | Throughout |
Template 1: Master clean-room protocol
Purpose: the governing rules for the project, signed by a senior officer so that compliance is a company obligation. Owner: project counsel drafts; the executive sponsor signs. When to use: before anyone is assigned.
[COMPANY] CLEAN-ROOM DEVELOPMENT PROTOCOL
Project: [PROJECT NAME] Version: [X.Y] Effective: [DATE]
Executive sponsor: [NAME, TITLE] Project counsel: [NAME]
Gatekeeper: [NAME] Records custodian: [NAME]
1. Objective. [ONE-SENTENCE COMPATIBILITY OBJECTIVE FROM TEMPLATE 2.]
2. Target. [TARGET PRODUCT, VERSIONS], made by [OWNER]. "Target
Materials" means the Target's software in any form (source, object,
disassembled, decompiled), its documentation, SDKs, sample code,
partner materials, and any non-public information about it.
3. Teams. The Dirty Team studies the Target using only Approved
Sources (Schedule A) and writes Specification Entries. The Clean
Team writes [PRODUCT] using only Released Specification Entries.
No person may serve on both teams. A person who leaves the Dirty
Team may not join the Clean Team for this product.
4. Approved Sources. Only the sources in Schedule A may be used.
Adding a source requires counsel's written approval. Prohibited in
all cases: [LIST, e.g., disassembly of firmware; any Target account
or server; partner-only documentation; leaked material; information
from current or former Target personnel].
5. Specification. Specification Entries describe required external
behavior in [COMPANY]'s own words. They contain no Target code,
pseudocode tracking Target code, internal Target names, or text
copied or closely paraphrased from Target documentation.
6. Gatekeeper. Every Specification Entry and every answer to a Clean
Team question is reviewed and released by the Gatekeeper under the
Review Standard (Template 10). Nothing reaches the Clean Team
except through the Gatekeeper, in writing.
7. Communications. All staff follow the Communications Rules
(Template 12). No technical discussion of the Target in shared
channels, meetings, or social settings.
8. AI tools. All staff follow the AI Tool Rules (Template 13).
9. Separation. Repositories, document stores, chat channels, tool
workspaces, and lab spaces are separated as set out in Schedule B.
The Records Custodian exports access lists monthly.
10. Records. The Records Custodian maintains the File Index
(Template 17). Records are not altered after creation; corrections
are made by dated addendum.
11. Breaches. Any actual or suspected exposure of a Clean Team member
to Target Materials, or any use of an unapproved source, must be
reported to counsel within one business day (Template 15).
12. Former Target personnel. Current or former employees, contractors,
and partners of [OWNER] serve on neither team and are subject to
Template 7.
13. Duration. This Protocol governs the initial release and all
maintenance releases until counsel terminates it in writing.
Approved: ______________________ [NAME, TITLE] Date: ________
Schedule A: Approved Sources Schedule B: Separation Measures
Drafting commentary. The protocol is the first document an owner's counsel will ask for, and the first question at the sponsor's deposition will be whether it was followed. Write rules the company can actually keep. Section 4's prohibited sources reflect the acquisition problems that defeat reverse-engineering defenses regardless of the clean room: a copy obtained by misrepresentation, Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832 (Fed. Cir. 1992); disassembly in breach of a license, Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003); circumvention without an exemption, 17 U.S.C. § 1201; and server access after revocation, 18 U.S.C. § 1030. Section 3's one-way rule (dirty to clean is never allowed) is the core of the design. Section 10's no-alteration rule matters because metadata will reveal edits, and an edited record is worse than none.
Template 2: Project charter and objective
Purpose: state what the project is for and why each element will be matched. Owner: executive sponsor with counsel. When to use: before staffing; update if the objective changes.
| Field | Entry (sample) |
|---|---|
| Objective (one sentence) | Brightwater arm firmware will exchange motion commands and status messages with Kestrel KX-series controllers over their RS-485 serial port so customers can coordinate Kestrel-driven conveyors with Brightwater arms. |
| Customer need | Halvorsen Packaging and four other customers run Kestrel conveyors; they will not replace them to buy Brightwater arms. |
| What will interoperate | Wire protocol only. No Kestrel software will be distributed, modified, or loaded. |
| What is out of scope | Kestrel's configuration utility, user interfaces, motion-planning algorithms, cloud services, firmware updates. |
| Approved sources | See Protocol Schedule A. |
| Patent clearance | [MEMO REFERENCE]; design constraint on synchronization method. |
| Marketing description | "Works with Kestrel KX-series controllers." No Kestrel logos. |
| Sponsor signature and date | [ ] |
Drafting commentary. In Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), the Court emphasized that Google copied only what programmers needed to carry their skills to a new platform. A charter that states a compatibility purpose, written before the work began, is the best contemporaneous evidence of purpose. Keep the marketing line consistent with the charter; promotional copy framed as substitution is the evidence an owner will use on the first fair use factor after Andy Warhol Foundation for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508 (2023).
Template 3: Element list worksheet
Purpose: list every interface element the product must match, why, and how it will be learned. Owner: dirty-team lead, reviewed by counsel. When to use: at the start of investigation, updated as elements are found.
| E-ref | Element | Why compatibility requires it | Planned source | Copyright classification | Status |
|---|---|---|---|---|---|
| E-01 | Frame structure (start byte, length, address, payload, CRC) | Controller rejects malformed frames | Captures (Source A-3) | Functional; filtered | Specified (S-001) |
| E-02 | Session handshake | Controller ignores commands before handshake completes | Captures; observation at Halvorsen | Functional; DMCA review done | Specified (S-004) |
| E-07 | 34 message types and their codes | Each command and status must be recognized | Public manual (names); captures (codes) | Names in manual: use only where on the wire | In progress |
| E-12 | 61 error codes and conditions | Arm must react to controller faults | Captures; induced faults in lab | Facts / functional | In progress |
| E-20 | Timing (reply within 20 ms; two retries) | Controller times out otherwise | Lab measurement | Functional | Specified (S-019) |
| X-01 | Configuration utility screens | Not required | None | Excluded | Out of scope |
Drafting commentary. The worksheet does the filtration work in advance. Under Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992), elements dictated by compatibility, efficiency, and other external factors are filtered out before comparison; the "Why" column is that argument, written at the time. In SAS Institute, Inc. v. World Programming Ltd., 64 F.4th 1319 (Fed. Cir. 2023), the defendant's showing that the asserted elements were unprotected shifted the burden to the plaintiff to identify what remained protectable. Excluded rows (X-refs) matter as much as included rows.
Template 4: Exposure interview script and record
Purpose: establish, before assignment, whether a person has been exposed to Target Materials. Owner: counsel, or HR with a script approved by counsel. When to use: before assigning anyone to either team; again for any mid-project addition.
EXPOSURE INTERVIEW RECORD
Interviewee: [NAME] Role considered: [CLEAN / DIRTY / TEST]
Interviewer: [NAME] Date: [DATE] Method: [IN PERSON / VIDEO]
Read aloud: "We are asking about your past contact with [OWNER]
and its [TARGET]. Please answer from memory. We are not asking you
to disclose anything you learned in confidence; if a full answer
would require that, say so and stop."
1. Have you ever been employed by, contracted for, or interned at
[OWNER] or any of its partners or resellers? [Y/N, details]
2. Have you ever seen [TARGET]'s source code, disassembled code, or
firmware, from any source (including leaks or forums)? [Y/N]
3. Have you used [TARGET] or its configuration tools? Under whose
license? Did you accept any terms yourself? [Y/N, details]
4. Have you read [TARGET]'s manuals, API references, partner
documentation, or training materials? [Y/N, which]
5. Have you worked on any product designed to interoperate with or
replace [TARGET]? [Y/N, details]
6. Have you contributed to any open-source project related to
[TARGET]? [Y/N]
7. Do you possess any [OWNER] documents or files, in any form? [Y/N]
8. Is there anything else that a reasonable person would consider
exposure to how [TARGET] works internally? [Y/N]
Interviewer's determination: [ELIGIBLE FOR CLEAN TEAM / DIRTY TEAM
ONLY / NEITHER TEAM; REFER TO TEMPLATE 7]
Reason: [ ]
Interviewer signature: _________ Interviewee signature: _________
Drafting commentary. Access is the element a clean room is designed to negate; courts infer copying from access plus probative similarity, Arnstein v. Porter, 154 F.2d 464 (2d Cir. 1946). The interview is the evidence behind the certification in Template 5, and an owner will test it by asking interviewees, at deposition, what they were asked. Question 4 matters because documentation is protected expression, and exposure to it is exposure. The read-aloud instruction avoids inviting a disclosure of the former employer's confidential information. Exposure to the target's public marketing materials ordinarily does not disqualify anyone; record it anyway.
Template 5: Clean-team certification and undertaking
Purpose: each clean-team member's sworn statement of no prior exposure and commitment to the protocol. Owner: each clean-team member; collected by the records custodian. When to use: before any access to the specification; renewed annually and at closing (Template 16).
CLEAN-TEAM CERTIFICATION AND UNDERTAKING
Project: [PROJECT] Protocol version: [X.Y]
I, [NAME], certify:
1. I have read the Protocol and the Communications Rules and AI Tool
Rules, and I will follow them.
2. Before today, I have not seen [TARGET]'s source code, object code
in disassembled or decompiled form, firmware internals,
documentation [other than: LIST ANY PUBLIC MARKETING MATERIALS],
partner materials, or non-public information, except as follows:
[NONE / DESCRIBE].
3. I have not worked for, or under a license from, [OWNER], except:
[NONE / DESCRIBE].
4. I will use only Released Specification Entries and answers
released by the Gatekeeper. I will not seek information about
[TARGET] from any other source, including the internet, colleagues,
AI tools, or former [OWNER] personnel.
5. If I am exposed to Target Materials, I will stop work on the
affected component and report to counsel within one business day.
I declare under penalty of perjury under the laws of the United
States of America that the foregoing is true and correct.
Executed on [DATE] at [CITY, STATE].
______________________ [NAME]
Drafting commentary. The closing sentence is the form prescribed for unsworn declarations executed within the United States, 28 U.S.C. § 1746, so the certification can be filed with a court as is. Certifications are only as good as their truth: a single contradicted certification can cast doubt on the whole file. Paragraph 4's ban on internet research addresses the commonest leak. Subconscious copying is still copying, Bright Tunes Music Corp. v. Harrisongs Music, Ltd., 420 F. Supp. 177 (S.D.N.Y. 1976), which is why the certification addresses exposure rather than intent.
Template 6: Dirty-team undertaking
Purpose: bind dirty-team members to approved sources and the gatekeeper channel. Owner: each dirty-team member. When to use: before investigation.
DIRTY-TEAM UNDERTAKING
I, [NAME], agree:
1. I will use only Approved Sources listed in Protocol Schedule A,
as amended in writing by counsel.
2. I will not decompile, disassemble, circumvent any technical
measure, use any [OWNER] account or server, or use any partner or
confidential [OWNER] material, unless counsel has approved that
activity in writing for a specific purpose.
3. I will record every observation in the Lab Notebook with its
source (Template 8).
4. I will communicate with Clean Team members about [TARGET] or
[PRODUCT] only through the Gatekeeper, in writing.
5. I will not join the Clean Team for [PRODUCT].
6. I will report any use of an unapproved source within one business
day.
Signed: __________ Date: ______
Drafting commentary. Paragraph 2 exists because the leading reverse-engineering fair use holdings are conditioned on necessity and lawful acquisition. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) held disassembly fair use where it is the only way to reach unprotected functional elements and there is a legitimate reason, and Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000) extended that to repeated intermediate copying while building a replacement. Writing approval for each intrusive step creates the record of necessity. If circumvention is approved, the written approval should identify the 17 U.S.C. § 1201(f) basis or the exemption at 37 C.F.R. § 201.40 relied on.
Template 7: Former-employee acknowledgment and wall memo
Purpose: protect against trade secret claims arising from hiring the owner's former personnel. Owner: counsel and HR, signed by the employee. When to use: on hire, or as soon as a current employee's prior relationship is identified.
ACKNOWLEDGMENT (EMPLOYEE)
I, [NAME], formerly [TITLE] at [OWNER] from [DATE] to [DATE],
acknowledge:
1. I have returned or destroyed all [OWNER] documents, files, code,
and devices, and I have retained no copies in any form, including
personal email, cloud storage, or personal devices. [IF ANY ARE
FOUND: I will report them to [COMPANY] counsel immediately and not
open them.]
2. I will not use or disclose [OWNER]'s confidential information or
trade secrets in my work for [COMPANY].
3. I will not participate in, advise on, or discuss with anyone the
technical work on [PROJECT], and I will not answer questions about
how [TARGET] works internally.
4. I understand that [COMPANY] does not want and will not accept any
[OWNER] confidential information.
Signed: __________ Date: ______
WALL MEMO (TO PROJECT STAFF)
[NAME] has joined [COMPANY] as [ROLE]. [NAME] is not a member of
either project team and must not be asked about [TARGET] or
[PROJECT]. Do not discuss the project with [NAME]. Report any
contact on these subjects to [COUNSEL]. IT has excluded [NAME] from
project repositories and channels.
Drafting commentary. The Defend Trade Secrets Act defines misappropriation to include use or disclosure by a person who knew or had reason to know the secret was acquired under a duty to maintain its secrecy, 18 U.S.C. § 1839(5), and authorizes injunctions and damages, 18 U.S.C. § 1836. The company's best defense is proof that it never wanted, received, or used the information. State trade secret claims typically survive copyright preemption because they require a breach of confidence, Data General Corp. v. Grumman Systems Support Corp., 36 F.3d 1147 (1st Cir. 1994). In the Brightwater project, Priya Natarajan signs the acknowledgment on her first day and is assigned to customer integration. For the full onboarding and departure program, see Employee Departure Trade Secret Protection Checklist: A Practical Checklist and Trade Secret Protection Toolkit: Building and Defending a Confidentiality Program.
Template 8: Lab notebook and source log
Purpose: tie every fact the dirty team learns to an approved source. Owner: each dirty-team member. When to use: every working session.
| N-ref | Date and time | Engineer | Source (Schedule A ref) | Activity | Observation (own words) | Artifacts (file, hash) | Used in |
|---|---|---|---|---|---|---|---|
| N-0112 | [DATE] 14:05 | D. Okafor | A-3 (lab captures, KX-400 serial no. [ ]) | Sent STATUS request at 9600 and 115200 baud | Controller replied only at 115200; 12-byte reply; byte 0 = 0x7E | cap_0112.bin, [SHA-256] | S-001, S-019 |
| N-0147 | [DATE] 10:30 | L. Ferreira | A-2 (Halvorsen site observation, per letter of [DATE]) | Watched conveyor fault recovery | After an E-STOP, the conveyor waited for a RESET message before accepting motion commands | Video log 0147 (Halvorsen-approved) | S-022 |
Drafting commentary. The notebook answers the owner's argument that the specification "must have come from the code." Keep observations in the engineer's own words; copying the target's manual into the notebook brings protected expression into the dirty files, and those files may be compared with the specification in discovery under Fed. R. Civ. P. 34. Hash the artifacts so their integrity can be shown under Fed. R. Evid. 901. Observation of a customer's installation should rest on the customer's written permission, consistent with its own license.
Template 9: Specification entry record
Purpose: the unit of transfer between teams. Owner: dirty team drafts; gatekeeper releases. When to use: for each element or group of related elements.
SPECIFICATION ENTRY S-[NNN] Version [N] Element(s): E-[NN]
Status: [DRAFT / IN REVIEW / RELEASED / SUPERSEDED]
Requirement:
[WHAT THE PRODUCT MUST DO, IN OBSERVABLE TERMS]
Details:
[TABLES OF FIELDS, OFFSETS, LENGTHS, TYPES, VALID VALUES; STATE
DIAGRAMS; TIMING; ERROR BEHAVIOR]
Test vectors:
[INPUT -> EXPECTED OUTPUT PAIRS, GENERATED FROM THE TARGET]
Why compatibility requires this:
[ONE OR TWO SENTENCES]
Supporting notebook entries: N-[ ], N-[ ]
Names used from the Target, if any, and why: [e.g., message name
"STATUS" appears on the wire and in the public manual; required]
Not specified (Clean Team free to choose): [e.g., buffer strategy,
retry implementation, data structures]
Sample (released):
S-001, Version 3. Element E-01. Each frame consists of a start byte (0x7E), a one-byte length (number of bytes after the length byte, excluding the CRC), a one-byte device address (0x01 to 0x1F), a payload, and a two-byte CRC computed with polynomial 0x8005, initial value 0xFFFF, over the length, address, and payload bytes, transmitted low byte first. The controller silently discards frames with a bad CRC. Test vectors: TV-001 to TV-014. Why: the controller rejects any other framing. Notebook: N-0112, N-0115, N-0131. Not specified: how the product assembles frames or computes the CRC.
Drafting commentary. The "Not specified" line is deliberate: it tells the clean team where its own design choices begin, and it shows later that the specification described results, not the target's methods. Abstraction is the craft; the entry above states a compatibility requirement, while "loop over the buffer with a lookup table as the target does at address 0x4F20" would describe the target's implementation. The Altai court found that a rewritten program, produced by programmers working from a description rather than the original code, did not infringe because what survived in it after filtration was unprotected. Where the product must expose the same function names and signatures as the target's API, the entry should list only the declarations external programs call, consistent with Google.
Template 10: Gatekeeper review standard and review log
Purpose: apply a written, consistent standard to everything that crosses to the clean team. Owner: the gatekeeper. When to use: every specification entry and every answer.
Review standard. Release an entry only if all are true:
- It contains no target code, disassembly, or pseudocode that tracks the target's control flow.
- It contains no internal target names (functions, variables, files, comments) that external programs do not observe.
- It contains no text copied or closely paraphrased from target documentation; target names used are only those required on the wire or in the external interface.
- Every fact is supported by a cited notebook entry from an approved source.
- It describes required external behavior, not the target's internal method.
- It is limited to elements on the element list.
| Log ref | Entry and version | Received | Reviewer | Decision | Changes or reasons | Released |
|---|---|---|---|---|---|---|
| G-031 | S-007 v1 | [DATE] | [NAME] | Rejected | Paragraph 2 paraphrases public manual section 4.3 sentence by sentence; rewrite from N-0140 observations | No |
| G-032 | S-007 v2 | [DATE] | [NAME] | Released with edit | Removed reference to "task scheduler slot"; internal and not observable | [DATE] |
| G-040 | S-011 v1 | [DATE] | [NAME] | Rejected | Source N-0151 cites a forum post; not an approved source | No |
Drafting commentary. The review log is the record that answers "how do you know nothing from the target's code reached the clean team?" If a lawyer serves as gatekeeper, decide at the outset that the review log and released entries are process records intended for production, and keep counsel's legal analysis (clearance memos, privileged advice) in a separate file. A party that relies on its clean room as a defense should expect to produce the materials that show how it worked; selective withholding invites an at-issue waiver argument. In litigation, seek an order under Fed. R. Evid. 502(d) so that inadvertent production of privileged material does not waive privilege. Lawyer-supervised technical reviewers raise supervision duties under ABA Model Rule 5.3.
Template 11: Clean-team question and answer log
Purpose: route every clean-team question through the gatekeeper and preserve the answer. Owner: the gatekeeper. When to use: every question.
| Q-ref | Date | From (clean) | Question | Forwarded to (dirty) | Answer as released | Spec update | Released |
|---|---|---|---|---|---|---|---|
| Q-088 | [DATE] | M. Chen | S-019 says reply within 20 ms. Is that from end of request or start? | D. Okafor | From the last byte of the request frame to the first byte of the reply. (N-0198) | S-019 v2 | [DATE] |
| Q-104 | [DATE] | R. Alvarez | Does the controller accept two motion commands without waiting for an ACK? | L. Ferreira | Released answer: No; the second command is discarded and error 0x21 returned. (N-0205) Edited by gatekeeper to remove dirty team's explanation of why, which referred to internal buffering. | S-024 v1 | [DATE] |
Drafting commentary. Questions are where informal communication creeps in. A rule that every answer is written, reviewed, logged, and incorporated into the specification keeps the specification complete and prevents a side channel. The Q-104 edit shows the gatekeeper doing the job: the clean team needs the behavior, not the target's reason for it.
Template 12: Communications rules
Purpose: a one-page rule set every staff member can follow. Owner: counsel; posted in the project space and acknowledged by all project staff. When to use: before staffing.
CLEAN-ROOM COMMUNICATIONS RULES: [PROJECT]
1. Dirty Team and Clean Team members do not discuss [TARGET] or
[PRODUCT] technical details with each other. Ever. Anywhere.
2. The only channel between teams is the Gatekeeper queue
[TOOL/LOCATION]. Written only.
3. No shared chat channels, meetings, or documents for project
technical work. All-hands meetings may discuss schedule and status,
not how [TARGET] works.
4. Managers who supervise both teams discuss only staffing, schedule,
and budget.
5. Do not forward, screenshot, or summarize Dirty Team materials to
anyone outside the Dirty Team.
6. Clean Team: do not search for information about [TARGET]'s
protocol, code, or internals online. If you land on such material
by accident, close it and report it (Template 15).
7. Former [OWNER] personnel: do not discuss [TARGET] internals with
anyone at [COMPANY].
8. Social settings count. If someone starts a conversation about
[TARGET] internals, stop it.
9. Questions about these rules go to [COUNSEL].
Drafting commentary. The owner will depose engineers about hallway and lunchroom conversations under Fed. R. Civ. P. 30. Short, absolute rules are easier to follow and easier to testify about than nuanced ones. Rule 4 addresses the shared manager, a frequent weak point in small companies.
Template 13: AI coding tool rules
Purpose: close the contamination and record gaps that AI coding assistants open. Owner: counsel, engineering leadership, and IT. When to use: before staffing; review whenever tools change.
AI TOOL RULES: [PROJECT]
1. Approved tools: [TOOL, PLAN/TIER]. No personal accounts.
2. Configuration: prompts and outputs retained for [PERIOD]; vendor
does not train on inputs; code-reference / public-code matching
filter ON; internet browsing and autonomous agents OFF for the
Clean Team.
3. Workspaces: separate Dirty and Clean workspaces. No shared
context, retrieval index, memory, or connected repositories across
teams.
4. Clean Team prompts must not name or describe [TARGET], [OWNER], or
their products, and must not include anything outside Released
Specification Entries and Clean Team code.
5. Dirty Team must not upload [TARGET] code, documentation, or
captures to any AI tool without counsel's written approval.
6. AI-assisted Clean Team code is reviewed like other code, and a
reviewer outside the Clean Team runs a similarity scan against
any known public versions of [TARGET] code.
7. Records Custodian exports prompt/output logs [MONTHLY] to the
clean-room file.
8. Report any rule breach under Template 15.
Drafting commentary. A model that learned the target's code from public sources (an open-source edition, sample code, a leak) can reproduce it, and the clean team will then have been exposed to it through the tool. Litigation over AI coding assistants, notably Doe v. GitHub, Inc. in the Northern District of California, has focused in part on claims under 17 U.S.C. § 1202 for removal of copyright management information; the district court dismissed those claims because the outputs were not identical copies, and the Ninth Circuit took up that question on interlocutory appeal, so check for the appellate decision before relying on it. District courts in 2025 also issued the first significant rulings on fair use in training generative models, including in the Northern District of California, and none of them addresses clean-room contamination directly. Rule 5 also protects the company: uploading third-party code may breach the target's license and disclose information the company is obligated to keep confidential. For the broader policy, see AI Confidentiality Toolkit: Acceptable Use Policies, Vendor Term Reviews, and Incident Playbooks and Trade Secrets and Generative AI: Reasonable Measures, Prompt Leakage, and Vendor Terms.
Template 14: Compatibility test report
Purpose: report test results to the clean team without transmitting how the target works. Owner: test team (dirty team or a separate group). When to use: each test cycle.
| T-ref | Build | Test vector or scenario | Result | Report to Clean Team (as released) | Spec change needed? |
|---|---|---|---|---|---|
| T-0412 | fw 0.9.3 | TV-031 (motion command, max velocity) | Fail | Controller returned error 0x21 to frame 3 of the sequence. | No |
| T-0419 | fw 0.9.4 | Scenario SC-07 (E-STOP recovery) | Fail | Controller did not resume after RESET; see S-022 v2 (released today). | Yes: S-022 v2 |
Drafting commentary. Testing is the most common leak because it requires running the clean product against the target, and testers want to help. Pass/fail reports, with any new behavior turned into a reviewed specification entry, keep testing inside the protocol. Raw protocol captures may contain firmware update payloads or embedded code; do not forward them.
Template 15: Exposure incident report and remediation record
Purpose: document and remediate any breach. Owner: the reporting person, counsel, and the records custodian. When to use: within one business day of any actual or suspected exposure or unapproved source.
EXPOSURE INCIDENT REPORT I-[NN]
Reported by: [NAME] Date/time: [ ] Incident date: [ ]
Person exposed: [NAME, TEAM]
What was seen or used: [DESCRIBE; DO NOT ATTACH TARGET MATERIAL]
How: [e.g., search result opened a forum post with disassembly]
Duration and extent: [ ]
Components the person had worked on: [ ]
Counsel assessment (privileged section filed separately): [Y]
Remediation:
[ ] Person removed from affected component / Clean Team on [DATE]
[ ] Code written by person after exposure reviewed by [NAME]; result
[ ] Code rewritten by unexposed engineer (component, commit range)
[ ] Source added to prohibited list; staff reminder issued
Closed by: [COUNSEL] Date: [ ]
Drafting commentary. Breaches happen. A documented breach with prompt remediation is far less damaging than one discovered in discovery, and Altai itself is the model: Altai discovered that an employee had brought in its competitor's code, rewrote the affected modules with programmers who had not seen it, and the rewritten version was held non-infringing. Keep the factual report as a process record and counsel's assessment as a separate privileged document.
Template 16: Closing certification
Purpose: confirm compliance at release, at departure, and at project close. Owner: each team member. When to use: at release; when anyone leaves a team; at protocol termination.
CLOSING CERTIFICATION
I, [NAME], member of the [CLEAN / DIRTY / TEST] team from [DATE]
to [DATE], certify that during that period I complied with the
Protocol, Communications Rules, and AI Tool Rules, except as
disclosed in Incident Report(s) [NONE / I-NN]. [CLEAN TEAM: I did
not see Target Materials or receive information about [TARGET]
other than Released Specification Entries and Gatekeeper-released
answers.] I have returned all project materials.
I declare under penalty of perjury under the laws of the United
States of America that the foregoing is true and correct.
Executed on [DATE] at [CITY, STATE]. __________ [NAME]
Drafting commentary. Engineers leave, and they may be unavailable or unfriendly when litigation arrives years later. A closing certification captured while memories are fresh, in the form permitted by 28 U.S.C. § 1746, preserves their account. It does not substitute for live testimony, but it anchors it.
Template 17: Litigation-ready file index
Purpose: make the clean-room file usable in litigation on short notice. Owner: the records custodian. When to use: maintained throughout; frozen at release.
| Tab | Contents | Format | Privileged? | Custodian | Bates range (when produced) |
|---|---|---|---|---|---|
| 1 | Protocol, all versions, with schedules | PDF, signed | No | Legal ops | [ ] |
| 2 | Project charter and element list | PDF; spreadsheet | No | Legal ops | [ ] |
| 3 | Team rosters with dates | Spreadsheet | No | Legal ops | [ ] |
| 4 | Exposure interviews and certifications | PDF, signed | No | Legal ops | [ ] |
| 5 | Former-employee acknowledgments and wall memos | PDF, signed | No | HR, legal ops | [ ] |
| 6 | Access-control exports (monthly) | CSV with hashes | No | IT | [ ] |
| 7 | Dirty-team lab notebooks and artifacts | Native, hashed | No | Dirty-team lead | [ ] |
| 8 | Specification entries, all versions | Repository export | No | Gatekeeper | [ ] |
| 9 | Gatekeeper review log | Spreadsheet | No | Gatekeeper | [ ] |
| 10 | Question and answer log | Spreadsheet | No | Gatekeeper | [ ] |
| 11 | Test reports | Spreadsheet | No | Test lead | [ ] |
| 12 | AI tool configuration and exported logs | Native | No | IT | [ ] |
| 13 | Incident reports (factual sections) | No | Legal ops | [ ] | |
| 14 | Closing certifications | PDF, signed | No | Legal ops | [ ] |
| 15 | Clean-team repository, full history | Repository bundle | No | Engineering | [ ] |
| 16 | Counsel clearance memos and incident assessments | Yes | Counsel | Privilege log |
Drafting commentary. When the owner's demand letter arrives, a litigation hold should issue promptly, and automatic deletion must be suspended; loss of electronically stored information that should have been preserved can draw sanctions under Fed. R. Civ. P. 37(e). Voluminous logs can be presented through summaries under Fed. R. Evid. 1006, and expert comparison of the codebases under Fed. R. Evid. 702 will rely on Tabs 7 to 15. Source code productions are usually governed by a protective order limiting access to outside counsel and experts, Brown Bag Software v. Symantec Corp., 960 F.2d 1465 (9th Cir. 1992); see Negotiating a Protective Order and Filing Under Seal: A Practical Guide and Litigation Hold and Evidence Preservation Checklist: A Practical Checklist. Comparison charts for the defense are in Copyright Infringement Litigation Toolkit: Similarity Charts, Expert Reports, and Filtration Analyses.
Frequently asked questions
Do all seventeen templates have to be used? No. A small project might combine the charter and element list, use a single certification form for all team members, and dispense with separate test reports if the dirty team tests. Templates 1, 3, 5, 9, 10, and 17 are the minimum for a defensible file.
Should the certifications be notarized? Not necessary. A declaration under penalty of perjury in the form of 28 U.S.C. § 1746 can be used in federal court in place of a sworn affidavit.
Can the gatekeeper's review log be withheld as privileged? Plan on producing it. It is the core evidence of how the clean room worked. Keep legal analysis in separate privileged memos.
How long should the file be kept? For the life of the product plus several years. The copyright limitations period is three years from accrual, 17 U.S.C. § 507(b), but continuing distribution keeps claims alive, and contract claims may have longer periods.
Do these templates help against patent claims? No. Independent development is not a defense to infringement under 35 U.S.C. § 271. Run a separate patent clearance.
Practical takeaways
- Sign the protocol before anyone is assigned, and make the rules short enough to follow.
- Interview before certifying, and keep the interview record.
- Keep former employees of the owner off both teams and document the wall.
- Tie every specification fact to a notebook entry from an approved source.
- Apply a written gatekeeper standard and log every decision.
- Treat AI tools as a contamination channel and keep their logs.
- Build the file index from day one, and expect to produce everything but counsel's analysis.
This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.
Related Documents
Related Articles
- Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering: the doctrine the templates are designed to satisfy.
- Legal Protection of Software: Copyrights, Patents, Trade Secrets, and Contracts: the protection regimes that shape the protocol's prohibited sources.
- Trade Secrets and Generative AI: Reasonable Measures, Prompt Leakage, and Vendor Terms: the trade secret side of Template 13.
- Failed Software Implementations: Contract, Fraud, and Warranty Claims When an IT Project Goes Wrong: failed technology projects and the contract, warranty, and fraud claims that follow.
Related Guides
- Running a Clean Room Software Development Project: A Practical Guide: when and how each template is used, step by step.
- Negotiating a Protective Order and Filing Under Seal: A Practical Guide: protecting the file and source code in litigation.
- Litigating Substantial Similarity in a Copyright Case: A Practical Guide: how the records are used to answer a similarity claim.
- Pursuing or Defending a Failed Technology Project Claim: A Practical Guide: failed technology projects and the contract, warranty, and fraud claims that follow.
Related Checklists
- Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist: the clearance work behind Schedule A of the protocol.
- Employee Departure Trade Secret Protection Checklist: A Practical Checklist: the other side of Template 7.
- Litigation Hold and Evidence Preservation Checklist: A Practical Checklist: preserving the Template 17 file.
- Troubled Technology Project Checklist: A Practical Checklist: failed technology projects and the contract, warranty, and fraud claims that follow.
Related Toolkits
- Copyright Infringement Litigation Toolkit: Similarity Charts, Expert Reports, and Filtration Analyses: filtration and comparison charts that draw on the specification.
- Trade Secret Protection Toolkit: Building and Defending a Confidentiality Program: confidentiality controls behind the former-employee wall.
- AI Confidentiality Toolkit: Acceptable Use Policies, Vendor Term Reviews, and Incident Playbooks: broader AI tool policies.
- Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols: failed technology projects and the contract, warranty, and fraud claims that follow.