What does it mean to read a 40-page travel insurance policy in 1.8 seconds? Not skim it. Read it with enough fidelity to correctly identify the delay threshold clause, confirm whether the scheduled departure falls within the endorsement period, and map the result to a parametric payout schedule.
The question is not hypothetical. This is what our extraction pipeline does on every claim that enters the system. And explaining how it achieves that starts with understanding what a travel insurance policy actually looks like structurally, as a document.
The document structure problem
A 40-page travel policy is not a 40-page document in the way a novel or a report is. It is a layered structure: base terms, a schedule of benefits, endorsements, exclusion schedules, a definitions section that governs how every other section is interpreted, and often a set of specific conditions that override general terms in ways that are not signalled by section headings.
The clauses that matter for a flight-delay claim might appear in three different sections of the document. The definition of "delay" might sit in the definitions section. The coverage threshold might appear in the schedule of benefits. An endorsement might have modified that threshold for the specific product variant sold to this policyholder. A general exclusion might apply unless a specific condition is met, and that condition might be buried four pages into the exclusions schedule.
A human adjuster reads all of this because they have done it hundreds of times. They know where to look. They build a mental model of the structure over years of handling claims against the same or similar policies. That knowledge does not transfer automatically to a machine unless the machine has been built with that structure in mind.
What general-purpose LLMs do instead
A general-purpose language model given the same document will produce a confident-sounding summary that is frequently wrong in material ways. Not wrong in the way a confused junior adjuster might be wrong. Wrong in the way that a model trained on diverse text produces plausible continuations of insurance-contract-adjacent language, which is not the same as correctly parsing a specific document's coverage logic.
The most common failure modes we encountered before building a purpose-built extraction layer: misattributing a general exclusion as absolute when it had a carve-out; missing that an endorsement had modified the base benefit limit; confusing the insured event definition with the benefit trigger; generating coverage citations that pointed to the correct section number but quoted the wrong sentence from it.
These are not edge cases. They are systematic failures that arise from asking a general-purpose model to do something it was not trained to do: parse the coverage logic of a specific insurance contract with deterministic accuracy.
Consider a concrete scenario. A flight-delay policy for a European travel insurer includes a base benefit of CHF 400 for delays over four hours, but an endorsement issued for a specific product bundle reduces that threshold to three hours and increases the benefit to CHF 600 for holders of a premium tier. A general-purpose model will often return the base terms correctly and miss the endorsement entirely, or will merge both into an averaged interpretation that matches neither. The adjuster handling the claim would know to check endorsements first. The pipeline has to be taught that same prioritisation explicitly.
The extraction architecture
The Insurteam extraction pipeline approaches a policy document the way an experienced adjuster approaches it: by understanding the document type's structure before reading the content.
The first pass is structural segmentation. The pipeline identifies document sections by type: base terms, schedule of benefits, endorsement blocks, definition sections, exclusion schedules. This is not a general text segmentation task. It is trained specifically on the structure of travel insurance policy documents, which have consistent structural patterns even across carriers who use different templates.
The second pass is claim-type-specific clause extraction. For a flight-delay claim, the relevant clauses are: the event definition (what constitutes a qualifying delay), the threshold (minimum hours), the benefit schedule (payout per tier), any endorsement modifications to these, and any applicable exclusions. The pipeline knows which clause types to look for and where in a travel policy's structure they typically appear.
The third pass is cross-reference resolution. A clause that references a definition section needs to be evaluated with that definition applied. An endorsement that modifies a base benefit needs to be recognised as an override, not a separate independent clause. This resolution pass is where general-purpose models fail most often, and where a domain-specific architecture earns its complexity overhead.
The result is a structured JSON object representing the coverage logic for this specific claim against this specific policy: the applicable threshold, the benefit schedule, any relevant exclusions, and a confidence score for each extracted element. Extraction time is under two seconds for most policies up to 60 pages.
Confidence scoring as a routing signal
Every extracted element carries a confidence score. This is not cosmetic. It is the mechanism that determines whether a claim routes to straight-through processing or to an adjuster queue.
When all extracted elements clear a confidence threshold, the pipeline forwards the structured result to the parametric rules engine for settlement calculation. When one or more elements fall below threshold, the claim routes to a human reviewer along with the specific elements that triggered the flag. The adjuster sees exactly which clauses the pipeline was uncertain about, rather than receiving the claim cold with no context.
This routing logic is important from a regulatory and operational standpoint. Insurteam does not approve or deny claims. The pipeline prepares a structured interpretation of the policy coverage for a specific loss event, and it flags its own uncertainty. The insurer's adjuster or automated downstream system makes the settlement determination. That boundary is deliberate.
What the speed actually enables
The speed is not a performance statistic for its own sake. It is what makes straight-through processing for high-volume travel claims operationally viable. A travel insurer handling 5,000 flight-delay claims a month cannot afford a model that takes 30 seconds per policy read if those reads need to happen at submission time. The two-second extraction window is what allows the full pipeline to return a settlement decision while the policyholder is still at the airport.
We are not claiming this extraction is perfect. The 94% accuracy figure from our beta pilot means roughly 1 in 17 cases produces an extraction result with at least one element that a human reviewer would flag. Those cases go to an adjuster queue. The goal is not to replace adjuster judgment. It is to route the structured majority to straight-through processing and route the genuine edge cases to the people who can handle them.
The policies where extraction accuracy drops are predictable: heavily amended policies with multiple overlapping endorsements, policies where the definitions section is embedded inside the schedule of benefits rather than separated, and legacy policy documents formatted as scanned PDFs with inconsistent section headers. We track failure patterns by policy template and use them to improve the structural segmentation pass iteratively. Understanding where a pipeline fails systematically is more useful than reporting an overall accuracy number.
