What does a scoped pilot look like for a data marketplace?

A data marketplace's catalogue lead wants a mismatch offering for freight customers. Together with a MirrorFirm contact, they scope a pilot on one domain: freight invoices against proof-of-delivery records.

The request lists three record pairs: carrier invoice with delivery confirmation, invoice with rate card, and consignment manifest with received quantity. It names four causes: duplicate invoice, wrong rate tier, short delivery and late scan. It asks for a training partition and a separate evaluation partition, plus policy text covering dispute thresholds and who can approve credits.

The pilot sample arrives as JSONL with a schema file. The catalogue lead's reviewer picks cases such as **INV-7712**, where the invoice bills 24 pallets but the delivery record shows 22. The reviewer solves it by hand, confirms the cause label of short delivery, and checks that the expected action, a credit request to the carrier, is allowed by the attached policy.

The reviewer also finds one case where the evidence note names the answer too directly. That is logged as a leakage defect, and the next iteration changes the note wording.

The state change is that the pilot moves from sample review to a decision on whether to list. Skipping this step would risk a listing whose labels or licence flags later need correction across customers.

**What it teaches:** a pilot should test the data, the schema and the licence fit together, using a narrow slice.