# Claim-to-Policy Comparison

Set up a new claim from an FNOL package *and* run an AI coverage comparison against the policy in force — so the adjuster opens a prepared claim with the analysis already laid out, and decides rather than assembles.

## The business problem

When a new loss is reported, an adjuster has to do two jobs before any real decision can be made. First, **set the claim up**: read the FNOL package, pull the loss facts, find the right policy, create the claim record, set an initial reserve, assign an adjuster, and attach the documents. Second, **understand coverage**: compare the loss against the actual 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 the setup and assembles the coverage comparison, then hands the prepared claim to an adjuster to approve. It is the full FNOL setup workflow *with* a coverage analysis built in. If you want a person to handle coverage review themselves, a lighter FNOL-setup pattern without the comparison step exists separately and is out of scope for this page.

> **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 claim is finalized, and can override any field or finding.

## Trigger and source data

The template ships with the **Manual File Upload** trigger for testing. For production, use the **Outlook Trigger** to start the flow when an FNOL email arrives in a connected intake mailbox. Both triggers are available today; inbound webhooks, scheduled/timer triggers, and SFTP are **not currently available**. To start runs from another system, drive the flow through the [Bevaya API](/api/flow-executions#run-a-flow). See [Configure triggers](../build-ai-agents/triggers.md).

The source data is 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
- A **contractor estimate** for the repair scope (if applicable)
- A **mitigation invoice** for emergency services (if applicable)
- **Damage photos** or correspondence (optional)

You also need a policy number that exists in the carrier system; the flow looks up the matching policy and pulls its full detail and endorsements for the comparison. If no policy match is found, the flow surfaces that for review rather than guessing.

## Template starting point

Create an AI agent from the **Claim-to-Policy Comparison** template and you get a working FNOL-to-prepared-claim flow with the coverage comparison wired in. You then point the carrier steps at your system and tune the extraction, matching, and analysis to your line of business. See [Create an AI Agent](../build-ai-agents/create-agent.md).

## 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 files | [Read Files](../build-ai-agents/utility-nodes.md) | Utility |
| Process each document in the package | [For Loop](../build-ai-agents/control-nodes.md) | Control |
| Classify the package and each document, and extract per-type fields | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Route each document to the right extractor | [Multiple Condition Branches](../build-ai-agents/control-nodes.md) | Control |
| Match the FNOL's policy number to a policy record | [Custom Code Blocks](../build-ai-agents/utility-nodes.md) | Utility |
| Look up the policy, its detail, and endorsements | [API Request](../build-ai-agents/utility-nodes.md) | Utility |
| Compare the loss to the policy and recommend a reserve | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Check extracted and analyzed values against rules | [Field Validation](../build-ai-agents/utility-nodes.md) | Utility |
| Generate the adjuster briefing | [Insights](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Create the claim, set the reserve, assign an adjuster, add the AI note | [API Request](../build-ai-agents/utility-nodes.md) or [Guidewire app nodes](../build-ai-agents/app-integration-nodes.md) | Utility / Apps |
| Upload each source document to the claim | [HTTP File Upload](../build-ai-agents/utility-nodes.md) | Utility |
| Route the prepared claim to an adjuster | [Flag for Human Review](../build-ai-agents/utility-nodes.md) | Utility |
| Close out the work item on either branch | [Mark Item as Complete](../build-ai-agents/action-nodes.md) | Action |

The coverage analysis step produces the structured findings shown to the adjuster — coverage verification, applicable coverages, exclusions, sub-limit and endorsement flags, fault assessment, injuries summary, policy status, bodily-injury severity, and a recommended next action — alongside a recommended initial reserve.

## What builders must configure before deployment

- **Carrier connection variables.** Store the carrier base URL and API credential as variables in **Settings → Variables** and reference them from the lookup and write-back nodes. Values are encrypted and masked; there is no separate secret type. See [Configure environments and variables](../build-ai-agents/environments-variables.md).
- **Lookup and write-back endpoints.** Point the policy lookup, claim creation, reserve, assignment, note, and document-upload steps at your carrier's API. If you run Guidewire ClaimCenter, use the [Guidewire app nodes](../build-ai-agents/app-integration-nodes.md) (Search / Create / Update a Guidewire Claim) for the claim operations.
- **Policy-matching logic.** The default matcher finds the policy by the extracted policy number; extend it for fuzzy matching, fallback by claim number, or multi-policy households.
- **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.

The AI extraction, coverage-analysis, 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](../onboarding/users-access.md).

## Matching target

The matching target is the **policy in force** in your carrier system. The flow matches the FNOL's policy number to a policy record, then pulls the policy's detail and endorsements so the comparison runs against live policy data. Because the analysis is only as good as the policy data it pulls, keep your carrier policy records — especially endorsements and sub-limits — current. **If no policy match is found, the flow routes the case to review with a clear exception reason and will not create a claim against an unverified policy.**

## How the AI agent behaves

The agent classifies the package and each document, extracts the per-type fields (FNOL facts, estimate totals, declarations tables for coverage limits, sub-limits, deductibles, and endorsements), and — after the policy lookup — compares the loss to the policy. 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 and the policy data it pulls; it does not invent values. 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 claim on the work 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 (high BI severity, a senior-adjuster recommendation, a subrogation angle), an AI recommendation with a confidence score and a suggested action (for example, *Activate Claim and Assign*), a quick-stats strip (reserve, loss date, BI severity), key-insights cards (coverage verification, reserve breakdown, compliance timers, assignment rationale), 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 **Flag for Human Review** gate until the adjuster submits; only then is the claim finalized in the Bevaya Platform. The **Reviewer** role can work items and reviews but cannot build or run flows. See [Human review](../monitor-review/human-review.md).

## Required integrations

This template is integration-heavy: it both reads from and writes to your carrier system. At minimum it needs policy lookup (policy list, detail, endorsements), claim creation, reserve setting, adjuster assignment, an AI note write-back, and document upload. These are built with [API Request](../build-ai-agents/utility-nodes.md) and [HTTP File Upload](../build-ai-agents/utility-nodes.md) nodes, or — on Guidewire ClaimCenter — with the [Guidewire app nodes](../build-ai-agents/app-integration-nodes.md). As long as your carrier system supports those operations through its API, the flow can be wired to it.

## Run status and reporting

Each FNOL 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](../monitor-review/run-history.md), and see live counts of items by status on the [Item status reporting](../monitor-review/item-status-reporting.md) 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.

