What does a scoped pilot look like for a marketplace adding an intake line?

A product manager at a data marketplace wants an intake line for freight forwarders. They ask MirrorFirm to scope a pilot: one domain, freight booking requests, delivered as Parquet tables and a small task pack.

Their written request covers four things: the entities (`booking_request`, `document`, `check_result`, `routing_decision`), three exception types (missing dangerous-goods declaration, duplicate booking, amended consignee), a policy file, and an acceptance test.

When the sample arrives, a data engineer loads the tables and runs the test. Booking `BKG-0763` has a dangerous-goods flag but no declaration, and the policy requires the case to be held in `compliance_review`. The record shows `compliance_review`, with a handover note from the booking clerk to the compliance officer. The state moves from `received` to `held`, then to `released` once the declaration arrives.

**Consequence:** the sample passes that check but fails another. Amended consignee cases carry no link to the original booking, so the engineer cannot reconstruct the amendment. The product manager records the defect, asks for a `parent_booking_id` field, and defers listing until a revised sample arrives.

**What it teaches:** a pilot works best with a written acceptance test tied to named exceptions. The outcome is a decision on what to list, what to change and what to drop, and each point is traceable to a record.