Functional Software Descriptions Are Not “Concrete Secrets” Under the DTSA; Late-Stage “Other Proprietary Information” Theories May Be Excluded

Introduction

NEXT Payment Solutions, Inc. v. CLEAResult Consulting, Inc. (7th Cir. Jan. 13, 2026) addresses two recurring litigation pressure points in software disputes: (1) how specifically a plaintiff must identify an alleged software trade secret to survive summary judgment under the Defend Trade Secrets Act (“DTSA”), and (2) how strictly courts may police attempts to pivot to new liability theories shortly before trial under the rubric of unjust enrichment.

NEXT, a developer of customer service software, built a customized appointment scheduling application—the “FAST Tool”—for CLEAResult, a provider of energy-efficiency programs. After several years, CLEAResult transitioned to a different platform (DSMTracker). NEXT alleged that, during “Project Renaissance,” CLEAResult compared DSMTracker to the FAST Tool’s internal-facing features and used what it learned to refine DSMTracker before terminating NEXT.

The key issues on appeal were:

DTSA trade secrets: whether NEXT identified “concrete secrets” with sufficient specificity (as opposed to broad functional descriptions) to allow a jury to decide whether the information was “not generally known” and “not readily ascertainable.”
Unjust enrichment: whether NEXT could proceed to trial on a newly emphasized theory that CLEAResult misused “other proprietary information” distinct from trade secrets, after the trade secret claim had been dismissed.

Summary of the Opinion

The Seventh Circuit affirmed across the board.

DTSA: Summary judgment for CLEAResult was proper because NEXT’s purported trade secrets—identified as dozens of “modules” and “combinations”— were described only by what the software does (functions and outcomes), not how it does it (e.g., specific algorithms, source code, methodologies, or architecture in a way that is not readily ascertainable). This left the factfinder unable to distinguish protectable secret information from what any user could observe.
Unjust enrichment: The district court did not abuse its discretion by excluding, via motion in limine, a late-breaking unjust enrichment theory premised on “other proprietary information.” The theory was not meaningfully pleaded or pursued until the eve of trial and would prejudice CLEAResult and delay proceedings.

Analysis

Precedents Cited

1) Specificity and “concrete secrets” in trade secret pleading/proof

REXA, Inc. v. Chester, 42 F.4th 652 (7th Cir. 2022): The court relied on REXA for the proposition that trade secret claims demand a “high level of specificity” and require “concrete secrets” rather than “broad areas of technology.” This case is applied as a strict gatekeeping rule at summary judgment: if the description is too general, the claim fails before a jury ever assesses misappropriation.
Life Spine, Inc. v. Aegis Spine, Inc., 8 F.4th 531 (7th Cir. 2021): Quoted through REXA for the “concrete secrets” framing and cited for the DTSA’s definitional elements (reasonable secrecy measures; independent economic value from not being generally known/readily ascertainable). Life Spine functions here as doctrinal scaffolding: the plaintiff’s identification burden is tied to the statutory requirement that the information be genuinely “secret.”
IDX Sys. Corp. v. Epic Sys. Corp., 285 F.3d 581 (7th Cir. 2002): The central comparator. IDX rejects “identify a kind of technology and invite the court to hunt through the details” and warns that what “any user or passer-by sees at a glance” is “exceedingly hard to call trade secrets.” The panel used IDX to characterize NEXT’s module list as function-focused “technical verbiage” that failed to separate alleged secrets from ordinary software features.
Composite Marine Propellers, Inc v. Van Der Woude, 962 F.2d 1263 (7th Cir. 1992): Cited via IDX to reinforce that courts will not sift through broad, undifferentiated descriptions in search of protectable material; the plaintiff must do the isolating.
BondPro Corp. v. Siemens Power Generation, Inc., 463 F.3d 702 (7th Cir. 2006): Supports the idea that processes described only “in general terms” are “usually widely known” and thus not trade secrets. BondPro supplies a practical inference: the more generic the description, the less plausible secrecy becomes.
Learning Curve Toys, Inc. v. PlayWood Toys, Inc., 342 F.3d 714 (7th Cir. 2003): Cited for the classic three-element misappropriation framework (trade secret, misappropriation, use). Although the dispute turned on element (1), Learning Curve anchors the analysis in the familiar structure.

2) Software-specific authorities: “what it does” vs. “how it works”

