How to Find Inventions in a Codebase

Most software inventions do not arrive as ideas labeled invention.

They arrive as a pull request titled "fix stale cache," an incident review, a new scheduling rule, a custom data structure, a workaround for an unreliable vendor API, or a control loop that made the system survive conditions the standard architecture could not.

The mistake is searching for impressive features. The better search is for technical divergence:

Where did the team stop using the ordinary solution and create its own mechanism?

This page provides a repeatable code-review method for surfacing those mechanisms. It identifies candidates for documentation and practitioner review, not patentability conclusions.

Where Inventions Actually Hide

Pitch decks describe products. Code records technical decisions.

The richest evidence is often found in:

Pull-request descriptions and review comments.
Architecture decision records.
Incident reports and postmortems.
Performance benchmarks.
Migration plans.
Test fixtures built around unusual edge cases.
Custom infrastructure replacing standard libraries.
Feature flags and fallback paths.
Commit sequences showing an abandoned conventional approach.
Issue threads explaining why the original design failed.

A source file by itself may show what the system does. The surrounding history often explains why the mechanism exists and what makes it different.

Twelve Code Patterns Worth Reviewing

These patterns are not automatically patentable. They are high-yield places to ask better questions.

1. The standard solution failed

Look for comments and pull requests containing language such as:

"The library cannot handle..."
"We had to bypass..."
"The default algorithm becomes unstable when..."
"We replaced the vendor implementation because..."

The workaround may contain the invention, not because it is custom, but because it solves a technical limitation through a new relationship or sequence.

2. Adaptive thresholds and control loops

Static rules often become adaptive mechanisms:

Thresholds that change with load, uncertainty, recency, or risk.
Controllers that select among algorithms according to observed state.
Feedback loops that continuously revise resource allocation.
Confidence-aware routing or verification.

Ask what is measured, how the measurement changes behavior, and what technical effect results.

3. Failure recovery and graceful degradation

Recovery logic is frequently dismissed as plumbing. It can be the technically distinctive part of the system:

Reconstructing state after partial loss.
Switching execution paths without duplicating work.
Maintaining service under inconsistent dependencies.
Rolling back only the affected part of a deployment.
Detecting and containing cascading failure.

4. Concurrency and consistency

Review mechanisms for:

Conflict resolution.
Ordering and deduplication.
Lock avoidance.
Eventual consistency.
Concurrent-write handling.
Deterministic merge behavior.

The important concept may be the rule for reconciling state, not the database or framework.

5. Caching, indexing, and retrieval

Look beyond "we added a cache."

Potentially distinctive mechanisms include:

Selective rather than global invalidation.
Adaptive eviction.
Semantic or graph-based neighbor selection.
Index updates that avoid rebuilding the whole structure.
Retrieval strategies that balance latency, quality, and freshness.

6. Distributed coordination

Inspect code that decides:

Which node performs an operation.
How ownership moves.
How partial results are combined.
How work is retried without duplication.
How the system behaves when connectivity is intermittent.

7. Security and privacy enforcement

Strong candidates often appear where policy becomes mechanism:

Selective disclosure.
Privacy-preserving aggregation.
Credential rotation.
Isolation of compromised components.
Context-sensitive authorization.
Secure synchronization without centralizing raw data.

"We comply with policy" is an outcome. The technical enforcement process is the mechanism.

8. New representations and data structures

Review custom:

Trees, graphs, indexes, sketches, vectors, and compact state models.
Data layouts designed for a particular access pattern.
Representations that enable a new operation or reduce resource use.
Transformations that preserve one property while removing another.

9. Resource-aware execution

Search for code that predicts or responds to:

Memory pressure.
Bandwidth limits.
Battery state.
Compute availability.
Cost ceilings.
Latency requirements.

The invention may be the decision architecture that selects, partitions, batches, compresses, or postpones work.

10. Model training and inference orchestration

For AI systems, examine more than the model itself:

Routing among models.
Fallback and verification.
Drift detection.
Incremental training.
Data filtering and labeling.
Privacy-preserving updates.
Caching and reuse of intermediate representations.
Evaluation systems that alter deployment behavior.

"Use an LLM" is usually not the invention. The surrounding technical system may be.

11. Integration boundaries

Adapters and translation layers can contain distinctive mechanisms when they reconcile incompatible guarantees:

Different identity systems.
Conflicting transaction models.
Inconsistent schemas.
Synchronous and asynchronous protocols.
Legacy and modern systems.

The key question is not that two systems were connected, but how the boundary preserves correctness or performance.

12. Observability and self-healing

Review systems that do more than report metrics:

Diagnose likely failure causes.
Change execution based on telemetry.
Predict overload.
Isolate anomalous components.
Repair state automatically.

A Repeatable Seven-Step Mining Process

Step 1: Choose a meaningful review window

Do not begin by scanning an entire ten-year repository. Start with one of these:

The last major release.
A quarter of pull requests.
A difficult migration.
A high-value product subsystem.
A major reliability or performance initiative.
Work completed before an upcoming public launch.

Step 2: Build a divergence queue

Flag artifacts that contain:

Custom algorithmic logic.
Replaced standard components.
Nontrivial retry or recovery behavior.
Performance-sensitive code.
Complex state transitions.
Explicit architectural tradeoffs.
Unexpected test cases.

The queue is not a list of inventions. It is a list of places where ordinary engineering assumptions changed.

Step 3: Ask why the standard approach was insufficient

For each candidate, capture:

