# Legal Demands Identification and Extraction

Automatically identify whether an incoming package contains a legal demand, classify it into the right document type, extract the fields that matter for that type, and route only the exceptions to a person.

## The business problem

Legal correspondence — demand letters, lien notices, settlement disbursements, court filings, and more — arrives in the same claim mail queue as everything else, mixed in with routine correspondence that needs no immediate action. Each type carries its own deadline, its own parties, and its own fields to capture, and someone has to read every package closely enough to tell them apart before any of that information reaches the person who needs it.

The **Legal Demands Identification and Extraction** template automates that pass: it triages the package, decides whether it's a demand, classifies demands into one of 17 document types, and extracts the fields specific to that type — so a reviewer only sees the packages that are missing something, low-confidence, or need a human decision.

## 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. See [Configure triggers](../build-ai-agents/triggers.md).

To run the template, upload a piece of legal correspondence — a single letter, an email thread, or a package with attachments. The template recognizes:

- **Demand types** — First Notice of Demand, Demand Analysis, Lien Demand, Counter Demand, Subrogation, and other demand-related classifications
- **Non-demand legal correspondence** — Notice of Representation, Proof of Service, Court Filing, Deposition, Mediation, Legal Correspondence, and other document types that travel through the same channel without being a demand for payment

By default, the template works entirely from the uploaded content.

## Template starting point

Create an AI agent from the **Legal Demands Identification and Extraction** template for a working flow that triages, classifies, extracts, validates, and routes for review out of the box. Open it in the canvas, select an environment, click **Start Editing**, and adjust it to your document mix — field prompts, classification categories, or validation thresholds. See [Create an AI Agent](../build-ai-agents/create-agent.md).

Use it standalone, or add its nodes into an existing [Claim Indexing](./claims-indexing.md) flow as a deeper extraction step once a document is classified as legal correspondence.

## 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](../build-ai-agents/utility-nodes.md) | Utility |
| Write a package-level triage overview and determine whether the package is a demand | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Branch on whether the package is a demand | [If](../build-ai-agents/control-nodes.md) | Control |
| Extract demand package details (demand path) | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Extract package details (non-demand path) | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Classify the demand into one of 17 document types (demand path only) | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Route to the field set for the classified document type | [Switch](../build-ai-agents/control-nodes.md) | Control |
| Extract the fields specific to the classified document type | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Check extracted values against rules | [Field Validation](../build-ai-agents/utility-nodes.md) | Utility |
| Branch on whether review is required | [If](../build-ai-agents/control-nodes.md) | Control |
| Route the package to a person, only when needed | [Review](../build-ai-agents/utility-nodes.md) | Utility |
| Close out the item | [Complete](../build-ai-agents/action-nodes.md) | Action |

## What builders must configure before deployment

- **Classification and field sets.** Tune the 17 document-type categories and their field prompts to the demand types and correspondence you actually receive.
- **Validation thresholds and review routing.** Set confidence thresholds and the reviewer assignment to your standards. See [Utility nodes](../build-ai-agents/utility-nodes.md).
- **A connection to your claim system.** We recommend an [HTTP node](../build-ai-agents/utility-nodes.md) after validation to look up the claim by claimant, insured, and policy or claim number, followed by a [Custom Code Block](../build-ai-agents/utility-nodes.md) to unpack the response and apply your own matching rules.

## How the AI agent behaves

The agent writes a reviewer-facing package overview, decides whether the package is a demand, and — if it is — classifies it into a document type and extracts the fields specific to that type on top of the claimant, insured, carrier, claim number, and policy number fields common to every demand. A non-demand package skips classification and moves straight to validation with a smaller field set.

Low-confidence or missing fields are flagged by validation rather than invented, and **Grounding** ties each extracted value back to its place on the page.

## Human review model

Review happens on the item in the Bevaya Platform.

- The **Insights tab** opens with an AI recommendation, key fields (whether the package is a demand, the document type, the claimant), the package summary, red flags, and urgency or deadline signals.
- The **Review tab** is organized by group — Package Triage, Classification, Parties & Carriers, Claim & Policy Numbers, Demand Details, and Type-Specific Details — where the reviewer confirms values, corrects a misclassification or a mistranscribed field, and approves.

When a package is routed for review, the exception reason names the specific fields that were flagged — for example a missing claimant name or a low-confidence document type — so the reviewer knows exactly what to check first. See [Human review](../monitor-review/human-review.md).

## Run status and reporting

Each package 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](../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.

## Example run

A claims handler uploads a demand letter from a claimant's attorney, sent as an email with the letter attached.

1. The flow reads the file and writes a package overview: the package is a demand, a one-sentence summary of what's being asked for, no red flags, and a recommendation that no immediate action is needed beyond standard processing.
2. It extracts the demand package details — claimant, insured, carriers, claim and policy numbers, demand amount, and due date — then classifies the document as a First Notice of Demand.
3. It extracts the fields specific to that type, including the jurisdiction and date of loss.
4. Validation passes on every required field, so the item completes without routing to a person.

If the same letter had a due date but no discernible insured policy number, validation would flag that field as missing and route the package to review with the reason named.

## Common failure modes

- **A claimant's and an insured's claim or policy numbers get confused.** The two parties usually have different carriers issuing different numbers, so the agent is instructed to leave a field blank with low confidence rather than duplicate one party's number into the other's field — flagged by validation for a reviewer to confirm from the source document.
- **A package that isn't clearly a demand.** The triage step decides demand status before classification runs, so correspondence with no specific request routes through the shorter, non-demand extraction path instead of being forced into one of the 17 demand types.
- **Low-confidence or missing fields on a poor scan or an ambiguous letter.** Flagged by validation and surfaced for review rather than guessed.

## Recommended rollout path

1. **Connect it to your claim system.** Add the HTTP and Custom Code Block nodes for your claim lookup and matching logic.
2. **Build and test on real correspondence.** Use **Run Draft** on representative packages across your demand and document-type mix, inspecting each step. See [Test and debug a draft](../build-ai-agents/test-debug-draft.md).
3. **Pilot with a reviewer** to confirm triage, classification, and extraction accuracy on your document mix.
4. **Promote to production.** Publish the flow and configure your production trigger. See [Drafts and publishing](../build-ai-agents/drafts-publishing.md).

## Where to go next

- [Utility nodes](../build-ai-agents/utility-nodes.md) — Field Validation, Custom Code Blocks, and Review.
- [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md) — classification and extraction.
- [Control nodes](../build-ai-agents/control-nodes.md) — If and Switch.
- [App integration nodes](../build-ai-agents/app-integration-nodes.md) — connect a write-back to your own systems.
- [Human review](../monitor-review/human-review.md) — the Insights and Review tabs the reviewer works from.
- [Item status reporting](../monitor-review/item-status-reporting.md) — track packages by status.
- [Claim Indexing](./claims-indexing.md) — a related template for sorting mixed claim mail, including legal correspondence among other document types.
- [Use cases overview](./overview.md) — the full catalog of supported patterns.