Claim-to-Policy Comparison
Read an FNOL package and run an AI coverage comparison against the policy documents provided — so the adjuster opens a prepared analysis with the reasoning already laid out, and decides rather than assembles.
The business problem
When a new loss is reported, an adjuster has to do real work before any decision can be made: read the FNOL package, pull the loss facts, and compare the loss against the policy — limits, sub-limits, deductibles, endorsements, exclusions — to know what's covered before reserving and reaching out to the insured. Done by hand, that is a 30-to-45-minute job per claim, and the coverage comparison is exactly where small misses (a sub-limit a few thousand dollars below the estimate) become expensive at settlement.
The Claim-to-Policy Comparison template automates that reading-and-comparing pass. It classifies and extracts every document in the package — including the policy documents — runs the coverage analysis, recommends a reserve, and hands the prepared briefing to an adjuster to review and approve.
Important: the comparison is decision support, not a decision. The agent assembles the coverage analysis and lays out the reasoning and evidence. It does not make a binding coverage or liability determination. An adjuster reviews and approves before the item is finalized, and can override any field or finding.
Trigger and source data
The template ships with the Manual File Upload trigger. You can configure other triggers if you'd like, including a connection to an Outlook email inbox so the flow starts when an FNOL email arrives. Inbound webhooks, scheduled/timer triggers, and SFTP are not currently available. To start runs from another system, drive the flow through the Bevaya API. See Configure triggers.
To run the template, manually upload an FNOL package — typically an email with a few attachments — containing one or more of:
- An FNOL report or notice describing the loss
- A policy declarations page identifying the policy in force
- An insurance policy — the full carrier-issued policy form (optional but recommended)
- A contractor estimate for the repair scope (if applicable)
- A mitigation invoice for emergency services (if applicable)
- Damage photos or correspondence (optional)
The comparison runs against the policy documents included in the package — the flow does not look up policy data from a carrier system. If the package contains no policy document, the flow still runs, but the briefing states clearly that no insurance policy was provided and that coverage terms, limits, deductibles, and endorsement details could not be verified.
Template starting point
Create an AI agent from the Claim-to-Policy Comparison template and you get a working flow that classifies, extracts, compares, and briefs out of the box. Once the template is open in the canvas, select an environment, click Start Editing, and make any changes you'd like to tune the template to your line of business and documents — for example, adjust field prompts, the coverage-analysis and reserve prompts, or validation thresholds. See Create an AI Agent.
What the template preconfigures
The template will execute the following nodes:
| Step in the flow | Node it uses | Category |
|---|---|---|
| Prepare the uploaded files | Read Files | Utility |
| Pull package-level context (loss facts, policy number, insured) | InsurGPT: Custom | InsurGPT |
| Process each document in the package | For Loop | Control |
| Classify each document and extract per-type fields | InsurGPT: Custom | InsurGPT |
| Route each document to the right extractor | Switch | Control |
| Compare the loss to the policy documents | InsurGPT: Custom | InsurGPT |
| Recommend an initial reserve | InsurGPT: Custom | InsurGPT |
| Check extracted and analyzed values against rules | Field Validation | Utility |
| Generate the adjuster briefing | Insights | InsurGPT |
| Route the prepared analysis to an adjuster | Review | Utility |
| Close out the item | Complete | Action |
The coverage analysis step produces the structured findings shown to the adjuster — coverage verification, applicable coverages, exclusions, sub-limit and endorsement flags, and a recommended next action — alongside a recommended initial reserve.
What builders must configure before deployment
- Extraction, analysis, and validation. Tune the classification and extraction prompts and fields, the coverage-analysis and reserve prompts, and the validation rules to your line of business and standards.
- Validation thresholds and review routing. Set confidence thresholds and the reviewer assignment to your standards. See Utility nodes.
How the AI agent behaves
The agent classifies the package and each document, extracts the per-type fields (FNOL facts, estimate totals, and the policy tables — coverage limits, sub-limits, deductibles, and endorsements — from the declarations page and policy form), and compares the loss to the policy terms found in the package. The comparison produces evidence-backed findings, not verdicts: it verifies which coverages apply, flags where an estimate exceeds a sub-limit, calls out relevant endorsements and exclusions, and proposes a reserve and a next action with a confidence score.
The agent works only from the supplied documents; it does not invent values. If no insurance policy is included in the package, the briefing says so up front rather than guessing at coverage terms. Low-confidence or missing fields are flagged by validation rather than fabricated, and Grounding ties extracted values back to the source page. Every finding is presented for an adjuster to confirm — the agent's role is to assemble and explain, the adjuster's role is to decide.
Human review model
The adjuster reviews the prepared analysis on the item in the Bevaya Platform, across two tabs:
- The Insights tab is the decision-ready briefing: a severity banner for anything to know up front, an AI recommendation with a confidence score and a suggested action, a quick-stats strip (reserve, loss date, peril), key-insights cards (coverage verification, reserve breakdown, sub-limit and endorsement flags), a loss narrative summarized by source document, the source documents, and an audit trail.
- The Review tab is field-by-field verification — loss date, location, peril, vendor, estimate totals, policy limits, sub-limits, deductibles, endorsements — each with its source document and page, where the adjuster confirms, edits, and approves.
The flow pauses at the Review gate until the adjuster submits; only then is the item finalized. Reviewers can work items and reviews but cannot build or run flows. See Human review.
Run status and reporting
Each FNOL becomes an item that moves through the standard lifecycle statuses — In Progress, Review, Complete, 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 straight-through-processing analytic.
Example run
A homeowner reports water damage. The broker emails the FNOL form, a policy declarations page, a mitigation invoice, and a contractor estimate.
- The flow ingests the package and prepares the files.
- It classifies the documents and extracts the loss facts, the estimate and mitigation totals, and the declarations tables (coverage limits, sub-limits, deductibles, endorsements).
- The coverage analysis compares the loss against the policy terms in the package, confirms the peril is covered, flags that the contractor estimate exceeds the water-mitigation sub-limit by a few thousand dollars, and recommends an initial reserve.
- Validation checks the extracted and analyzed fields against the confidence threshold; anything below is flagged.
- The adjuster opens the item, reads the Insights briefing, confirms the sub-limit flag on the Review tab against the declarations page, approves, and the item is marked complete.
A 30-to-45-minute reading-and-comparing job becomes a few minutes of review.
Common failure modes
- No insurance policy in the package. The flow still runs, but coverage terms, limits, deductibles, and endorsement details cannot be verified, so many fields will be blank. The briefing states this up front so the adjuster knows to request the policy before relying on the analysis.
- Low-confidence or missing fields. Poor scans or incomplete packages produce values the agent can't confirm; these are flagged by validation and surfaced for review rather than fabricated.
- A misclassified document. The adjuster corrects the classification during review and resubmits so the agent re-runs extraction for the corrected type; persistent patterns are best fixed in the classification prompt.
- Complex claims (multi-coverage, multi-claimant). The per-document loop scales to the package and the analysis reasons across it; especially complex lines can be extended with additional branches per coverage type or claimant.
Recommended rollout path
- Build and test on sample FNOLs. Start from the template and use Run Draft on representative packages, inspecting each step. See Test and debug a draft.
- Validate the coverage analysis against known claims — confirm the sub-limit and endorsement flags line up with what an experienced adjuster would find.
- Pilot with the adjuster gate on every claim so a person approves each coverage comparison while you build trust in the findings.
- Promote to production. Publish the flow and configure your production trigger — for example, a connection to an Outlook email inbox. See Drafts and publishing.
- Keep the human in the loop. The comparison is decision support; the adjuster approval gate is the control that keeps it safe, so keep it in place even as accuracy proves out.
Where to go next
- Utility nodes — Field Validation and Review.
- InsurGPT nodes — classification, extraction, coverage analysis, and the briefing.
- Human review — the Insights and Review tabs the adjuster works from.
- Claim Indexing — for classifying and extracting inbound claim mail, rather than analyzing a new loss.
- Item status reporting — track claims by status.
- Use cases overview — the full catalog of supported patterns.