What does scoping a first pilot look like for an evaluation team?

A model lab's evaluation lead wants to test agents on approvals before expanding. They agree with MirrorFirm to scope a pilot in healthcare administration: payments to locum doctors for a clinic group.

The pilot specification, `PILOT-0009`, names three authority dimensions: payment amount, whether the locum is on the credentialed panel, and the approving role. The practice manager can approve panel payments up to $8,000. The finance manager can approve up to $25,000. Any payment to a locum not on the panel needs the medical director as well, whatever the amount. The specification asks for two policy versions, one of which moves the practice manager's limit, and a held-out split using a second clinic group's structure.

The first sample arrives as linked tables and a small batch of tasks. The evaluation engineer recomputes the labels and finds them consistent. But few requests sit near the practice manager's limit, and no delegation lapses mid-case. The engineer asks for regeneration weighted toward those cases, and for the policy change to fall between submission and approval on some tasks.

The consequence is a second sample that exercises the boundaries the lab cares about, plus a written scope that records what the pilot does and does not cover.

**What it teaches** - A pilot should name its authority dimensions and exceptions up front. - First samples are for finding gaps in coverage, not for confirming the plan. - The scope document is a deliverable in its own right.