The extraction found the indemnity and got the direction wrong

The clause was found. The record says this agreement contains an indemnity, and that is true. It does not say who owes it, what sets it off, or who runs the defence when a claim lands, and those are the facts anyone opening the record needed. A missing field announces itself. A field reading "indemnity: present" looks like work that was done.

Direction fails first because English lets a drafter state an obligation without naming the person under it, and indemnity drafting does this constantly. Finding the clause is text matching, which models are good at. Attributing it means resolving "the Indemnifying Party" or a bare passive back to a name in the Parties clause — a parsing problem over language written for a lawyer with the definitions open, and it fails quietly.

Ask 10 contracts who owes whom, and mark every answer

Change nothing until you know which of the 4 answers is wrong. The sample has to be small enough to grade in an afternoon and structured so a disagreement points at a cause rather than at a feeling.

1. Pull 10 executed agreements spanning the paper you actually receive. Mix your own template with counterparty paper: failure rates differ enough that a sample drawn only from your template will look reassuring, which is the wider trap in reviewing on the other side's paper.
2. Write the 4 answers by hand before opening the stored record. Indemnifying Party, Indemnified Party, triggering events, and who controls defence and settlement. Reading the record first contaminates the grading, because a plausible wrong answer is hard to un-see.
3. Score the 4 fields separately rather than scoring the document. One right-or-wrong per contract hides the shape: direction can sit at 9 of 10 while trigger scope sits at 4 of 10, and those numbers demand different fixes.
4. Label each disagreement by cause. Party absent, party wrong, triggers truncated, defence mechanic missing, mutual read as one-way. 5 labels are enough for a first pass and they map onto the table below.
5. Count the mutual clauses separately. If only 2 of the 10 are mutual, the sample cannot tell you whether mutuality is handled — only that the extractor is right most of the time, which you already suspected.
6. Keep the 10 graded documents. They are the regression set for every later change, and rebuilding them in 3 months costs more than the afternoon did.

An indemnity is 5 facts, and "present" is not one of them

Fix what a correct record contains before diagnosing the extractor. Most systems failing this test were never asked for more than a boolean and a clause number, which makes the extraction compliant with a schema that was wrong before any code ran — the reason a taxonomy belongs in the clause list agreed before anyone builds the extractor.

• The Indemnifying Party, named. Not inferred from which side of the page the clause sits on, and not inherited from the party named in the surrounding article heading.
• The Indemnified Party, and everyone it reaches. Affiliates, officers, employees, agents and sometimes end customers appear in the beneficiary set, so a single counterparty name understates the obligation.
• The triggering events, in full. Third-party infringement, breach of confidentiality, personal injury, breach of a data-protection commitment: 4 separate triggers with 4 different likelihoods of ever firing.
• Control of the defence and the right to settle. Who appoints counsel, who may settle, and whether consent may be withheld. This is the operative mechanic and the field most often empty.
• Conditions and carve-backs. Notice periods, cooperation duties, and the "except to the extent caused by" sentence that trails the obligation and narrows it, often in the very next line.

5 ways an indemnity loses its owner

Match the rows against your graded labels rather than reasoning about likelihood. 2 of these produce a confidently populated field and are invisible unless somebody reads the source clause; the other 3 leave a hole you can query for.

Rows 2 and 3 are the expensive ones. Both produce a full-looking field with a plausible name in it, so no completeness check flags them and no reviewer scanning for blanks stops. They surface only when somebody relies on the record, in front of a counterparty.

The sub-clause that was cut away from the obligation it belongs to

An indemnity article is rarely 1 clause. The obligation is stated, notice is required, conduct of the defence is allocated, settlement consent is qualified — 4 units, each under its own number. A segmenter cutting on numbering hands the first to the indemnity extractor and drops the other 3 into the taxonomy's bucket for unclassified text. The extractor then correctly reports that the text it was given holds no defence mechanic.

That puts the defect upstream of the model, which is why prompt edits never move it. The cut is the decision that determines whether later analysis can be right at all: how a contract is cut into clauses before anything reads it. Executed paper is worse again, because appended schedules and spliced signature pages disturb the very numbering the segmenter keys on, the pathology set isolated in extraction that falls apart on the signed conformed copy.

Routing each label from the sample to its own repair

1. Party absent on both your paper and theirs. Passive drafting. Add a resolution step that reads the clause with the definitions and the Parties clause in scope, and a schema that permits an explicit unresolved value.
2. Party present and wrong, concentrated on mutual clauses. A records-per-clause problem, not a reading problem. One clause has to be allowed to produce 2 obligations before anything else helps.
3. Triggers short, direction right. Search the clause for a pointer to a Schedule, an Annex or a defined term. If one is there, retrieval never followed it, and resolving defined terms and where their meanings move is a prerequisite rather than an enhancement.
4. Defence control empty across most of the sample. Compare the stored span against the document. If the span ends before the sub-clause allocating conduct of the defence, it is segmentation, and re-prompting cannot reach it.
5. Correct on your template, wrong on theirs. The extractor learned your house conventions. Rebuild the sample so counterparty paper is the majority, then re-grade before changing anything.

A record saying an indemnity is present, without saying who owes it, has turned a document a lawyer could read into a database nobody can act on.

What a corrected indemnity record still leaves open

Getting direction, triggers and defence control right makes the record true. It does not make it a judgement, and it is not yet an artefact anyone can send. 4 things sit outside this repair.

• What the obligation is worth. Whether the indemnity sits inside or outside the limitation of liability is a separate reading, and the arithmetic belongs to the liability cap and the carve-outs that swallow it.
• Whether the clause is acceptable. A correct field still has to be judged against a standard, and a standard tuned badly produces the second failure where every clause comes back flagged as a deviation.
• How a proposed change reaches the other side. An accurate record is no use if the edit arrives as untracked prose, the defect in the suggested edit that lands as clean text.
• What the document looks like when regenerated. Extraction accuracy carries nothing into assembly, so a correct indemnity still emerges inside a generated document that does not look like firm paper.

The through-line is that an indemnity record is an operational object rather than a summary: somebody will answer whether a claim is covered from the record, and will not open the contract to check. Building the surface where it is read, corrected and trusted is ordinary internal tools and operations software, and it sits with the rest of contract review, clause risk and redlining in our work with legal teams.

• indemnity
• clause extraction
• contract review
• diagnosis