What does a scoping session for an approvals pilot produce?

A team building a hospital administration environment books a scoping session with MirrorFirm. The attendees are the environment lead, an evaluation engineer and a product owner. Their agents will handle purchase approvals for a ward supplies budget.

The session works through the decisions that shape the pilot, and the outputs are recorded as a scoping note `SCOPE-0021`:

- **Domain slice:** consumables and equipment purchases, excluding clinical credentialing. - **Authority patterns:** amount tiers for ward managers, divisional directors and the finance committee; a higher tier for equipment over a set value; acting arrangements during leave. - **Traps:** a split order, an expired delegation and a requester approving a purchase they raised. - **Outputs:** a snapshot of organisation state, a first set of task definitions in JSONL, validity labels held separately, and reference outcomes. - **Interface:** `get_request`, `get_authority`, `approve`, `reject`, `escalate`, with a reset call keyed by `snapshot_id`.

The evaluation engineer asks for a held-out set that shares the organisation state but uses different amounts and delegation dates. The product owner asks that the sample be licensed for internal evaluation first, with training use decided afterwards.

After the session, the note lists open questions: how closely should the generated ward structure resemble the team's own hospital, and who reviews that resemblance for disclosure risk?

**What it teaches:**

- A scoping note turns vague wishes into checkable deliverables. - Evaluation and training uses can be licensed in stages. - Resemblance to a real organisation is a question to ask early.