NDA Clause Extraction: Catching Carve-Outs That Gut It

Read an NDA clause by clause and every individual sentence can look reasonable, standard, even protective, while the document as a whole leaves the receiving party almost completely free to reuse what it learned. That is not a hypothetical. It is the ordinary effect of two clauses that show up constantly, separately, in negotiated confidentiality agreements: a residuals clause that lets the receiving party's personnel keep and use anything retained in "unaided memory," and a carve-out excluding information that was "independently developed" from the confidentiality obligation entirely. Neither clause is unusual. Neither is, by itself, obviously dangerous. Combined, they can leave a disclosing party with almost nothing enforceable, and a keyword-matching extraction tool that flags both clauses as "present, standard language" will never tell anyone that.

This matters for anyone building or buying contract abstraction tooling that processes NDAs at volume, vendor onboarding, M&A due diligence, fintech partnership evaluations, loan servicing agreements that bundle in confidentiality terms. The failure mode isn't missing a clause. It's finding every clause, tagging each one correctly, and still missing the interaction between them that determines whether the agreement actually protects anything.

What NDA clause extraction actually has to identify

A working extraction pipeline for NDAs needs to classify and pull several distinct things out of a document that can run anywhere from two pages to twenty: the structural type of the agreement, mutual or one-way; the definition of confidential information and how broad or narrow it is; the standard carve-outs to that definition; the duration of the obligation; any residuals language; and the remedies available on breach. Each of these is its own extraction sub-problem, and most vendor pages describe them as a flat checklist, present or absent, without addressing how the items on that checklist interact with each other. That interaction is where the real risk lives, and it's also where automated review most commonly fails silently, because a clause-presence checklist has no way to represent "clause A neutralizes clause B."

Mutual versus one-way: the structural difference that keyword matching gets wrong

The surface-level distinction between a mutual and a one-way NDA is simple: in a mutual NDA both signatories can be a disclosing party and a receiving party, and in a one-way NDA only one party discloses while the other receives. Detecting which type an NDA is sounds like it should be trivial, check the title, check whether the document defines both a "Disclosing Party" and "Receiving Party" role for each signatory. In practice this is exactly the kind of detection that breaks on real contracts, because the title and the operative language frequently disagree with each other.

The most common failure pattern is a mutual NDA template, title says "Mutual Non-Disclosure Agreement," cover page lists both parties symmetrically, where the confidentiality obligations clause was drafted or edited to bind only one party in practice. This happens when a party starts from a mutual template because it looks more balanced or standard, then negotiates in one-directional restrictions into the obligations section without updating the definitions or the document type. An extraction system that classifies mutual versus one-way based on the document title, or even based on whether both roles are defined in the recitals, will misclassify this contract as symmetrical protection when the actual operative obligations in the confidentiality covenant section bind only the receiving party. The only way to catch this reliably is to check where the restriction language actually attaches grammatically, does the confidentiality covenant say "each party shall" or does it say "Receiving Party shall," and then cross-reference that against whether both parties are ever assigned the Receiving Party role anywhere in the operative sections, not just the definitions block.

Structural marker	True mutual NDA	One-way NDA with mutual-style title
Recitals define both roles	Yes, both parties assigned Disclosing and Receiving Party roles	Often yes, even though only one party ever discloses in practice
Confidentiality covenant subject	"Each party" or "the Receiving Party," where Receiving Party has been defined to include both signatories interchangeably	"Receiving Party" tied to a single named party, even inside a document titled mutual
Carve-outs apply to	Both parties' disclosures symmetrically	Only the disclosures of the party actually treated as discloser in the operative text
Residuals clause, if present	Should be mutual if information genuinely flows both directions	Frequently one-sided even in a mutual-titled document, granting residuals rights to only one side
What a title-only classifier reports	Correctly flags as mutual	Incorrectly flags as mutual, missing the asymmetric obligations buried in the covenant section

