Extracting the Term and Survival Period From an NDA

“When does this NDA expire?” has two answers and they are usually years apart. One is when the agreement stops covering new disclosures. The other is when the duty of confidence over information already disclosed finally lapses. A schema with one expiry column will store whichever number the model saw first.

Two durations, two questions

The term of the agreement answers: if I send you something next Tuesday, is it covered? The survival period answers: the thing I sent you last year — how long must you keep it quiet?

These are independent numbers and are often deliberately different. A two-year term with a five-year survival is an ordinary drafting choice: the parties expect the evaluation to finish quickly and the secrets to matter for longer. Extracted into one field, the two-year figure is usually the one that wins because it appears earlier in the document and under a heading that says “Term”.

The minimum honest schema is four fields plus a derived one:

term_length          e.g. 2 years
term_anchor          effective_date | signature | event
survival_length      e.g. 5 years
survival_anchor      effective_date | termination | each_disclosure
last_obligation_date derived, nullable

survival_anchor is the field doing the work, and it takes three values because there are three ways drafters write the clause.

Three survival architectures

• From termination or expiration. “The obligations set forth in Section 3 shall survive for five (5) years following the expiration or termination of this Agreement.” One clock for the whole document. Computable from the term alone.
• From each disclosure. “shall survive for five (5) years from the date of disclosure of the applicable Confidential Information.” One clock per item disclosed. The document does not contain enough information to produce a date.
• Tiered, with a trade-secret carve-out. “shall survive for five (5) years, provided that with respect to any information constituting a trade secret under applicable law, the obligations shall continue for so long as such information remains a trade secret.” Two durations, one of which is open-ended and conditional on a fact that changes over time.

The third is the one that breaks date columns, because there is no date. Storing a far-future placeholder makes the row sortable and makes it lie; the correct representation is a separate trade_secret_tier flag with a null end and a reason, exactly the nullable-with-reason pattern that schema edge cases argues for generally.

The same NDA, three last dates

Take a synthetic agreement with an Effective Date of 1 May 2024, a two-year term, and a five-year survival, and vary only the anchor:

Effective Date              2024-05-01
Term                        2 years  -> ends 2026-05-01
Survival                    5 years

A) anchor = termination/expiration
   last obligation ends     2031-05-01

B) anchor = each disclosure
   last disclosure could occur on the final day of
   the term, 2026-05-01
   -> that item is protected until 2031-05-01
   -> an item disclosed 2024-06-10 lapses 2029-06-10
   -> no single document-level date exists

C) tiered
   non-trade-secret material   2031-05-01
   trade secrets               null (condition, not date)

Reading A and reading B produce the same latest possible date and completely different data. Under A, every item lapses on one day and a retention policy can act on it. Under B, the pipeline needs a disclosure log, and the useful extracted output is the rule — five years, anchored on disclosure — not a date. A system that reports 2031-05-01 for case B is right about the worst case and wrong about every individual document, which is precisely backwards for a retention decision, where deleting early is the risk.

Note also the same day-before-anniversary ambiguity that afflicts renewal windows: whether a two-year term running from 1 May 2024 ends on 30 April or 1 May 2026 depends on the drafting, and it propagates into the survival date under anchor A. It is a single day, and it is a day on which somebody may destroy a document. Carry the term-end phrasing through rather than resolving it silently; the arithmetic is worked in extracting auto-renewal terms.

Early termination does not shorten survival

Most NDAs let either party end the agreement early, and the clause usually reads “either party may terminate this Agreement upon thirty (30) days’ prior written notice, provided that the obligations of Section 3 shall survive such termination in accordance with Section 6”.

Under survival anchor A, that sentence moves the survival end date earlier, because the clock hangs off termination and termination just happened sooner. Under anchor B it changes nothing at all, because each item’s clock started when it was disclosed. The same termination event has opposite effects on the answer depending on a field two sections away, which is why survival_anchor has to be extracted as a value rather than assumed.

Two further distinctions belong in the record. Termination for convenience — the notice-period form above — and termination for cause are frequently both present with different notice periods, and some drafts hang the survival clock only off the first. And “expiration” and “termination” are not synonyms: a survival clause naming only termination, on an agreement that expires by its own terms, is a genuine ambiguity worth flagging rather than resolving. The general mechanics of termination clauses are in extracting termination clauses.

When the answer is null

Four situations produce a legitimately null last-obligation date, and a pipeline should be able to say which one it is rather than emitting a guess:

• Per-disclosure anchoring, where the date depends on a log the contract does not contain.
• Trade-secret or perpetual tiers, where the end is a condition rather than a date.
• An event-anchored term, where the agreement runs from a closing or a service start that has not happened.
• No survival clause at all. This is the one that should never be silently coerced to “same as the term”. An NDA with no express survival provision raises a question about what happens at expiry, and that question goes to a lawyer, not to a default value.

The pattern across all four is the same. A date field on a contract extraction should be accompanied by a basis field explaining where the date came from, and null should be a first-class value with a reason code — the discipline set out in handling a missing required field. A retention system built on dates with no provenance will eventually delete something it should have kept, and nobody will be able to reconstruct why — which is the argument for keeping the derivation in an an audit trail alongside the extracted value.