# Submission Intake

Turn an underwriting submission packet into a clean, organized data set and a decision-ready briefing — so the underwriter's job becomes *review and decide* rather than *read and assemble*.

## The business problem

A new-business submission rarely arrives as a single tidy form. It comes as a packet: an ACORD application, a statement of values, one or more loss runs, a supplemental questionnaire, maybe a census, plus the broker's cover email and assorted correspondence. Before an underwriter can price or triage the risk, someone has to open every document, work out what each one is, and copy the relevant facts into a working view of the account. That reading-and-assembling step can take an hour or more per submission, and it scales badly during busy renewal seasons.

The **Submission Intake** template automates that first pass. It reads each document in the packet, classifies it, extracts the fields that matter for that document type, and synthesizes a one-page picture of the submission — exposure, coverage requested, loss history, and risk drivers — ready for an underwriter to review.

## Trigger and source data

The template ships with the **Manual File Upload** trigger so you can drop in a sample packet and run it while you build and test. For production email-driven intake, switch to the **Outlook Trigger**, which starts the flow when a matching submission email arrives in a connected mailbox. Both triggers are available today. Other trigger types you may have seen elsewhere — inbound webhooks, scheduled/timer triggers, and SFTP — are **not currently available**; if you need to start runs from another system, drive the flow through the [Bevaya API](/api/flow-executions#run-a-flow) instead. See [Configure triggers](../build-ai-agents/triggers.md).

The source data is a submission packet containing any mix of the document types the template recognizes:

- **ACORD forms** — standardized insurance application forms
- **Statements of Values (SOVs)** — property schedules with building, limit, and construction detail
- **Supplemental Applications** — risk questionnaires and additional forms
- **Loss Runs** — historical claims data
- **Census** — employee lists for health plans (often a spreadsheet)
- **Correspondence** — emails, letters, and memos

Anything that doesn't match a known type is routed to a generic **Other** extractor so it is still captured rather than dropped.

## Template starting point

Open the builder, create an AI agent from the **Submission Intake** template, and you get a working flow you can run immediately on a sample packet. From there you customize the prompts, fields, and validation rules to your own underwriting standards. See [Create an AI Agent](../build-ai-agents/create-agent.md) for how templates and drafts work.

## What the template preconfigures

The template arrives wired end to end. In Bevaya terms, it is built from these released nodes:

| Step in the flow | Node it uses | Category |
| --- | --- | --- |
| Prepare the uploaded files for processing | [Read Files](../build-ai-agents/utility-nodes.md) | Utility |
| Process every document in the packet | [For Loop](../build-ai-agents/control-nodes.md) | Control |
| Classify each document and extract its 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 |
| Synthesize a submission-level summary | [InsurGPT: Custom](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Check extracted values against rules | [Field Validation](../build-ai-agents/utility-nodes.md) | Utility |
| Generate the underwriting briefing | [Insights](../build-ai-agents/insurgpt-nodes.md) | InsurGPT |
| Branch to review only when needed | [Conditional Branching](../build-ai-agents/control-nodes.md) | Control |
| Route exceptions to a person | [Flag for Human Review](../build-ai-agents/utility-nodes.md) | Utility |
| Close out the work item | [Mark Item as Complete](../build-ai-agents/action-nodes.md) | Action |

It also ships with default field sets for each document type — for example, address, building and contents limits, deductible, construction type, year built, and protections for an SOV; claim-by-claim history for a loss run; legal entity, FEIN, operations, and class codes for a supplemental — and a submission-summary step that produces line of business, coverage and limit summary, loss-history metrics, an exposure and valuation summary, and notable risk drivers.

## What builders must configure before deployment

The defaults are a strong starting point, not a finished configuration. Before you deploy, plan to:

- **Tune the classification step** for the documents your shop actually sees. The whole flow keys off getting document type right, so refining the classification prompt pays off across every extractor downstream.
- **Adjust field sets per document type** to match your underwriting templates — add a field, drop one you never use, or tighten a field's description and allowed values.
- **Set validation thresholds** that fit your risk tolerance. The default flags any field extracted with confidence below 80%; raise the bar on high-stakes fields and lower it on low-stakes ones. See [Utility nodes](../build-ai-agents/utility-nodes.md).
- **Decide the review gate.** The template routes to human review only when validation flags more than one field; adjust that condition to make review stricter or looser.
- **Choose your trigger and environment.** Point the Outlook Trigger at the right mailbox for production, and set any per-environment values as variables. See [Configure environments and variables](../build-ai-agents/environments-variables.md).

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](../onboarding/users-access.md).

## Matching target

Submission Intake does not match the packet against a system of record. Its job is to organize and synthesize the submission, then hand a trusted, structured data set to the underwriting process — whether that is an underwriter reviewing it in the Bevaya Platform or a downstream system you push the data to with an [API Request](../build-ai-agents/utility-nodes.md) node. If you need to associate a submission with an existing account or policy record, that is a customization you add, not a built-in step of this template.

## How the AI agent behaves

For each document in the packet, the agent classifies the document type and extracts the fields defined for that type, working only from the supplied content. After the loop finishes, a synthesis step reads across everything extracted and produces the submission-level summary, and the Insights step turns that into a plain-language underwriting briefing.

The agent does not invent values. Where it cannot confidently extract a field, the validation step flags it rather than guessing, and the flow routes the item to a person. Enabling **Grounding** on the extraction step ties each value back to its place on the source page, so a reviewer can see exactly where a number came from. AI output is treated as needing confirmation — it is validated and reviewed, never written straight to a system of record.

## Human review model

Review happens in the Bevaya Platform on the work item the flow creates, and reviewers work from two tabs:

- The **Insights tab** is the briefing the reviewer reads first — a severity banner for anything urgent (an out-of-appetite class, a total insured value above written authority, a major missing-document gap), an AI recommendation with a confidence score and a suggested next action, a quick-stats strip, a triage summary, a risk rating with strengths and flags, the source documents, and an audit trail.
- The **Review tab** is field-by-field verification, organized by document category — Submission Overview, SOVs, ACORDs, Supplemental Apps, Loss Runs, Census, Correspondence, Other — where the reviewer confirms a value, edits anything the AI got wrong, and approves.

A reviewer works one item at a time, and the **Reviewer** role can open, save, submit, and complete reviews but cannot build or run flows. Insights tells the reviewer *what's in the submission and what to do*; Review lets them *verify the underlying data and make corrections*. For the full reviewer experience see [Human review](../monitor-review/human-review.md).

## Run status and reporting

Once published and running, each submission becomes a work item that moves through the standard lifecycle statuses — **Queued, In Progress, Deferred, Review, Complete, Closed, Failed, Canceled**. You can watch individual runs and inspect each step's input, output, and status in [Run history](../monitor-review/run-history.md), and see counts of items by current status on the [Item status reporting](../monitor-review/item-status-reporting.md) page. Status reporting is a live count of where work stands; it is not a trend, throughput, or straight-through-processing analytics view.

## Example run

A broker emails a general-liability and property submission for a mid-sized manufacturer: an ACORD 125/126, an SOV spreadsheet with eight locations, three years of loss runs, a supplemental application, and a cover note.

1. The flow ingests the packet and prepares each file.
2. It classifies the documents — ACORD, SOV, Loss Runs, Supplemental Application, Correspondence — and extracts the fields for each: location and building detail and limits from the SOV, claim-by-claim history from the loss runs, operations and class codes from the supplemental.
3. The synthesis step produces a submission summary: line of business, total insured value across the eight locations, a loss-history rollup, and risk drivers (one location in a CAT-exposed zone, a clean three-year loss record otherwise).
4. Validation flags the SOV deductible on one location as low-confidence, so the flow routes the item to review.
5. The underwriter opens the work item, reads the Insights briefing, jumps to the SOV group on the Review tab, corrects the deductible against the source page, and submits. The item is marked complete.

What would have been an hour of reading becomes a few minutes of verifying.

## Common failure modes

- **A document is misclassified.** A cover email reads like a formal application, or a supplemental looks like an ACORD. The reviewer can correct the classification during review and resubmit the item so the agent re-runs the extraction for the corrected type. Persistent patterns are best fixed by adding a disambiguation rule to the classification prompt.
- **Low-confidence or missing fields.** Poor scans, handwriting, or unusual layouts produce values the agent can't extract confidently. These are flagged by validation and surfaced for review rather than fabricated.
- **An unrecognized document type.** Anything outside the known set is routed to the **Other** extractor, which captures title, date, key content, and purpose so nothing in the packet is silently lost.
- **A document the model reads poorly because structure matters.** For dense, position-sensitive forms, enable **Grounding** so values are tied back to the page and easier to verify.

## Recommended rollout path

1. **Build and test on real samples.** Start the agent from the template and use **Run Draft** with a representative set of submission packets, inspecting each step's output. See [Test and debug a draft](../build-ai-agents/test-debug-draft.md).
2. **Tune classification and field sets** until extraction is reliable on your document mix, then set validation thresholds to your standards.
3. **Pilot with review on every item.** Loosen the review gate so a person confirms each submission while you build confidence in the extractions.
4. **Promote to production.** Publish the flow, point the Outlook Trigger at the production mailbox, and confirm variables resolve correctly in the production environment. See [Drafts and publishing](../build-ai-agents/drafts-publishing.md).
5. **Tighten the gate over time.** As accuracy proves out, raise validation thresholds and narrow the review gate so routine submissions flow through and only genuine exceptions reach a person.

## Where to go next

- [Configure triggers](../build-ai-agents/triggers.md) — set up Manual File Upload for testing and the Outlook Trigger for production intake.
- [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md) — how classification, extraction, and the briefing step are configured.
- [Utility nodes](../build-ai-agents/utility-nodes.md) — Read Files, Field Validation, and Flag for Human Review.
- [Human review](../monitor-review/human-review.md) — the Insights and Review tabs the underwriter works from.
- [Item status reporting](../monitor-review/item-status-reporting.md) — track submissions by status.
- [Start a flow run (API)](/api/flow-executions#run-a-flow) — drive intake programmatically from another system.
- [Use cases overview](./overview.md) — the full catalog of supported patterns.