A data join can multiply test readings without changing their values. If a board identifier appears several times in both input tables, the result may contain every matching combination. An average or defect count calculated afterward can be wrong even though every individual value looks legitimate.

The pandas merge documentation provides relationship validation and row-origin indicators. These features help check expected join structure. They do not decide which business key correctly identifies a board, test attempt, or material record.

Define the intended relationship

State whether the join should be one-to-one, many test steps to one attempt, or many boards to one build. Write down the complete key for each side. A serial number may need a product or site namespace, and a repeated test needs an attempt identifier. Check how missing keys are treated by the selected library or database, because two absent identifiers must not become an assumed match between unrelated records.

Check key uniqueness before joining. If a supposed master table has two rows for the same key, determine whether they are duplicates, historical revisions, or legitimate separate records. Selecting the first row arbitrarily hides that unresolved distinction.

Reconcile input and output populations

Check Problem it detects
Rows per key on each side Unexpected multiplicity
Unmatched keys Lost or incomplete associations
Output row count Expansion or reduction caused by the join
Representative joined records Semantically wrong but syntactically matching keys

Use an indicator or explicit unmatched report during review. An inner join can quietly discard boards with no matching build record. A left join preserves those test rows but still requires the missing association to be resolved or reported.

Handle history explicitly

  1. Choose the applicable revision or effective period.
  2. Validate the expected key relationship.
  3. Perform the join with explicit key fields.
  4. Review unmatched and multiply matched records.
  5. Compare counts before calculating summary metrics.

If a material table records changes over time, the current value may not describe an earlier build. Use the actual build association or an appropriate historical key. A join on today’s part alias can attach a newly approved alternate to boards manufactured before that alternate existed.

Test the pipeline with a deliberate duplicate key and an unmatched board. Confirm that both conditions become visible rather than producing a plausible report. Keep the join policy and source dataset identities with the analysis so another reviewer can reconstruct how a measurement acquired its lot, variant, and component context.

Move from reading to a build-ready project

Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.

Open the DFM checklist