The ordinary approach.
The technical condition under which it failed.
The mechanism the team introduced.
The resulting technical effect.
The tradeoff or constraint the team accepted.

This problem-mechanism-effect chain is much more useful than a feature summary.

Step 4: Extract the implementation invariant

Ask:

What remains true if the language, framework, cloud, model, database, or device changes?

Then ask the opposite:

Which details are essential according to the actual design, and which are merely one implementation?

The goal is not maximum abstraction. It is an accurate technical concept that survives ordinary implementation substitutions.

Step 5: Map the concept back to evidence

A useful candidate should link to:

Files and line ranges.
Commits and pull requests.
Design documents.
Tests.
Benchmarks.
Incident reports.
Contributor discussions.

Evidence allows engineers and counsel to verify the technical story instead of trusting an AI-generated summary.

Step 6: Triage business and protection fit

Rate the candidate on separate dimensions:

Dimension	Question
Technical distinctiveness	Did the team create a nonstandard mechanism?
Technical effect	Does it improve operation, performance, security, reliability, or resource use?
Product importance	Is it central to revenue, differentiation, or defensibility?
Detectability	Could competitor use be observed or inferred?
Design-around difficulty	Can the mechanism be replaced easily?
Secrecy durability	Can it remain hidden in a server-side system?
Disclosure urgency	Is publication, sale, demo, or open-source release approaching?
Ownership clarity	Are contributors and assignments known?

Do not collapse these into one "patentability score." They answer different questions.

Step 7: Create a lightweight invention flag

For every promising candidate, record:

One-sentence problem.
One-sentence mechanism.
One-sentence technical effect.
Contributor names.
Evidence links.
Planned disclosure date.
Product or business relevance.

Then use the [Invention Disclosure Procedure](/invention-disclosure-procedure) for the candidates selected for deeper review.

A 30-Minute Code Review Agenda

Minutes 0–5: Select the change

Choose one architecture decision, incident fix, or high-impact pull request.

Minutes 5–15: Reconstruct the technical problem

Ask the engineers:

What failed?
What did the normal solution do?
What constraint made it unusable?
What alternatives did you reject?

Minutes 15–22: Describe the mechanism

Draw the components and data flow. Identify state, transformations, decisions, and feedback.

Minutes 22–27: Identify alternatives

What could be centralized, distributed, synchronous, asynchronous, model-based, rule-based, client-side, server-side, or edge-based?

Minutes 27–30: Record the evidence and dates

Link the code and note contributors, public artifacts, and the next planned release.

The output should be a review queue, not a patent filing decision.

What Not to Count as an Invention Candidate

Avoid inflating the pipeline with:

Routine use of a known library.
A configuration change with no new technical mechanism.
A product idea stated only through user value.
A generic request to "add AI."
Ordinary refactoring.
A bug fix that restores expected behavior without introducing a distinct method.
Code volume or complexity by itself.

A small function can implement a powerful concept. A large subsystem can be entirely conventional.

Where AI Helps, and Where It Fails

AI can help:

Summarize unfamiliar modules.
Cluster related code changes.
Identify unusual control flow and custom algorithms.
Extract problem-mechanism-effect statements from pull requests.
Link candidate concepts to code evidence.
Generate questions for inventor interviews.

AI should not decide:

Patentability.
Inventorship.
Ownership.
Whether prior art renders a claim obvious.
Whether public disclosure has affected rights.
Whether a patent, trade secret, or publication is the right strategy.

The best output is not "this code is patentable." It is:

Here is a distinctive technical mechanism, the engineering evidence that supports it, the contributors who may know its history, and the questions counsel should examine.

Metrics for an Engineering IP Program

Useful metrics include:

Percentage of major architecture changes reviewed.
Median days from inventive event to invention flag.
Percentage captured before public release.
Number routed deliberately to patent, trade secret, open source, or archive.
Disclosure completeness.
Percentage with clear contributor and ownership records.
Number of emergency pre-launch reviews avoided.

Raw disclosure count is a poor incentive. It rewards volume rather than decision quality.

Frequently Asked Questions

Should we scan every commit?

Usually not with full human review. Automated tools can monitor changes continuously, while human triage focuses on high-signal pull requests, architecture changes, incident fixes, and strategic subsystems.

Is custom code automatically inventive?

No. Custom code may implement a routine approach. The useful signal is a distinct technical mechanism created in response to a real limitation.

Should engineers search patents before submitting a disclosure?

Engineers should record products, papers, libraries, and patents they already know. A preliminary landscape review can provide context, but it should not delay capture or substitute for counsel-directed search and legal analysis.

Can an AI coding agent be an inventor?

No. Only natural persons can be named as inventors in U.S. patent applications. The ordinary conception standard applies even when AI tools were used. Preserve the human decisions around problem identification, architecture, selection, modification, and testing.

What if the concept is better kept secret?

That is a routing decision. A complete technical disclosure supports patent, trade-secret, open-source, defensive-publication, and no-action decisions. Capture first; route deliberately.

Related Resources

[Can Software Be Patented?](/can-software-be-patented)
[Invention Disclosure Procedure](/invention-disclosure-procedure)
[Idea Disclosure Template](/idea-disclosure-template)
[GitHub Concept Scanner](/github-concept-scanner)
[Patent vs. Trade Secret for Software Algorithms](/patent-vs-trade-secret-software)

Sources

Disclaimer. This page is educational and provides an engineering discovery framework, not legal advice or a patentability determination. A qualified patent practitioner should evaluate the actual facts, prior art, claims, inventorship, ownership, and filing strategy.