Silvaco Data Sys. v. Intel Corp., 184 Cal. App. 4th 210 (Cal. App. Ct. 2010): Used to emphasize that the “finished (compiled) product” and observable behavior are not trade secrets if “evident to anyone running the finished program.” The Seventh Circuit used Silvaco as persuasive authority consistent with its own IDX line: visible functionality is, by definition, readily ascertainable to a user.
(The opinion notes Silvaco was “disapproved of on other grounds by Kwikset Corp. v. Superior Ct., 51 Cal. 4th 310 (Cal. 2011),” but the relied-upon point about compiled output and observability remains conceptually aligned with Seventh Circuit doctrine.)
Fin. Info. Techs., LLC v. iControl Sys., USA, LLC, 21 F.4th 1267 (11th Cir. 2021): Cited for the general proposition that software source code is often not readily ascertainable and can qualify for trade secret protection—highlighting the contrast with NEXT’s failure to identify code, algorithms, or comparable “how.”
Syntel Sterling Best Shores Mauritius Ltd. v. TriZetto Grp., Inc., 68 F.4th 792 (2d Cir. 2023): Offered as an example where specificity was adequate because the plaintiff identified underlying source code and architecture behind the claimed secrets. The reference underscores what “good” identification looks like in software cases.
Integrated Cash Mgmt. Servs., Inc. v. Digital Transactions, Inc., 920 F.2d 171 (2d Cir. 1990): Cited to clarify the court’s limit: while code/algorithms are often the most direct proof, a plaintiff might sometimes prove a protectable secret through other evidence (e.g., expert testimony that an architecture/combination could not be readily duplicated without years of research). The Seventh Circuit cited this to avoid creating an absolute “must produce source code” rule—while holding NEXT’s proof still failed.

3) DTSA/UTSA overlap

Mickey's Linen v. Fischer, No. 17 C 2154, 2017 WL 3970593 (N.D. Ill. Sept. 8, 2017): Cited for the proposition that DTSA analysis may borrow from state-law decisions applying Uniform Trade Secrets Act analogues because of substantial overlap. This matters because the opinion comfortably draws from Illinois, Seventh Circuit, and persuasive out-of-circuit authorities.

4) Late theories and trial management (unjust enrichment)

United States v. Wade, 962 F.3d 1004 (7th Cir. 2020): Sets the standard of review for motions in limine (legal conclusions de novo; ultimate decision for abuse of discretion).
Crest Hill Land Dev., LLC v. City of Joliet, 396 F.3d 801 (7th Cir. 2005) (citing Fort Howard Paper Co. v. Standard Havens, Inc., 901 F.2d 1373 (7th Cir. 1990)): Supports the court’s broad discretion to reject “surprises” (new arguments/defenses) after discovery and summary judgment.
Bethany Pharmacal Co. v. QVC, Inc., 241 F.3d 854 (7th Cir. 2001): Reinforces that district courts are not required to tolerate additional delay needed to respond to a new theory of liability.
Soltys v. Costello, 520 F.3d 737 (7th Cir. 2008): Adds systemic considerations—eleventh-hour additions burden not only the parties but also the courts and other litigants.
Scott v. City of Chicago, 195 F.3d 950 (7th Cir. 1999): Used for pleading notice principles: whether a complaint provides notice is assessed by looking at the complaint “as a whole,” which undercut NEXT’s attempt to parse isolated “proprietary information” phrasing into a distinct, preserved theory.

Legal Reasoning

A. The “identify the secret” burden in software trade secret cases

The opinion’s core move is to treat specificity not as a formal pleading nicety but as a functional prerequisite to applying the DTSA definition. The statute protects information only if it is secret in the relevant sense—not generally known and not readily ascertainable. Without a sufficiently particular description, a court (and later a jury) cannot tell whether the plaintiff is claiming: (i) protectable internal methods, or (ii) the mere existence of common software features.

NEXT’s “module” spreadsheet exemplified the failure: each module was described by user-facing outcomes (manage inventory, display availability, send notifications, generate PDFs). The panel held that describing outputs and functional goals “in circular terms” is not identifying a trade secret. The trade secret (if any) would be the non-obvious method— such as the “specific algorithms, source code, or methodologies”—and NEXT did not identify those.

The court also emphasized an observability principle: if a feature is apparent to a user of the product—whether on a public-facing or internal-facing interface—then, absent more, it is “readily ascertainable” in the trade secret sense. NEXT’s argument that the internal-facing side was “non-public” did not cure the problem because the relevant audience for ascertainability included clients/users who legitimately access the software and can see what it does.

B. No categorical “source code production” rule—yet functional descriptions alone are insufficient here

