What does a scoping session for a first pilot look like in practice?

An evaluation lead at an insurance technology team wants to test agents on premium funding facilities, where an insurer-approved premium is financed over monthly instalments. They open scope record `SCOPE-0044` in `draft` with a broad ask: all product types, all exceptions, a full simulated environment.

In the session, a data engineer asks what the evaluation must decide. The lead lists three questions: does the agent notice an expired approval, does it detect a mismatch between the approved premium and the requested limit, and does it record a return reason that credit can act on.

The scope narrows accordingly: - one product, premium funding; - three exception families, plus a set of clean bookings as the control; - JSONL tables with a manifest, and a task file carrying expected dispositions; - a small reset-able environment with `get_approval`, `create_facility`, `hold_file` and `return_to_credit`; - evaluation use only, with holdout tasks kept out of anything shared for training.

The record moves to `agreed`. The first sample is reviewed for foreign key integrity, schedule reconciliation and label consistency before a larger set is discussed.

**What it teaches.** The pilot is defined by decisions the team needs to make. Narrow scope makes failures attributable and keeps the review manageable.