The practical consequence of getting this wrong in a lending or fintech context is straightforward: a partnership or vendor NDA gets classified as offering the disclosing party's business reciprocal protection because the document is titled and structured to look mutual, when the actual restrictive covenant only ever binds one side. Nobody downstream questions it because the extraction tool reported "mutual, standard" and moved on.

The residuals clause: what it actually permits and why it's controversial

A residuals clause carves out from the confidentiality obligation anything "retained in the unaided memory" of the receiving party's personnel after exposure to confidential information, typically framed around general ideas, concepts, know-how, and techniques rather than specific documented material. The rationale drafters give is practical rather than legal: employees who review a disclosing party's confidential material cannot selectively erase what they absorbed, so a residuals clause acknowledges that reality instead of pretending an NDA can enforce something biologically implausible.

That justification is reasonable as far as it goes, and it's also exactly why residuals clauses are considered one of the most consequential provisions to miss in NDA review. A narrowly drafted residuals clause limits itself to genuinely general knowledge, excludes anything intentionally memorized, and explicitly states that it does not affect confidentiality obligations for tangible or documented confidential information. A broadly drafted residuals clause extends the same "unaided memory" language to cover use for competitive purposes without those limits, which functionally lets the receiving party's team walk away from a diligence process or a technical evaluation and build a directly competing product, so long as they can characterize what they used as "retained in memory" rather than "copied from a document."

The clause is also structurally asymmetric in a way that's easy to miss on a read-through. A party negotiating hard for residuals rights while refusing to grant them mutually is a specific, identifiable red flag, one side wants the freedom to walk away with retained knowledge while insisting the other side cannot. In a mutual NDA where information genuinely flows in both directions, an unbalanced residuals clause that grants that freedom to only one signatory is inconsistent with the document's own stated mutuality, the same structural mismatch problem described above showing up inside a single clause rather than across the whole agreement.

The independently developed information carve-out

Separately from residuals, essentially every negotiated NDA excludes from its definition of confidential information anything that: was already in the public domain, was already known to the receiving party before disclosure, was rightfully received from a third party without restriction, or was independently developed by the receiving party without reference to or use of the disclosed information. These four exclusions are close to universal, and their absence from an NDA is itself a signal worth flagging, a document that asks a receiving party to treat information that's already public, or that it already independently knew, as if it were newly disclosed and secret is asking for something courts are generally reluctant to enforce anyway.

The independent development carve-out specifically creates a proof problem that has nothing to do with how well it's drafted. If a receiving party is later accused of misusing confidential information, the carve-out lets it claim the information in question was arrived at independently, without reference to the disclosure, and the disclosing party then has to prove a negative: that no independent, clean development path existed. That is a genuinely hard thing to prove, particularly for a receiving party that operates in the same space as the discloser and has engineers who plausibly could have arrived at similar solutions on their own. This isn't a drafting flaw in any individual NDA, it's an inherent feature of how the independent development carve-out functions, and it's precisely why pairing it with a residuals clause compounds the problem rather than merely adding to it.

Worked example: how the two carve-outs stack to gut protection

Consider an NDA between a lending platform evaluating a document-processing vendor's OCR technology during a technical diligence call, a common scenario in fintech partnership evaluations. The NDA is titled mutual, defines confidential information broadly to include technical specifications, model architecture, and pricing, and includes both a standard independent development carve-out and a residuals clause. Read individually, all four elements look fine.

Clause	What it says	What it permits in combination
Confidentiality definition	Covers technical specifications, model architecture, pricing, and business plans disclosed during diligence	Establishes broad protection on paper
Independent development carve-out	Excludes information the receiving party can show it developed without reference to the disclosure	Receiving party's engineers, who now know what "good" looks like after the demo, can build a similar system and characterize it as independently developed
Residuals clause	Permits use of ideas, concepts, and techniques retained in unaided memory, not limited to tangible documents	Even design choices and architectural approaches discussed verbally in the diligence call, never reduced to a document, are freely reusable
Combined effect	Neither clause alone eliminates protection	Together, the receiving party's engineers can absorb the approach shown in diligence, wait a reasonable interval, build something functionally similar, and defend it as both independently developed and residuals-permitted, with the disclosing party carrying the burden of proving otherwise on both fronts simultaneously

