Keep identical sample codes from different reports distinct

A sample code may be local to a report

Keep the report identity with each observation so a familiar code does not create a false match in your register.

Our public material-register example shows a synthetic report beside downloadable output. Use it to inspect how values and source references travel together. The self-service ParseMill trial is for invoice PDFs; supplier test reports and engineering review need a separate fit discussion.

A proposed relationship between samples in different reports requires evidence such as an explicit shared batch or cross-reference. Similar codes, dates or results alone do not establish that they are the same physical sample.

Use a composite-identity fixture

The keys are synthetic internal labels. The third record may supersede the first, but it should not overwrite it until the report’s revision relationship is established. Retain both versions and the decision about which is current for the intended use.

W3C: Provenance model primer distinguishes entities and revision or derivation relationships. Use that separation to preserve both source identity and any later relationship between records.

Check identity before joining

1. Record issuer, report number, revision, source-file identity and reported sample code. Preserve missing identity components as unresolved.
2. Create a stable internal key that distinguishes source records without claiming physical sample equivalence. Check for accidental key collisions.
3. Before joining across reports, document the source evidence for the proposed relationship and its scope. Keep uncertain matches in a review queue.
4. Verify the joined result for unexpected multiplication or loss of rows. Retain original keys so every combined record can be traced back.

Microsoft: Table.Distinct compares selected columns when removing duplicates. A sample-code-only criterion can remove legitimate records from different reports, so use reviewed identity criteria.

Handle revisions and duplicate copies differently

A duplicate PDF copy may contain the same report and observations, while a revised report may change results or notes. Compare report identity and content before deciding whether to deduplicate, supersede or retain both. Record the reason and keep the removed-copy relationship if a duplicate is excluded from the working view.

Do not make a composite key from mutable row positions alone. Sorting or inserting records can change those positions. Preserve stable source identity and a source locator separately from display order. If a key must change, retain an old-to-new mapping so existing evidence references can be repaired explicitly.

Verify the register keeps the distinction

The fixture passes when both A-v1:S01 and B-v1:S01 remain distinct and A-v2:S01 has an explicit revision status. No join should silently collapse the records because their visible sample code matches.

Include repeated sample codes in the requirements for a supplier-report pilot. Agree how report identities and revisions would remain distinct, then check the resulting register against the source. This is a separate fit assessment from the self-service invoice trial.