$182,552 claimed, 15 cubic yards covered: an AI pipeline reads a real FEMA appeal
This article walks through insurance-claims-agent, a workable example from the open-source SIE repo on GitHub: a four-model pipeline that reads a published FEMA flood-insurance appeal and separates covered scope from excluded costs. SIE is Superlinked’s self-hosted inference engine, one cluster that serves embedding, reranking, OCR, vision, entity-extraction, and generation models behind three primitives (extract, encode, score). The example is a complete project with the public appeal and policy documents bundled. Built by Superlinked.
In July 2019, Lake Ontario flooded and left stone debris under a policyholder’s building. The cleanup math got ugly fast. The proof of loss came to $182,552. The debris removal estimate was $49,500. Barge transport alone was quoted at $181,832.94. And the National Flood Insurance Program policy, read carefully, covered removing 12 to 15 cubic yards of stone from beneath the building. Nothing more. Not the barge. Not the handling, the disposal, or the yard restoration.
FEMA published the appeal decision (Decision B8), which makes it a rare thing: a fully public, real-world test case for whether an AI pipeline can read a policy and an appeal record and correctly separate covered scope from excluded costs.
The insurance-claims-agent example in the SIE repo runs exactly that test.
Four models, one question
The pipeline chains four specialized models, each doing one job, every call served through SIE with endpoints and latency tracked centrally.
Docling goes first, parsing the appeal documents and the policy into structured markdown so tables and sections survive. GLiNER2 then extracts the claim facts: dollar amounts, volumes, dates, coverage terms. A BGE reranker retrieves and orders the policy language passages most relevant to the dispute, so the analysis rests on the controlling text rather than whatever paragraph happened to embed nearby. Qwen 3.5 4B closes it out, generating structured JSON that separates covered work from excluded costs.
The output lands where FEMA landed: stone removal beneath the building, within the 12-15 cubic yard scope, is covered; the barge, handling, disposal, and yard costs are outside the policy.
Why the boundary statement matters
The README draws a line worth quoting: the output “does not approve or deny coverage, calculate a payment, label fraud, or replace an adjuster.” It summarizes a published appeal for software evaluation.
Read past the disclaimer tone; that sentence is the correct product framing for this entire category. The realistic near-term role for AI in claims is evidence preparation: parse the record, extract the numbers, surface the controlling policy language, and structure the covered-versus-excluded analysis so a human adjuster starts from organized evidence instead of a document pile. The judgment stays human. What changes is how much of the adjuster’s day goes to reading versus deciding.
Building on a published appeal makes the whole exercise checkable. FEMA’s reasoning is public, so you can compare the pipeline’s scope separation against the actual decision line by line. Synthetic claims data never gives you that.
The retrieval step carries the case
Of the four stages, the reranking deserves the closest look, because coverage disputes are retrieval problems wearing a trench coat. The policy language that decides this appeal (the debris removal provision and its scope limits) sits inside a document full of provisions that mention removal, debris, buildings, and costs in other contexts. Naive similarity search surfaces all of them; they’re all “about” the same topic. The BGE reranker’s job is to put the controlling provision above the merely adjacent ones before the generation model ever sees the context.
Get that ordering wrong and the final model reasons correctly from the wrong text, which is the most dangerous failure in the pipeline because the output still looks rigorous. The structured JSON cites policy language; it’s just not the language that governs. Ranking quality, in other words, is a coverage-accuracy question, and this example makes the ranked evidence inspectable so you can audit that step on its own.
Running it
The example runs locally after a uv sync, or against SIE Cloud by setting SIE_CLUSTER_URL and SIE_API_KEY. One practical note from the README for single-GPU machines: stage the model loads across ports separately rather than loading all four at once. The appeal documents and the policy are bundled, so there’s no data hunt; the public FEMA record is the corpus.
Because every model call goes through one SIE deployment, you also get a per-stage view of the pipeline: where the latency lives, what each model consumed and produced. When a run’s conclusion looks off, you can trace it to the stage that went wrong, which is precisely the debuggability that monolithic single-model pipelines deny you.
The pattern behind the demo
Strip away the flood-insurance specifics and the architecture is a template for document-heavy adjudication anywhere: parse, extract, retrieve the controlling language, generate a structured comparison. Warranty claims, benefits disputes, procurement compliance, grant audits; the shape repeats.
Insurance happens to be the perfect proving ground because the documents are long, the money is specific, and the coverage boundaries are written down. If the pipeline can keep a $181,832.94 barge quote out of a 15-cubic-yard coverage scope, it’s doing real reading.
Clone the example, run the bundled appeal, and check the JSON against FEMA’s published decision yourself.
Try it on GitHub: superlinked/sie/examples/insurance-claims-agent