What happens when a marketplace curator finds structural faults in a pilot sample?

A catalogue curator at a data marketplace receives pilot sample SAMP-0007 for a healthcare administration theme: prior authorisations approved with conditions, such as a referral letter or a clinical review before a procedure is scheduled.

The curator's review analyst runs the acceptance checks. Referential integrity fails: a subset of condition records reference a `decision_id` that does not exist in the decisions table. In another table, several releases list conditions that were created after the release time. The free-text fields read well, and the risk review finds no accidental matches to real organisations.

The curator does not list the sample. Instead the analyst writes a defect note referencing the failing check, the affected record identifiers such as COND-0412-03, and the expected behaviour. The note goes to MirrorFirm with a request for a corrected version and a statement of what changed.

When the corrected sample arrives under a new version identifier, the same checks run again. The listing proceeds only after they pass, and the listing text records the version and states that the data is generated.

**What it teaches:** a pilot should include a defect and correction loop. Fix the checks before the sample, and keep version labels so the catalogue and customers know what they hold.