What acceptance checks should we run on a sufficiency sample?

Run these checks on every sample before you agree to list or license a release onward.

- Re-derive the outcome for a hand-picked set of cases from policy and documents alone. - Confirm every foreign key resolves: cases, documents, rules, gaps, requests. - Confirm each request names every open gap and nothing extra. - Read the borderline cases, such as near-recent documents and near-matching names. - Count outcome classes and defect types, and flag any class that dominates. - Check that request wording varies in form and is not a single template. - Scan identifiers and free text for specificity that could point to a real source. - Validate every file against the supplied schema, and note optional fields that are empty.

Record the result of each check with the release version. If a check fails, send the supplier the case identifiers, not a general complaint.

Set your pass criteria in advance and write them down. Agreeing thresholds after you see the data makes it easy to rationalise problems.

Remember the output is generated. Passing these checks says the data is internally sound, not that it carries no disclosure risk.