Skip to content
MirrorFirm

What does the starting state of a simulated claims-intake environment look like?

A storm-damage claim, CLM-0412, starts in a simulated insurance environment with policy, prior claim and routing data. The agent's actions change state and expose a routing trap.

A simulated environment for a general insurance claims team resets to CLM-0412, a storm-damage notification lodged by phone and typed into a free-text note by a contact-centre agent.

At reset the environment holds policy POL-88213 (active, with a roof-age condition), a closed earlier claim CLM-0377 at the same address, and a routing table with four queues: `property-standard`, `property-complex`, `fraud-review` and `catastrophe-event`. The date of loss falls inside a declared event window.

The intake agent calls `lookup_policy` and sees storm cover with the roof-age condition. It calls `search_claims` and finds CLM-0377, an earlier roof claim. It sets `prior_related_claim=CLM-0377`, and `check_completeness` returns `missing: photos, date_of_loss_confirmation`.

**State change.** Status moves from `lodged` to `awaiting-documents`, and a request is queued to the policyholder. The routing decision is flagged for `property-complex` because of the prior roof claim, not `catastrophe-event`, even though the event window matches.

**Consequence.** If the agent routes on the date alone, the environment records a misroute, and the assessor's handover later lacks the prior-claim link.

**What it teaches**

- The right action depends on environment state, not only the case text. - A record found by search can override the obvious routing cue. - Deferring a route while setting status correctly is itself a scoreable behaviour.

A simulated environment can make the correct action depend on records the agent must find, which tests investigation rather than recall.

Audience:
Evaluation teams
Content type:
Scenario
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Application intake