Clean-Room AI Rewrite: How to Rebuild Any System Architecture Legally

Clean-room reimplementation, also known as "Chinese wall" development, is a method for recreating the functionality of existing software without duplicating its source code. This approach has been validated through several landmark legal cases:

• Phoenix Technologies v. IBM (1984): Phoenix successfully recreated the IBM PC BIOS by employing one team to document the BIOS behavior and another to implement it from those documents alone.
• Sega v. Accolade (1992): This case established that reverse engineering for interoperability purposes is fair use, setting a precedent in the software industry.
• Oracle v. Google (2021): The Supreme Court ruled that Google's reimplementation of Java APIs in Android was fair use, clarifying API copyright boundaries.

The core principle is clear: you can legally replicate what software does (its functionality) without copying how it does it (its implementation).

Traditional clean-room development relies on a strict separation between two teams:

• Analyzes the existing system
• Documents observable behavior, APIs, and input/output formats
• Creates functional specifications
• Does not write implementation code

• Works exclusively from the specifications provided by Team A
• Never accesses the original source code
• Builds the new system based solely on the specs
• Makes independent implementation decisions

This separation acts as a legal firewall, ensuring that Team B's work is independent, even if Team A's analysis involved proprietary systems.

AI introduces new opportunities and challenges in clean-room engineering:

• Describing desired functionality to an AI and having it generate implementations
• Using AI to write code based on your specifications
• Asking AI to explain general algorithms or design patterns
• Having AI review your specification for completeness

• Pasting proprietary source code into an AI and asking it to "rewrite" it
• Requesting AI to "make this code original," which might retain copyrightable structure
• Using AI trained on the specific proprietary codebase you're reimplementing
• Feeding decompiled code to an AI for translation

AI can serve as an ideal Team B in clean-room projects. An AI model that has never been exposed to the original source code can implement functionality from a clean specification with minimal risk of inadvertent copying.

Workflow:

1. Team A (Human): Studies the system and writes specifications.
2. Team B (AI): Implements from specs in a fresh context.
3. Human Review: Ensures AI output is correct and of high quality.
4. Legal Review: Confirms the chain of custody is intact.

This approach is faster than traditional methods, as AI can generate implementations in minutes, allowing for rapid iteration on specifications.

Document the existing system's behavior without accessing the source code:

1. Black-box Testing: Run the software and document every input/output pair.
2. API Documentation: Catalog all endpoints, parameters, and responses.
3. User Documentation: Study official docs, tutorials, and help pages.
4. Protocol Analysis: Capture network traffic, file formats, and data schemas.
5. Error Behavior: Document how the system handles edge cases and failures.

