Extracting Indemnification Language From a Contract

Every material fact about an indemnity is somewhere other than the indemnity clause. The parties are defined terms from the definitions section, the cap is in the limitation of liability clause, and the carve-out that removes the cap is in the same distant place. Extract the clause alone and you have quoted a paragraph, not answered a question.

Indemnify, defend, hold harmless

The conventional triplet is three obligations printed as one phrase, and the middle one behaves differently from the others in a way that matters for the schema. Indemnifying is reimbursement after the fact. Defending is an obligation that starts when a claim is asserted, before anyone knows whether it has merit, and is the reason the clause has procedural machinery attached to it.

So model the scope as three booleans rather than as a single hasIndemnity flag. A clause that says indemnify and hold harmless without saying defend is a different clause from one that includes defence, the difference is one word, and a summarising extraction will render both as “the supplier indemnifies the customer”.

The duty to defend brings its own sub-fields, and their presence or absence is the point of extracting them:

• Notice condition. Prompt written notice of the claim, sometimes with a stated period, sometimes qualified so that late notice only reduces the obligation to the extent of prejudice. The qualifier is a separate field.
• Control of the defence. Which party selects counsel and conducts the matter, and whether the other may participate at its own expense.
• Settlement consent. Whether the indemnifying party may settle without consent, and the standard for withholding it.
• Cooperation. An obligation on the indemnified party that is a condition of the indemnity.

Who the indemnified party actually is

Two problems, and both defeat named-entity extraction.

First, the clause usually does not name the parties. It says the Indemnifying Party and the Indemnified Party, or Supplier and Customer, all of which are defined terms established in the preamble or the definitions section. Resolving them requires the definitions, which are twenty pages away, and the defined term may itself be defined in terms of another. An extraction pipeline that treats each clause as an independent document cannot resolve them at all — you need a per-contract term dictionary built in a first pass and supplied to every clause-level call after it.

Second, the indemnified party is nearly always broader than a party to the contract. The typical formulation extends to a party and its affiliates, officers, directors, employees, agents, successors and permitted assigns, and the extension is doing real work. Extract it as a list of categories, not as prose, because the question people bring to this field is whether a particular kind of person is inside it.

The triggering events are a third list and they are enumerated in the same run-on sentence: third-party claims arising out of or relating to a stated set of causes — infringement, breach of confidentiality, negligence or wilful misconduct, breach of the agreement, violation of law, employment claims. Each of those is an item, they are separated by semicolons inside a single sentence four hundred words long, and any chunking strategy that splits on sentence boundaries yields one chunk containing everything. Split on the semicolon-and-enumerator structure or extract the list explicitly by schema; the general treatment of splitting long structured text is in reconstructing document structure.

Mutual, one-sided, or mutual in name only

Whether an indemnity runs both ways is a question about the whole set of indemnity provisions, not about one sentence, and it is answered by checking whether each party appears as indemnitor somewhere.

The textual patterns are distinct. Genuinely mutual clauses open with each party shall indemnify the other, and the trigger list is shared. One-sided clauses name an indemnitor: Supplier shall indemnify Customer. The interesting third case is the one drafted to look mutual: two subsections, one per party, with visibly different trigger lists — one party indemnifying for a broad set of causes and the other for a narrow one. Reported as “mutual”, that is technically true and substantively misleading.

So do not emit a mutual boolean as a primary output. Emit the array of obligations, each with its indemnitor, its indemnitee list and its trigger list, and derive mutuality if a consumer wants it, with the trigger counts alongside. A derived field with its inputs visible can be argued with; a stored boolean cannot.

The cap is in a different clause

This is the structural fact that makes indemnity extraction a multi-clause problem. The limitation of liability clause typically caps each party’s aggregate liability at some figure — fees paid in a preceding period, a multiple of them, a fixed sum — and excludes categories of damages such as consequential, indirect and lost profits. Then it carves out exceptions: notwithstanding the foregoing, the limitations shall not apply to a listed set, which very often includes the indemnity obligations.

The result is that whether an indemnity is capped is stated in a clause the indemnity does not reference, and the carve-out is one sentence in a section otherwise about something else. An extraction scoped to the section headed “Indemnification” will correctly report every word of the obligation and cannot say whether it is capped, which is the first thing anybody wants to know.

Build the join deliberately. Extract the limitation of liability clause as its own object with a cap expression, a damages exclusion list and a carve-out list, then match carve-out items back to the indemnity obligations by trigger category. Where the match is ambiguous — a carve-out referring to “Section 9” when your obligations came from sections 9.1 and 9.3 — record the reference unresolved rather than guessing. The unresolved reference is more useful than a wrong resolution, for the same reason an endorsement listed but not found is more useful than a silently incomplete exclusion list.

What a complete extraction contains

Per obligation: indemnitor, indemnitee categories, scope as three booleans, trigger list, notice condition with its prejudice qualifier, defence control, settlement consent standard, and the source section. Per contract: the cap expression, the damages exclusions, the carve-out list with resolution status, and whether the indemnity is stated to be an exclusive remedy — a single sentence that changes what the rest of it is worth and which sits, of course, in yet another place.

Two operational notes. Indemnity and warranty-disclaimer text is frequently set in capitals for conspicuousness, which breaks case-sensitive matching, defeats sentence segmenters that rely on capitalisation, and degrades OCR on a scanned copy; normalise case for matching but keep the original, because the capitalisation is itself a signal that you are in the right region of the document.

And record the absence. A commercial agreement with no indemnity at all is not a failed extraction, it is a finding, and it is a common one on short-form and click-through agreements. A pipeline that emits an empty array with an explicit “no indemnity provision located” finding says something true; one that emits nothing says nothing, and downstream nobody can tell it apart from a document that failed to parse.