Skip to content
Ishqkala

Claims Operations

How to Extract Actionable Tortfeasor Data from Unstructured Adjuster Notes

What adjuster notes really look like, how NLP turns claim shorthand into party, role, liability signal and evidence pointer, and where extraction goes wrong.

Siddharth Menon · Chief Technology Officer · · 5 min read

Key takeaways

  • Adjuster notes are written in shorthand by several authors over months, so extraction has to normalize abbreviations, resolve who 'he' and 'OV' refer to, and respect negation and hedging.
  • A useful extraction is a structured record: the party, its role in the loss, the liability signal, and a pointer to the exact note and sentence that supports it.
  • Evidence pointers matter as much as the signal, because a subrogation professional has to verify a lead in seconds and counsel has to rely on it later.
  • Measure precision and recall separately on your own closed files: missed leads cost recoveries, false leads cost reviewer time.

What real notes look like

Here are five diary entries from one commercial water loss, CLM-25-162087, written the way they appear in a claims system. Entry 1, 06/03 09:12, FNOL rep: 'Insd Lakeview Dental Group LLC reports water thru ceiling into ops 2 and 3. Source unk. Bldg mgr on site.' Entry 2, 06/03 14:47, field adj: 'Met w/ bldg mgr. Leak traced to unit 204 above, toilet supply line. Per mgr, tenant in 204 had Northgate Plumbing swap fixtures 5/27. Mitigation vendor removed line, asked them to bag and hold it.'

Entry 3, 06/05 10:30, field adj: 'R/S w/ 204 tenant. States he did not hire anyone, landlord's plumber did the work. Will get lease.' Entry 4, 06/09 16:05, desk adj: 'Per mitigation vendor no visible defect on line, may have let go at the fitting??' Entry 5, 06/18 11:20, desk adj: 'Lease rec'd. Sec 9 tenant responsible for fixtures, Sec 14 indemnity to landlord. Paid bldg + contents $41,300, BI pending.'

Nothing in the structured fields of this file says 'third party.' The loss cause code is water discharge, and the claimant field is empty. Everything that makes it recoverable is in those five entries.

What a good extraction returns

From those entries, an extraction should return structured records rather than highlighted words. Record 1. Party: Northgate Plumbing. Role: contractor that replaced fixtures in the source unit seven days before the loss. Liability signal: workmanship on the failed toilet supply line, with timing that supports causation. Evidence pointer: entry 2, sentences 2 and 3; physical component bagged and held by the mitigation vendor per entry 2, sentence 4.

Record 2. Party: the building owner and landlord. Role: hired the plumber, according to the tenant's recorded statement. Liability signal: possible direct or vicarious responsibility for the contractor's work. Evidence pointer: entry 3, sentence 2, flagged as conflicting with the building manager's account in entry 2.

Record 3. Party: the tenant of unit 204. Role: occupant of the source unit under a lease that assigns fixture responsibility to the tenant. Liability signal: contractual responsibility for fixtures (lease Sec. 9), plus an indemnity clause (Sec. 14) that runs to the landlord, not the insured. Evidence pointer: entry 5, sentence 2; lease document in the file.

Entry 4 is a caution, not a party. It is a hedged observation by a non-expert, relayed second-hand, ending in two question marks. The extraction lowers confidence on a manufacturing-defect theory and keeps the workmanship theory intact, because a line that separates at the fitting with no visible hose defect points toward installation more than manufacture. A keyword system would either ignore entry 4 or let 'no visible defect' suppress the whole file.

The same record shape works on auto files. An entry reading 'R/S w/ IVD: stopped at red on Elm @ 5th, OV hit from behind, OV drvr said sorry, his brakes locked' returns one record. Party: the other vehicle's driver. Role: following driver. Liability signal: rear-end impact while the insured was stopped, plus an apology and a brake-failure explanation that may point to a second party if the vehicle was recently serviced. Evidence pointer: the entry's date and time, sentences 1 and 2, with the police report number to confirm the driver's identity.

How the pipeline gets there

The steps are unglamorous and each one matters. Normalization expands claim shorthand using context: 'Insd' is the insured, 'R/S' is a recorded statement, and 'BI' in a commercial property file means business interruption, not bodily injury. Segmentation splits run-on entries into sentences while keeping each entry's timestamp and author, because a field adjuster's own observation and an FNOL rep's paraphrase carry different weight.

Entity and role resolution links mentions across entries: 'tenant in 204', 'he' and '204 tenant' are one person, and 'landlord's plumber' and 'Northgate Plumbing' are probably one company. Liability cue classification then maps each sentence to a recovery theory for the line of business, such as workmanship, product failure, lease obligation, rear-end impact or signal violation. Negation and hedge detection separates 'no third party involved' from 'third party involved?' and from 'insd thinks a third party may be involved.' Temporal anchoring orders the facts, so a repair seven days before the loss reads differently from one seven years before.

Finally, corroboration checks the narrative against other sources: an estimate line item for the supply line, photos tagged to the source unit, an ISO ClaimSearch match on the same address, or a CPSC recall on the component. A lead that appears in the notes and in a second document scores higher than one that appears once.

Where extraction goes wrong

The failure modes are predictable. Copy-forward notes repeat an early guess as if it had been confirmed. Adjuster speculation, such as 'prob the WH,' gets read as fact. Names are misspelled across entries, so one contractor becomes three. Statements conflict, as entries 2 and 3 do here, and a system that silently picks one hides the most useful thing in the file: the dispute that discovery will have to resolve.

The answer is not a single confidence number. It is a record that shows its work: which sentences support the lead, which sentences cut against it, and which facts still need a document. That is what lets a subrogation professional accept or reject a lead in under a minute.

Evaluating extraction on your own book

Measure precision and recall separately on your own closed files. Start with a few hundred files your subrogation unit has already worked: files that recovered, files closed without recovery, and files where a lead was found too late. That set gives you a recall baseline and the failure cases that matter in your book. Recall tells you how many real recoveries the system finds; precision tells you how much reviewer time it costs. Require an evidence pointer on every lead and check a random set by hand. Ishqkala's adverse liability scoring has been verified at 92% accuracy by subrogation counsel, and every lead in the platform links back to the note, report or estimate it came from.

Two governance points belong in the evaluation as well. Ishqkala does not train its models on customer claim files or adjuster notes. And extraction is decision support: licensed claim professionals and recovery counsel decide which leads become demands.

Newsletter

The Subrogation Strategist

Subrogation case law updates, arbitration rulings, and recovery workflows, monthly.

Find the millions hiding in your closed claim files before the Statute of Limitations expires.

We'll scan a batch of 500 closed claims for free and deliver an itemized recovery manifest within 5 business days.