```markdown

Transform your behavioral documentation into a formal specification:

1. Architecture Spec: System components, data flow, integration points.
2. Data Model: Schema definitions, relationships, constraints.
3. API Contract: Every endpoint with request/response schemas.
4. Business Rules: Validation logic, permission checks, computed values.
5. Non-functional Requirements: Performance targets, scalability needs.

The specification must be detailed enough for a developer (or AI) to implement it without referring back to the original system.

With a clean specification in hand:

1. Create a Fresh Environment: New repository, no copies of original code.
2. Choose Your Own Architecture: You're not obligated to match the original structure.
3. Implement from the Spec: Use AI or human developers, working only from your specification.
4. Make Independent Design Decisions: Different language, framework, or patterns are fine.
5. Document Your Decisions: Architecture Decision Records (ADRs) prove independence.

# Example: Starting a clean-room rebuild
mkdir widget-api-v2
cd widget-api-v2
git init

# Create from spec, not from original
claude "Implement the Widget API from this specification:
[paste your behavioral spec]
Use Express.js with TypeScript and PostgreSQL.
Follow REST best practices."

After implementation, verify:

1. Code Comparison: Run plagiarism detection tools (MOSS, JPlag) against the original.
2. Architecture Review: Confirm your structure is substantively different.
3. Decision Audit: Document every architectural choice and why you made it differently.
4. Legal Review: Have counsel review the specification-to-implementation chain.

A common mistake in system rebuilds is attempting to replicate the original architecture. This is both legally risky (it suggests you studied the implementation) and technically wasteful (the original architecture may be outdated).

Instead, start with architecture:

1. Define Your Own Domain Model: Based on business requirements, not the existing schema.
2. Choose Modern Patterns: The original system may be outdated — use current best practices.
3. Design for Your Constraints: Different team size, deployment target, and scale requirements.
4. Prioritize Differently: You know which features matter most from user behavior data.

Starting from a specification rather than code gives you a unique advantage: you can redesign the architecture while preserving functional compatibility.

The original system might use a monolithic architecture with a SQL database. Your rebuild could use:

• Microservices or serverless functions
• A different database (document store, graph DB)
• Event-driven architecture instead of request/response
• A completely different tech stack

As long as the external behavior matches the specification, the internal architecture is entirely your creative work.

A prominent example of clean-room reimplementation is the creation of an open-source database system inspired by a proprietary counterpart. The development team, divided into two distinct groups, followed the clean-room methodology:

1. Clean-Room is a Legal Shield: It proves your implementation is independent, not copied.
2. AI Accelerates Team B: LLMs can implement from specs faster than human teams, with zero contamination risk.
3. Never Feed Original Code to AI: The chain of custody must be clean from specification to implementation.
4. Architecture Independence is a Feature: Different internal design strengthens your legal position.
5. Document Everything: The paper trail is your evidence of independent creation.

Consider clean-room reimplementation when:

• Replacing a vendor's proprietary system you've licensed
• Creating an open-source alternative to commercial software
• Migrating between platforms with incompatible licenses
• Rebuilding a system where the original team or source code is unavailable

Always consult legal counsel before starting a clean-room project. The stakes are high, and jurisdiction-specific nuances matter.

```

The March 2026 Claude Code npm Incident

Not legal advice. This section describes a factual event and the legal questions it raised. If you are conducting a clean-room rewrite with IP liability implications, consult a qualified IP attorney. The legal questions raised here are unsettled as of April 2026.

In March 2026, it was discovered that the Claude Code npm package (the CLI tool published by Anthropic) had inadvertently included minified source code from third-party projects in its bundle — code that was not intended to be distributed or that may have been included without proper license verification.

1. Distribution compliance: Were the third-party licenses satisfied?
2. Training data lineage: If Claude was trained on code similar to or identical to this code, what does that mean for outputs Claude generates that may resemble that code?

Why This Matters for Clean-Room Rewrites

Traditional clean-room process relies on strict information separation: the "dirty team" knows the original system; the "clean team" does not. The clean team writes to specifications provided by a third party, never seeing the original implementation.

The March 2026 incident forces a new question: if your clean team's AI assistant was trained on data that included the original codebase (or similar codebases), does that AI constitute a "dirty" team member?

This is not a purely theoretical question. Most large language models used in coding contexts have been trained on:

• Public GitHub repositories
• npm packages
• StackOverflow answers
• Technical documentation

If the original codebase was publicly available at any point — even temporarily — it is possible that one or more LLMs have that code in their training data.

Practical Guidance: AI as Clean Team, Risks and Mitigations

Not legal advice. The guidance below represents current best practices in the technical community, not settled law. Consult an IP attorney for any clean-room rewrite with material IP liability.

The Core Risk

Using an AI model (Claude, GPT-4, Gemini, or any LLM trained on public code) as your "clean team" creates an unresolved legal question: the model may have been trained on the original codebase, making it impossible to guarantee that its outputs are genuinely independent.

This risk is highest when:

• The original codebase was publicly available on GitHub or npm
• The codebase is distinctive enough that an LLM could reproduce it from training memory
• The rewrite is being done to avoid IP liability (not just for engineering reasons)
• The IP dispute involves a sophisticated counterparty with legal resources

Mitigations

The Industry Position (April 2026)

Major IP law firms advise caution but stop short of prohibiting AI use in clean-room rewrites. The dominant view is:

• The clean-room doctrine was designed for human information boundaries, not AI training data
• Courts have not yet addressed the "trained-on-contaminated-data" theory
• The risk is real but its magnitude is unknown
• Document everything and get legal review for high-stakes rewrites

For most engineering teams, AI assistance in clean-room rewrites is pragmatically acceptable — with documentation — unless the specific codebase and specific counterparty create elevated IP liability risk.