1. The flow ingests the package and prepares the files.
2. It classifies the documents and extracts the loss facts, the estimate and mitigation totals, and the declarations tables (coverage limits, sub-limits, deductibles, endorsements).
3. It matches the policy number to a policy record and pulls the policy detail and endorsements from the carrier system.
4. The coverage analysis 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.
5. The flow creates the claim, sets the reserve, assigns an adjuster, attaches the documents, and adds the coverage analysis as a note on the claim.
6. The adjuster opens the work 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 setup-and-coverage job becomes a few minutes of review.

## Common failure modes

- **No matching policy.** The flow routes to review with an exception reason and does not create a claim against an unverified policy.
- **Stale carrier policy data.** Missing endorsements or out-of-date sub-limits weaken the comparison — the analysis reflects whatever the carrier system returns. Keep policy records current.
- **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.
- **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

1. **Build and test on sample FNOLs.** Start from the template and use **Run Draft** in a test environment pointed at a carrier sandbox, inspecting each step. See [Test and debug a draft](../build-ai-agents/test-debug-draft.md).
2. **Validate policy matching and the coverage analysis** against known claims before any production write-back.
3. **Pilot with the adjuster gate on every claim** so a person approves each setup and coverage comparison while you build trust in the findings.
4. **Promote to production** once write-back is verified against the live carrier system — publish the flow, point the trigger at the production mailbox, and confirm variables resolve to production settings. See [Drafts and publishing](../build-ai-agents/drafts-publishing.md).
5. **Keep the human in the loop.** Because this template creates claims and sets reserves, the adjuster approval gate is the control that keeps it safe; keep it in place even as accuracy proves out.

## Where to go next

- [App integration nodes](../build-ai-agents/app-integration-nodes.md) — Guidewire and the carrier write-back steps.
- [Utility nodes](../build-ai-agents/utility-nodes.md) — API Request, HTTP File Upload, Custom Code Blocks, Field Validation, and Flag for Human Review.
- [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md) — classification, extraction, coverage analysis, and the briefing.
- [Human review](../monitor-review/human-review.md) — the Insights and Review tabs the adjuster works from.
- [Claim Indexing](./claims-indexing.md) — for filing inbound mail against a claim that already exists, rather than opening a new one.
- [Item status reporting](../monitor-review/item-status-reporting.md) — track claims by status.
- [Use cases overview](./overview.md) — the full catalog of supported patterns.