Extracting Confidentiality Obligations From an NDA

Whether an NDA binds one party or both is the first field, it decides the shape of every other field, and it cannot be read off the title. Plenty of documents headed “Mutual Non-Disclosure Agreement” impose obligations in one direction only, because somebody edited a template and left the heading alone.

Mutual or one-way, decided structurally

The reliable signal is how the operative sentence names its subject. Three patterns cover nearly everything:

• Role-based and symmetric. “Disclosing Party” and “Receiving Party” are defined as roles that either party may occupy — usually with an explicit sentence saying so — and the obligations attach to “Receiving Party”. Mutual.
• Party-named. “Recipient shall hold in confidence all Confidential Information disclosed by Company”, where Company is one named entity. One-way, whatever the heading says.
• Role-based but asymmetric. The definitions are reciprocal but one substantive obligation names a party directly, or a schedule describes only one party’s information. This is the case worth flagging for review, because it is the one produced by editing a mutual template.

Encode it as directionality with values mutual, one_way and mixed, plus the section number the determination came from. Then store obligations as a list keyed by obligated party rather than as document-level fields. A mutual NDA with genuinely different obligations in each direction — different survival periods are common — is representable that way and is not representable in a flat schema.

One structural giveaway is worth checking mechanically: count the occurrences of each party’s defined name inside the obligation sections only. In a genuinely mutual agreement the operative sections use roles and mention neither party by name. A single named mention inside an obligation is where asymmetry usually hides.

What counts as confidential

The definition of Confidential Information is the field that decides the breadth of everything else, and definitions fall into two families that behave very differently.

An inclusive definition covers all information disclosed in connection with the stated purpose, usually with a non-exhaustive list of categories. A marking-based definition covers only information marked or identified as confidential. The second is narrower by an enormous margin, and the difference is a boolean field — marking_required — that is far more useful downstream than the definition text itself.

Store also the permitted_purpose, which is a separate defined term and is the limit on what the recipient may do with the information at all. “Solely for the purpose of evaluating a potential business relationship between the parties” is a real restriction and it is not part of the confidentiality obligation; it is a use restriction sitting next to it. And store permitted_recipients: employees only, or employees and affiliates, or advisers on a need-to-know basis, each usually with a flow-down requirement that those recipients be bound by equivalent terms.

The marking requirement and its clock

Where marking is required, oral disclosures need a follow-up mechanism, and that mechanism carries a deadline that most extractions miss entirely:

"Information disclosed orally or visually shall be
 Confidential Information only if identified as
 confidential at the time of disclosure and reduced
 to writing and delivered to the Receiving Party
 within thirty (30) days thereafter."

marking_required           true
oral_disclosure_covered    conditional
oral_followup_days         30
oral_followup_anchor       date_of_disclosure

This is a per-disclosure obligation with a per-disclosure clock, which means it cannot be represented as a document-level date any more than a per-disclosure survival period can — the same modelling problem appears in extracting the term and survival period. What the extraction can do is capture the rule and the window so that a disclosure log can be checked against it.

The failure mode here is quiet: a model asked for “confidentiality obligations” summarises the marking sentence into “oral disclosures are covered”, which drops both conditions and inverts the outcome for any oral disclosure that was never confirmed in writing.

Carve-outs are not permissions

Every NDA has two things that both look like exceptions and are not the same kind of thing at all. Merging them into one exceptions array is the single most common semantic error on these documents.

The definitional carve-outs remove information from protection permanently. The standard set is information that was already public; that becomes public other than through the recipient’s breach; that the recipient already knew without a duty of confidence; that the recipient independently developed without use of the disclosed information; and that the recipient received from a third party free of any duty. Once information falls into one of these, it is not Confidential Information and no obligation applies to it.

The compelled-disclosure proviso does something entirely different. It permits one act — disclosure required by law, subpoena or court order — while leaving the information confidential for every other purpose, and it usually attaches conditions: prompt notice to the disclosing party where legally permitted, cooperation in seeking protective treatment, and disclosure limited to the portion legally required.

carve_outs: [
  "already_public", "becomes_public_no_breach",
  "prior_knowledge", "independent_development",
  "third_party_no_duty"
]
permitted_disclosures: [
  { trigger: "legal_compulsion",
    notice_required: true,
    notice_timing: "prompt, where legally permitted",
    scope_limit: "portion legally required" }
]

Two arrays rather than one flattened list — the choice nested versus flat extraction schemas is about — because one says “this is not protected” and the other says “this is protected but you may do this one thing”. A downstream question like “may we share this document with our auditor” gets opposite answers depending on which array the auditor exception ended up in.

Check the carve-out list for what is missing rather than what is present. The five above are close to universal; an NDA lacking the independent-development carve-out, or lacking the prior-knowledge one, is unusual and its absence is the finding. That makes the field a good candidate for a completeness check rather than a confidence score, and the shape of that check is the one in handling a missing required field.

Return, destroy, and the backup exception

The return-or-destroy obligation has four sub-fields worth separating: whether return or destruction is at the recipient’s election or the discloser’s; the trigger, which is usually written request or termination or both; whether a written certification of destruction is required and by whom it must be signed; and the exception for copies retained in routine backups or required by law or professional rules.

That last one is the operationally significant field and the one most often summarised away. “Provided that Receiving Party may retain copies stored in automatic archival systems, which shall remain subject to the confidentiality obligations herein” means the obligation outlives the destruction event for that subset of copies. If your schema has a single obligations_end date, this sentence contradicts it.

The clause that undoes the rest

A residuals clause permits the receiving party’s personnel to use general knowledge, skills and ideas retained in unaided memory. It is not present in most NDAs, it is heavily negotiated where it is present, and it materially narrows every obligation above. It is also easy to miss because it sits at the end of a long section and reads like boilerplate.

Treat it as a top-level boolean with the clause text attached, and treat its presence as a review trigger regardless of confidence — a rule that routes on the value rather than on a score, which threshold-based review routing has to accommodate. Extraction that is right ninety-nine times out of a hundred is fine for a payment term and not fine for a clause whose presence changes the answer to the question the whole document exists to settle.