The disclosing party in this scenario is not protected by the fact that its confidentiality definition was broad. It's not protected by the fact that pricing and architecture were explicitly named as confidential. Both carve-outs sit underneath that definition and each independently narrows what's actually enforceable, and because they overlap in what they exclude, general approaches and techniques not tied to a specific document, they don't just subtract from protection twice, they create a combined defense where the receiving party can invoke whichever carve-out fits better for a given piece of information. A clause extraction tool that reports "confidentiality definition: broad, includes technical specs" without separately flagging that a residuals clause and an independent development carve-out both apply to that same category of information is reporting a false sense of protection.

What a real court did with a residuals clause: Space Data Corp. v. Google

The interaction between a residuals clause and a misappropriation claim isn't just a theoretical concern, it played out in federal litigation. In Space Data Corp. v. Alphabet Inc. and Google LLC, No. 5:16-cv-03260, filed in the U.S. District Court for the Northern District of California, Space Data alleged that Google misused confidential information shared under an NDA that included a residuals clause while evaluating Space Data's high-altitude balloon technology, technology that Google's Project Loon later pursued independently. The court's ruling on Google's motion to dismiss turned in part on the residuals clause: the court found that Space Data's complaint did not sufficiently plead how Google's alleged conduct fell outside the scope of what the residuals provision permitted, or how Google's use went beyond what the clause's carve-out for retained, unaided knowledge allowed.

The practical lesson from that ruling for anyone building NDA extraction tooling is specific: a residuals clause doesn't just create a substantive defense, it raises the disclosing party's pleading burden at the earliest stage of litigation, before discovery, before any evidence exchange. A plaintiff has to affirmatively plead facts showing the defendant's conduct falls outside the residuals carve-out, which is a materially harder bar to clear than pleading ordinary misappropriation. Extraction tooling that flags "residuals clause present" as a mid-severity item, on par with a duration term or a governing law clause, is understating what the clause actually does to a disclosing party's legal position if the relationship goes wrong.

What a clause extraction system needs to check to catch this, technically

Detecting the individual clauses, residuals language, independent development carve-out, mutual versus one-way structure, is the easier half of the problem and is achievable with clause-type classification trained on labeled NDA paragraphs, similar to how contract clause classifiers are trained and benchmarked across other clause categories in commercial agreements more broadly. The harder half is flagging the interactions. A system built to actually surface risk, rather than just presence, needs to do at least three additional things beyond per-clause classification.

First, it needs to check grammatical binding, whether the operative confidentiality covenant subject is "each party," "both parties," or a single named Receiving Party, cross-referenced against the roles assigned in the recitals, to catch the mutual-titled-but-one-way-bound pattern described above. Second, it needs to check whether a residuals clause and an independent development carve-out apply to overlapping categories of information, both typically covering general approaches, techniques, and concepts rather than fixed documents, and flag that overlap as a combined-risk item rather than reporting each clause separately with no relationship between them. Third, for a residuals clause specifically, it needs to distinguish the narrow version, no intentional memorization, explicit carve-back for tangible confidential information, from the broad version that extends to competitive use without those limits, since those two versions produce meaningfully different legal exposure despite using overlapping vocabulary and often appearing under the identical clause heading.

None of this argues for eliminating residuals clauses or independent development carve-outs from NDA review, both serve legitimate, well established purposes and neither is inherently a red flag on its own. It's a reason to treat "clause present, standard language" as an incomplete answer to the actual question a lending or fintech risk team is asking, which is whether the NDA in front of them will actually protect the specific information they're about to disclose if the counterparty relationship sours. Related coverage of how automated systems classify and extract contract clauses more broadly is available in our piece on document intelligence for legal documents, and a deeper look at how automated tools handle another commonly-missed clause category, force majeure and indemnification language, is worth reading alongside this one, as is our piece on governing law clause extraction, for anyone evaluating NDA extraction tooling against a broader confidentiality and risk-allocation clause set. Written by Nupura Ughade.