Claim File Summarization
Turn an entire claim file — FNOL, adjuster notes, medical records, financials, witness statements, policy documents — into a one-page briefing that gets a reviewer up to speed in minutes instead of hours.
The business problem
Coming up to speed on an existing claim is slow. An adjuster taking over a file, a supervisor doing a periodic review, or a senior adjuster auditing exposure has to read through everything in the file — the original loss report, every note, the medical records, the financials, any legal documents — just to find their footing before they can act. On a mature claim that can be an hour of reading per file.
The Claim File Summarization template reads the whole claim file and produces a structured summary: the loss event, the investigation, the financials, the coverage picture, and the open actions. The reviewer reads a one-page briefing and gets oriented in minutes.
Accountability and limitations. The summary is generated text and decision support, not an authoritative record. It is the reviewer's starting point, not a substitute for the file or for professional judgment. The reviewer confirms the underlying extractions and remains accountable for any decision made from the summary.
Trigger and source data
The template ships with the Manual File Upload trigger, which accepts a single PDF or a zipped claim file. To start summaries automatically from your claims system — for example on adjuster reassignment or when a supervisor review is scheduled — drive the flow through the Bevaya API. Inbound webhooks, scheduled/timer triggers, and SFTP are not currently available. See Configure triggers.
The source data is a claim file — typically multiple PDFs covering the life of the claim. You can upload the documents individually, or upload the whole file as a single archive and let the template expand it. Common document types include:
- FNOL or claim notice — the original loss report
- Adjuster investigation reports — field notes, witness statements, photos
- Medical records and bills
- Witness statements or sworn declarations
- Financial summaries — payments to date, reserves, recoveries
- Legal documents — if the claim is in or near litigation
- Policy declarations or full policy form — optional, but enables a coverage evaluation if included
The summary's quality scales with the documents you provide: a file with the FNOL, adjuster notes, medical records, financials, and a policy declaration produces a much richer summary than an FNOL alone.
Template starting point
Create an AI agent from the Claim File Summarization template and you get a working summarization flow out of the box. It runs as a self-contained workflow — the summary lands on the work item in the Bevaya Platform — and is built to be extended with a write-back to your claims system when you want the summary posted there. See Create an AI Agent.
What the template preconfigures
The template is wired end to end from these released nodes:
| Step in the flow | Node it uses | Category |
|---|---|---|
| Prepare the uploaded documents for processing | Read Files | Utility |
| Extract the claim details (and whether a policy doc is present) | InsurGPT: Custom | InsurGPT |
| Branch on whether a policy document was provided | Conditional Branching | Control |
| Extract the policy and coverage details (only if a policy doc is present) | InsurGPT: Custom | InsurGPT |
| Extract the loss summary and handoff context | InsurGPT: Custom | InsurGPT |
| Generate the one-page briefing | Insights | InsurGPT |
| Check extracted values against rules | Field Validation | Utility |
| Route the summary to a person for review | Flag for Human Review | Utility |
| Close out the work item | Mark Item as Complete | Action |
The three extraction steps produce the structured content behind the briefing: claim details (claim number, line of business, date of loss, insured and claimant, injuries, financials, reserve and paid-to-date, days open, severity, reserve and payments analysis, pending actions); policy and coverage details with a coverage evaluation; and a loss summary covering the event, the assessment process, and handoff context.
What builders must configure before deployment
- Extraction prompts and fields. Tune the three extraction steps to your shop's reserving philosophy, severity definitions, and the fields you care about.
- Validation thresholds. The default flags any field extracted with confidence below 80%; adjust per field. See Utility nodes.
- Optional write-back. Out of the box the summary lives on the work item in the Bevaya Platform. To post it back to your claims system as a note, attachment, or queue item, add an API Request node after the briefing step that calls your carrier's API, with the connection details stored as variables in Settings → Variables. See Configure environments and variables.
- Trigger. Keep Manual File Upload for on-demand use, or drive the flow from your claims system through the API for system-initiated summaries.
The AI extraction and insight steps are an AI intelligence capability available to the Admin role; the Partner role can build the rest of the flow but is restricted from AI intelligence features. See Users and access.
Matching target
There is no system match in this template. Claim File Summarization reads the documents you give it and produces a summary; it does not look up or modify a record in your carrier system. If you want the summary associated with a claim record, add a write-back step that posts it there.
How the AI agent behaves
The agent extracts the claim, policy, and loss content from the uploaded documents, working only from what's in the file, then composes the one-page briefing from that extracted content and the documents. It associates its statements with the source material rather than outside knowledge — and with Grounding enabled on the extraction steps, values are tied back to the page they came from so a reviewer can verify them.
The agent handles the common case where a policy document isn't in the file: the claim-details step records whether a policy doc is present, and a conditional branch skips the policy extraction when it isn't, so the rest of the summary still produces and the coverage fields are simply left blank with a note. Where it cannot confidently extract a value, validation flags it rather than fabricating one. The briefing is a summary, not an authoritative record; where the wording matters it is routed through human review.
Human review model
The reviewer works the summary on the work item in the Bevaya Platform, across two tabs:
- The Insights tab is the one-page briefing: a severity banner (High / Medium / Low with the reasoning), an AI recommendation with a confidence score and a suggested next action, a quick-stats strip (total reserve, paid to date, days open, severity, claim number), key-insights cards (coverage evaluation, reserve analysis, payments analysis, pending actions grouped by owner), a loss summary (the event, the assessment process, and handoff context), the source documents, and an audit trail.
- The Review tab is field-by-field verification, organized by extraction group — Claim Details, Policy Details, Loss Summary — where the reviewer confirms, edits, and approves.
The flow pauses at the Flag for Human Review gate until the reviewer submits. The Reviewer role can work items and reviews but cannot build or run flows. See Human review.
Privacy considerations
Claim files often contain sensitive material — medical records, personal identifiers, financial detail. That content is processed within your organization's isolated tenant; each run is scoped to your organization, and any connection credentials used in a write-back are stored as encrypted, masked variables rather than in the flow. The AI summary is treated as decision support, confirmed by a reviewer before it is relied on. Handle the resulting work items and any write-back in line with your own privacy and records policies.
Run status and reporting
Each claim file becomes a work item that moves through the standard lifecycle statuses — Queued, In Progress, Deferred, Review, Complete, Closed, Failed, Canceled. Watch individual runs and inspect each step's input, output, and status in Run history, and see live counts of items by status on the Item status reporting page. Status reporting is a live count of where work stands, not a trend or throughput analytic.
Example run
An adjuster is reassigned a two-year-old property claim and needs to get up to speed before a call with the insured that afternoon. They zip the claim file — FNOL, eighteen months of adjuster notes, two contractor estimates, payment records, and the policy declarations — and run the flow.
- The flow expands the archive and prepares each document.
- It extracts the claim details, sees that a policy declaration is present, and runs the policy and coverage extraction; it also extracts the loss summary and handoff context.
- The briefing step produces a one-page summary: the loss event and how it was investigated, the financial picture (reserve, paid to date, days open), the coverage evaluation, and the pending actions grouped by owner.
- Validation passes, and the flow routes the summary to review.
- The receiving adjuster reads the Insights briefing, confirms the financials on the Review tab, and walks into the call already oriented — minutes of reading instead of an afternoon.
Common failure modes
- No policy document in the file. Handled automatically — the policy extraction is skipped and the coverage fields are left blank with a note; the rest of the summary still produces. Include the policy declarations (or retrieve it via a write-back's companion lookup) to get the coverage evaluation.
- A thin claim file. The summary scales with the documents provided; an FNOL on its own yields a thin summary. More documents produce a richer one.
- Low-confidence fields. Poor scans or unusual layouts produce values the agent can't confirm; these are flagged by validation and surfaced for review rather than guessed.
- Expecting a system write-back out of the box. The template ships without one — the summary lives on the work item until you add an API Request step to post it to your claims system.
Recommended rollout path
- Build and test on real files. Start from the template and use Run Draft on a range of claim files — large and small, with and without a policy doc — inspecting each step. See Test and debug a draft.
- Tune the extraction prompts to your reserving philosophy, severity definitions, and recommendation framing, and set validation thresholds.
- Pilot for a specific workflow such as adjuster handoffs or supervisor reviews, with a reviewer confirming each summary.
- Add a write-back if you want the summary in your system of record, then publish and confirm variables resolve in the production environment. See Drafts and publishing.
- Expand to more review and audit workflows once the summaries prove reliable for your teams.
Where to go next
- InsurGPT nodes — the extraction and Insights steps behind the summary.
- Utility nodes — Read Files, Field Validation, Flag for Human Review, and API Request for an optional write-back.
- Control nodes — the conditional branch that skips policy extraction.
- Human review — the Insights and Review tabs the reviewer works from.
- Claim Indexing — for filing inbound documents against a claim, rather than summarizing a file already on hand.
- Item status reporting — track summaries by status.
- Use cases overview — the full catalog of supported patterns.