> For the complete documentation index, see [llms.txt](https://docs.layerlens.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layerlens.ai/more-in-this-section-2/scenarios-5.md).

# Insurance scenarios

Five canonical scenarios where insurance carriers and InsurTech teams use Stratix evaluation to gate AI features into production. Patterns, not specific customers.

## 1. Claims triage and processing

**Setup:** First-notice-of-loss assistant ingests claim narrative, photos, prior policy data; produces severity bucket, coverage-applicability flag, and recommended next action (assign adjuster, pay-in-place, deny-with-reason).

**Why it's hard:**

* Severity must be calibrated — under-triage delays critical claims; over-triage clogs senior adjusters with low-value work
* Coverage-applicability requires reading a policy document the model has likely never seen
* Photos add modality risk (occluded damage, poor lighting, staged-loss indicators)

**Stakes:**

* Industry estimates put insurance fraud at \~$80B/year across P\&C lines
* Average mis-estimation cost on commercial property claims: $50K-$500K per incident
* State DOI complaint rates rise sharply when triage routes legitimate claims to denial paths

**Stratix evaluation criteria:**

| Aspect                  | What you measure                                                      | Pattern                                                |
| ----------------------- | --------------------------------------------------------------------- | ------------------------------------------------------ |
| Severity calibration    | Buckets vs. ground-truth final paid amount                            | Deterministic rule on bucket-vs-actual delta           |
| Coverage citation       | Cited policy section exists and supports decision                     | Citation-existence + judge for citation-supports-claim |
| Escalation rule         | Severity ≥ "major" auto-routes to senior adjuster                     | Hard rule — zero violations tolerated                  |
| Photo evidence handling | Claim doesn't proceed past triage without photos when policy requires | Deterministic rule                                     |
| Disparate impact        | Approval rate parity across demographic proxies (zip code, age band)  | Group fairness scorer                                  |

## 2. Underwriting risk assessment

**Setup:** AI co-pilot helps underwriter price a new policy. Inputs include applicant data, third-party risk signals, prior claims history. Output: recommended premium, risk class, exclusions to attach.

**Why it's hard:**

* Proxy discrimination — zip codes, occupation codes, even credit-tier features can encode protected class
* State-by-state rate filing rules diverge
* Recommendation must be explainable to a regulator post-hoc

**Stakes:**

* Most state DOIs flag underwriting decisions when premium varies by more than \~1.25× across otherwise similar applicants without documented basis
* DOJ and state AG investigations have followed proxy-discrimination findings in algorithmic underwriting

**Stratix evaluation criteria:**

* **Disparate impact ratio** — Fairness scorer; ratio < 0.8 fails (four-fifths rule analog)
* **Premium-band justification** — Each premium decision must cite the rate filing factor that drove it; citation-existence rule
* **State-rule applicability** — Hard rule that state-specific exclusions match the policyholder state
* **Explainability** — Judge scores whether a non-technical regulator could follow the reasoning

## 3. Policy Q\&A and customer self-service

**Setup:** Customer-facing chatbot answers questions about an active policy: "Am I covered for water damage from the supply line in my dishwasher?" Response must reference the actual policy document version on file, not generic policy language.

**Why it's hard:**

* Stale-policy interpretation — model trained on yesterday's policy form misreads today's renewal
* Coverage edge cases (deductibles, sub-limits, exclusion endorsements) are legally precise and don't tolerate paraphrase

**Stakes:**

* Carriers face state DOI complaints and class-action exposure when chatbot output contradicts the actual policy
* A miscommunicated coverage decision can trigger bad-faith claims handling allegations

**Stratix evaluation criteria:**

* **Policy-document grounding** — Retrieval-faithfulness judge against the customer's specific policy version
* **Document-version match** — Hard rule: cited document version equals customer's active version
* **Sub-limit accuracy** — Deterministic rule: any dollar amount cited matches the policy file
* **Hedge language enforcement** — Output must include "this is informational, refer to your policy / contact a licensed agent" caveat for non-trivial coverage questions

## 4. Fraud detection and special-investigations referral

**Setup:** Model scores claims for fraud-investigation referral. Output: risk score 0-100, top three contributing factors, recommended action (close, investigate, refer to SIU).

**Why it's hard:**

* False positives drag legitimate claimants into invasive investigations and create complaint exposure
* False negatives cost the carrier directly
* Demographic disparity in referral rates is a regulator hot button

**Stakes:**

* Industry-wide P\&C fraud cost \~$80B annually; SIU efficiency drives loss-ratio meaningfully
* Disparate referral rates have been the subject of state DOI consent orders

**Stratix evaluation criteria:**

* **Precision at top decile** — Deterministic; tracks whether the high-score band matches confirmed-fraud rate
* **Recall on labeled known-fraud set** — Deterministic
* **Group-fairness scorer** — Referral rate ratio across demographic proxies
* **Reason-code coverage** — Hard rule: every referral must cite ≥ 3 contributing factors
* **Audit-trail completeness** — Every score logged with model version, feature inputs, threshold decision

## 5. Subrogation and recovery

**Setup:** AI assistant reads a claim file and identifies subrogation potential — the third party potentially liable for the loss the carrier just paid. Output includes liable-party identification, dollar-recovery estimate, statute-of-limitations deadline.

**Why it's hard:**

* Liability identification requires reading police reports, third-party policies, and jurisdictional law
* Statute-of-limitations errors directly bar recovery
* False-positive subrogation pursuits annoy customers and damage agency relationships

**Stakes:**

* Subrogation recovery typically returns 1-3% of P\&C loss expense — material to combined ratio
* Missed-deadline claims are unrecoverable and an E\&O exposure for the carrier

**Stratix evaluation criteria:**

* **Liability-party identification accuracy** — Judge scores against ground-truth liability findings
* **Statute-of-limitations rule** — Hard deterministic rule: every subrogation file must include the SoL date and jurisdiction
* **Recovery-estimate calibration** — Deterministic; estimated vs. actual recovery on closed files
* **Document-citation completeness** — Every liability claim must cite the supporting document section

## See also

* [Insurance eval patterns](/more-in-this-section-2/eval-patterns-5.md)
* [Insurance compliance](/more-in-this-section-2/compliance-5.md)
* [Concept: Judges](/8.-evaluate-score-the-outputs/judges-1.md)
* [Trace evaluations (SDK)](/more-in-this-section-9/trace-evaluations-1.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.layerlens.ai/more-in-this-section-2/scenarios-5.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.