What does a reseller's quality check on an intake sample look like in practice?

A data product analyst at a reseller receives a sample of utility connection request cases, coded `CONN-0001` onward, from a pilot release. Before listing, they run three scripts.

The first checks state transitions. All cases pass. The second joins `routing_decision.rule_id` to the policy file and compares the queue the policy would assign with the queue recorded. Case `CONN-0318` is recorded as `standard_connections`, but rule `R-VUL-03` requires `priority_support` when a medical-dependency flag is set. The flag is set.

The analyst checks the `override_by_role` field. It is empty, so this is not a supervisor override. They log a defect, move the batch from `candidate` to `held`, and send the case, rule and field values back to MirrorFirm with a request for an explanation.

**Consequence:** the reseller does not list the sample until the defect is explained or corrected. Had the field shown a supervisor override with a note, the case would have been retained as a deliberate exception and tagged for buyers.

**What it teaches:** a conformance join between decisions and policy rules is a cheap, high-value check. It separates deliberate exceptions from errors only if the data records overrides explicitly, so ask for that field in scoping. Keep the defect log as evidence of what you checked before onward licensing.