The panel included an important limiting clarification (footnote 3): it did not hold that a software trade secret plaintiff must always produce source code or algorithms. It acknowledged other potential proof routes (e.g., evidence of non-readily-duplicable architecture, potentially supported by expert testimony). But the court held that NEXT offered none of that—only generic functional descriptions.

The court also found the evidentiary posture decisive: NEXT conceded CLEAResult did not access the processing engine or source code, leaving NEXT to argue that visible modules themselves were trade secrets. Under Seventh Circuit doctrine, visible functions are exactly the wrong level of abstraction.

C. “New and valuable” is not “secret”

NEXT argued its scheduling functions were “new and valuable” because tailored to utilities and real-time matching by geography and technician availability. The court treated this as beside the point: even if the product performs well or uniquely, performance characteristics and outputs that are “evident to anyone running the finished program” are not “secret.” Trade secret law is about secrecy and non-ascertainability, not merely novelty or business value.

D. Unjust enrichment: late-stage theory management through motions in limine

On unjust enrichment, the Seventh Circuit accepted the district court’s characterization that NEXT attempted an end-run around the DTSA loss by reframing the same factual narrative as “other proprietary information” misappropriation shortly before trial.

Two reasoning steps mattered:

Notice and consistency: Reading the complaint as a whole, “proprietary information” was not pleaded as a distinct category separate from trade secrets. The complaint repeatedly used the combined phrase “trade secrets and proprietary information,” without identifying any independent “other proprietary information.”
Case-management discretion: Even if a pleading could be stretched, NEXT had not pursued such a theory through discovery and summary judgment. Introducing it on the eve of trial would prejudice CLEAResult and likely require delay—precisely the kind of “surprise” disfavored by Crest Hill Land Dev., LLC v. City of Joliet, Fort Howard Paper Co. v. Standard Havens, Inc., Bethany Pharmacal Co. v. QVC, Inc., and Soltys v. Costello.

Impact

Sharper line between “features” and “secrets” in software cases: The decision reinforces a Seventh Circuit-friendly defense posture: lists of modules, screens, capabilities, or “what the software does” are unlikely to satisfy DTSA specificity requirements without identification of the non-obvious method (code/algorithms/architecture) or equivalent evidence that the “how” is not readily ascertainable.
Internal access is not automatic secrecy: The opinion rejects the notion that “non-public” (e.g., internal client portals) equals “not readily ascertainable.” If authorized users can observe the functionality, the plaintiff must still identify the concealed mechanism that constitutes the secret.
Strategic consequences for plaintiffs: Plaintiffs should expect early demands (often via trade secret identification orders) to pin down: (i) the precise secret, (ii) its boundaries, and (iii) why it is non-ascertainable. Failure to do so risks summary judgment even before misappropriation is litigated.
Trial-stage pivots face heightened skepticism: Using unjust enrichment as a “catch-all” after losing a trade secret theory will be constrained where the new theory was not clearly articulated, developed in discovery, and presented through summary judgment. Motions in limine can function as powerful tools to enforce that discipline.

Complex Concepts Simplified

“Trade secret” (DTSA): Not just valuable information—information that is kept secret with reasonable measures and has value because it is not generally known or readily ascertainable (18 U.S.C. § 1839(3)).
“Specificity” requirement: Courts require a plaintiff to identify the secret precisely enough to separate protectable material from commonplace knowledge. In software, “it schedules appointments” is a feature; a trade secret would be the non-obvious method enabling that feature (e.g., a particular algorithmic approach, data structure strategy, or architecture), described concretely.
“Readily ascertainable”: If an ordinary user or customer can learn the information simply by using or observing the product’s behavior, it often is not a trade secret. Trade secret law generally protects hidden know-how, not visible outputs.
Motion in limine: A pretrial motion to exclude evidence or arguments. Here it served to prevent an eleventh-hour shift to a new unjust enrichment theory.
Unjust enrichment (as litigated here): A claim that the defendant received an unfair benefit. The key procedural point is that the theory must be disclosed and pursued in time for the opposing party to conduct discovery and prepare defenses.

Conclusion

The Seventh Circuit’s decision stands for two practical rules. First, DTSA plaintiffs asserting software trade secrets must identify “concrete secrets”—not merely a catalog of functions, modules, or user-visible features—so a factfinder can evaluate secrecy and non-ascertainability. Second, plaintiffs cannot wait until the eve of trial to rebrand a failed trade secret narrative as misuse of “other proprietary information” under unjust enrichment; district courts may exclude such late theories to prevent prejudice and delay.