What does a scoping conversation look like for an insurer premium desk pilot?

An environment lead at an AI lab is building a simulated insurer back office. They meet MirrorFirm with a premium accounts specialist role described in the brief, and record the outcome as PILOT-0091.

The brief fixes three task families: monthly instalments paid in a lump sum covering several months, duplicate direct-debit payments, and an overpayment that needs a refund request. It specifies one policy set, with a rounding tolerance and a refund approval limit by role. It lists the buyer's tools: `search_open_items`, `apply_allocation`, `hold_unapplied`, `request_refund` and `escalate`. The stop rule says to widen the scope only if graded failures can be explained in one line each.

The first sample is loaded into the buyer's staging store. Running task TASK-0207 twice gives different results. The cause is that `audit_log` rows from the first run persisted after `reset`, and the second run's grader counted them as unexplained writes.

**State change:** after the harness clears audit rows on reset, both runs yield identical graded results.

**Consequence:** the buyer learns this from a small sample instead of after ordering a larger release.

**What it teaches:** a pilot tests your harness as much as the material. Include reset and re-run checks in the plan from day one.