# Use cases

Use cases start from a concrete insurance operations problem and show which Bevaya pattern solves it — the template to start from, the nodes that do the work, the integrations involved, how a person stays in the loop, and how to track the work once it's running.

Every use case follows the same shape under the hood. A flow is triggered, documents are read and prepared, an AI step classifies and extracts what matters, the flow matches or routes the result, a person reviews exceptions, and the work item is finalized — and, where it applies, data is written back to your system of record. The building blocks are the same across use cases; what changes is how they're composed and configured. See [Platform concepts](../welcome/platform-concepts.md) for the underlying model and [Build AI Agents](../build-ai-agents/overview.md) for how flows are built.

## How to choose a starting pattern

Pick a use case by matching four things to your situation:

- **The operational problem** — what work are you trying to take off a person's plate?
- **The source documents** — what arrives, and in what shape?
- **The system of record** — does the flow need to look something up or write something back, and to which system?
- **The review needs** — how much human confirmation does the work require before it's trusted?

The patterns documented today are below. Each links to its full guide; start there for the template details, the released nodes it uses, the integrations to configure, the review model, and how to track runs.

## Underwriting automation

**[Submission Intake](./submission-intake.md)** — A new-business submission arrives as a packet of mixed documents (ACORD forms, SOVs, loss runs, supplementals, census, correspondence). The flow classifies each document, extracts the fields that matter per type, and produces a one-page underwriting briefing. No system match — it organizes the submission and hands a trusted data set to the underwriting process. Review fires on exceptions; underwriters verify and decide.

## Claims automation

**[Claim-to-Policy Comparison](./claims-to-policy-comparison.md)** — A new loss is reported as an FNOL package. The flow sets up the claim end to end (creates the claim, sets a reserve, assigns an adjuster, attaches documents) *and* assembles an AI coverage comparison against the policy in force. Matches to the **policy** in your carrier system and writes the claim back. The adjuster approves before anything is finalized — the comparison is decision support, not a determination.

**[Claim Indexing](./claims-indexing.md)** — Inbound claim mail (medical bills, legal correspondence, reports, photos) needs to be filed against the right existing claim. The flow classifies each document, matches the package to an **existing claim** (by claim number, or by claimant name and date of loss), and attaches the documents with the right tags. Unmatched or mixed packages route to a person. It never creates claims or touches reserves.

**[Claim File Summarization](./claims-file-summarization.md)** — Someone needs to come up to speed on a claim quickly — an adjuster handoff, a supervisor review, an exposure audit. The flow reads the whole claim file and produces a one-page briefing (loss event, investigation, financials, coverage, open actions). No system match; the summary lives on the work item and can optionally be written back. A reviewer confirms it.

## At a glance

| Use case | Source documents | System of record | Writes back? | Review model |
| --- | --- | --- | --- | --- |
| [Submission Intake](./submission-intake.md) | Submission packet (ACORD, SOV, loss runs, supplemental, census) | None | No (optional) | Exceptions routed to review |
| [Claim-to-Policy Comparison](./claims-to-policy-comparison.md) | FNOL package + policy declarations | Policy in force | Yes — creates claim, reserve, assignment, docs | Adjuster approves every claim |
| [Claim Indexing](./claims-indexing.md) | Inbound claim correspondence | Existing claim | Yes — attaches documents only | Reviewer confirms; no-match routed |
| [Claim File Summarization](./claims-file-summarization.md) | A full claim file | None | No (optional) | Reviewer confirms each summary |

This catalog grows as more templates are documented. If a workflow you need isn't listed here yet, you can still build it from scratch — see [Create an AI Agent](../build-ai-agents/create-agent.md).

## What's common to every use case

- **Triggers.** Each template ships with **Manual File Upload** for testing; production intake uses the **Outlook Trigger**, and runs can be started programmatically through the [Bevaya API](/api). See [Configure triggers](../build-ai-agents/triggers.md).
- **Nodes.** Classification and extraction use [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md); routing and looping use [Control nodes](../build-ai-agents/control-nodes.md); file prep, validation, API calls, and human review use [Utility nodes](../build-ai-agents/utility-nodes.md); carrier connections use [App integration nodes](../build-ai-agents/app-integration-nodes.md); and the work item is closed with an [Action node](../build-ai-agents/action-nodes.md). The [Node catalog](../build-ai-agents/node-catalog.md) is the full map.
- **Human in the loop.** Exceptions and approvals route to a person via **Flag for Human Review**; reviewers work the **Insights** and **Review** tabs on the work item. See [Human review](../monitor-review/human-review.md).
- **Tracking.** Watch runs in [Run history](../monitor-review/run-history.md) and counts by status in [Item status reporting](../monitor-review/item-status-reporting.md).
- **Roles.** Building flows requires the **Admin** or **Partner** role, with AI intelligence available to **Admin**; reviewers work items but don't build. See [Users and access](../onboarding/users-access.md).

## Reading this section by audience

- **Executives** — read the problem and "At a glance" sections to see which operational problems Bevaya addresses and where a human stays accountable.
- **Implementation teams** — read each guide's template, configuration, integration, and rollout sections to scope and deliver a deployment.
- **Operations teams** — read the review model and run-status sections to understand the day-to-day reviewer experience and how to monitor the work.

## Where to go next

- [Build AI Agents](../build-ai-agents/overview.md) — how flows are built, tested, published, and run.
- [Create an AI Agent](../build-ai-agents/create-agent.md) — start from a template or build from scratch.
- [Monitor and Review](../monitor-review/overview.md) — run history, human review, and item status.
- [Bevaya API](/api) — drive any of these workflows programmatically.
- [Platform hierarchy](../onboarding/platform-hierarchy.md) and [Users and access](../onboarding/users-access.md) — set up your organization before you build.