Testing BOM and placement consistency checks with synthetic faults
Disclosure: PCBA Partner operates the checkers discussed here. The examples use synthetic data. This is a bounded demonstration of selected checks, not an independent product evaluation or a production performance study.
What should a clean file check mean?
A bill of materials and a placement file can each be readable while describing different assembly instructions. One may contain a reference that the other omits. A component marked do not populate in the BOM may still have coordinates in the placement export. Both files can also share a mistake that a comparison between them will never reveal. These possibilities make the meaning of a clean check more important than the appearance of a clean screen.
This article describes a small, reproducible exercise for examining that boundary. It uses six synthetic CSV files to test five selected algorithm scenarios, followed by two checks through the public browser interface. The purpose is to distinguish input validation, cross-file comparison and engineering decisions. The exercise does not estimate defect rates, claim savings in preparation time or establish that any assembly is ready for manufacture.
The examples are intentionally small enough to inspect by hand. That makes the expected answer explicit: a reviewer can identify each populated reference, count the intended quantity and trace every inserted inconsistency without relying on the software output. Small examples are useful for demonstrating behavior, but their simplicity is also a limitation. They do not represent the range of naming practices, export formats or variant structures found in production work.
Establish the reference case before inserting faults
The reference BOM contains four rows. R1 and R2 share a row with quantity two and a synthetic resistor part number. C1 has quantity one and a synthetic capacitor part number. J1 is explicitly identified as through-hole. R3 is marked do not populate, with quantity zero. The component identifiers and part numbers are teaching data; they are not a purchasing specification.
The corresponding SMT placement file contains three rows: R1, R2 and C1. J1 is intentionally absent because the file represents SMT placement and the BOM identifies J1 as through-hole. R3 is absent because it is not to be populated. This is an important distinction when defining the expected result. A rule that simply requires every BOM reference to appear in every placement file would flag intentional omissions as discrepancies.
Coordinates are expressed in millimetres relative to a synthetic shared origin. The data includes a negative coordinate and a bottom-side component, but there is no physical board outline. The reference case therefore specifies enough information to exercise file checks without implying that the coordinate values have been validated against a real PCB. The placement angles are numerical inputs, not evidence of correct component orientation.
Before running the comparison, inspect the detected column mappings. A reference column must be interpreted as references, a quantity column as quantity, and the side and rotation columns as their respective fields. A readable CSV with an incorrect mapping can produce misleading results. Record any manual choices, including the selected unit, so that a second reviewer can repeat the same interpretation.
For this exact reference pair, the expected result is no findings within the demonstrated checks. The saved algorithm output reports an executed comparison with no issues. The browser exercise also reports zero errors, zero review findings and zero cross-file findings. Those observations establish the outcome for these inputs; they do not extend to untested files or properties.
Keep input errors separate from comparison results
The first altered BOM changes the quantity on the R1/R2 row from two to three while retaining the same two references. This introduces an inconsistency within one file. Detecting it does not require looking at placement coordinates. The expected response is a quantity mismatch and a blocked cross-file comparison until the BOM error is resolved.
The recorded algorithm result follows that expectation. It identifies quantity three against two listed references and reports the comparison state as blocked. The comparison issue list is empty, but that empty list must not be read as a successful comparison. State and findings need to be interpreted together: an operation that did not run cannot provide a clean comparison result.
This distinction matters when documenting a workflow or reviewing a report. Preserve whether a check was executed, blocked or not performed, rather than recording only the number of issues. If a user fixes the quantity, the corrected file should be checked again and compared against the intended placement revision. The existence of a previous blocked result says nothing about the corrected pair.
Insert disagreements that require both files
The next exercise keeps the reference BOM and replaces the placement file with a deliberately inconsistent version. R1 remains present. R2 is removed. C1 remains present, but its footprint text changes from C0603 to C0402. R3 is added despite its do-not-populate status. A new reference, U99, is also added even though it does not occur in the BOM.
These changes produce four distinct findings in the saved algorithm output. R2 receives a missing-placement warning. R3 receives a do-not-populate placement error. C1 receives a footprint-mismatch warning. U99 receives an absent-from-BOM error. The public browser exercise with the same pair reports two errors and two review findings, for four cross-file findings in total.
The distinction between errors and review findings should not be used as a substitute for understanding the underlying discrepancy. In this example, R2 is expected in the SMT file because the reference BOM identifies its mounting type. In a different file set, an omitted reference could reflect an intentional assembly process or variant decision. The useful follow-up is to establish which instruction is authoritative and whether the omission is intended.
The C1 finding has a different scope. It compares footprint text, not pad geometry. Different labels can refer to equivalent library definitions, while identical labels can hide different library revisions. Here, the deliberately changed text is detected. The exercise does not establish that the checker can determine whether two physical footprints are equivalent or suitable for the selected component.
Similarly, identifying U99 as absent from the BOM does not decide which document should change. It could be an unintended placement row, or the BOM could be incomplete. Resolving that question requires the intended assembly definition. The file checker supplies a discrepancy to investigate; it does not have independent knowledge of design intent.
Require a declared unit
Another placement example removes the unit declarations from the coordinate headers. The numerical values are unchanged. The initial algorithm result contains a file-level unit-required error and unit errors for the individual rows. The expected response is to request an explicit interpretation rather than infer a unit from the apparent size of the numbers.
For this synthetic exercise, selecting millimetres is justified by the written example specification. After that explicit choice, the recorded unit issues are cleared. This is a demonstration of a known input decision, not a recommendation to assume millimetres whenever a file lacks units. A real handoff needs a source for the unit declaration, such as the export settings or an agreed file specification.
Recording the selection is part of making the check reproducible. If the same unlabelled numbers are interpreted under different units, a clean result after selection can describe different physical positions. Removing an ambiguity in the software interface is therefore different from confirming that the chosen interpretation is correct for the board being assembled.
Normalize an angle without claiming orientation approval
The final algorithm example contains one bottom-side component at X equal to minus 12 millimetres and Y equal to 5 millimetres, with a rotation of minus 90 degrees. The saved result preserves X, Y and the Bottom side designation. It normalizes the numerical angle to 270 degrees and produces a warning to confirm the source rotation convention.
This behavior is narrow and inspectable. The checker does not mirror the bottom-side coordinate in this example. A reviewer can compare the original row with the normalized record and see exactly what changed. That record should not be described as a machine-ready orientation simply because the angle is now within a familiar numerical range.
A real orientation review needs the source and destination conventions: origin, axis direction, bottom-side viewing or mirroring, zero-angle definition and any package-specific machine offsets. Component polarity and pin-one references also require the relevant physical and assembly documentation. None of those relationships is established by converting minus 90 to 270. A plausible preview cannot replace the missing convention evidence.
Preserve the evidence needed to repeat the exercise
The algorithm record identifies the public shared core used for the exercise and its SHA-256 hash. It records five named scenarios, their expected distinctions and the observed structured output. Identifying the tested version matters because a later software revision may produce different messages or behavior. The saved result is evidence for the recorded run, not a claim about every future deployment.
The browser checks cover only the reference pair and the pair containing four cross-file disagreements. They add evidence that these two scenarios can be exercised through the public interface. They do not mean that all five algorithm scenarios were tested through every browser, device or file-selection path. Keeping those scopes separate prevents a small interface check from being presented as comprehensive application validation.
For review, retain the six input files unchanged alongside the result record and the instructions. If a reviewer changes a cell, save the changed example separately and state the new expected outcome before rerunning it. Otherwise, a demonstration can drift into adjusting inputs to match whatever the software happens to report. The expected result should remain independently explainable from the example specification.
A concise results table should name the input pair, whether comparison ran, the finding categories and the unresolved engineering questions. A simple pass label hides too much. In the quantity example, the correct result includes a blocked comparison. In the reference example, no findings is the expected software behavior, while physical suitability remains outside the exercise. Both can satisfy their stated expectations without providing the same kind of evidence.
Limits and a useful next study
The exercise uses five deliberately selected algorithm scenarios and two interface scenarios. The four inserted cross-file discrepancies are all reported for their particular inputs. That observation is not a detection-rate estimate. There is no representative production dataset, no independent set of naturally occurring faults and no evaluation of the prevalence of false alarms across varied engineering exports.
The files also omit many conditions that a broader validation study would need to define. Examples include multiple assembly variants, mixed export conventions, naming aliases and revision mismatches that preserve the same references. These are proposed areas for further study, not claims that the current checker supports or fails them. Each needs an explicit expected interpretation and a suitable test set before conclusions can be drawn.
A next study could build a separately reviewed dataset of real export structures using permissioned or synthetic content, with independent expected outcomes and documented exclusions. It should distinguish parser failures from semantic disagreements and record the amount of manual interpretation required. Any comparison of time or production outcomes would need its own measurement method, baseline and limitations; none is supplied by this exercise.
For the present demonstration, the conclusion is narrower. The selected inputs show a clean reference comparison, a quantity error that blocks comparison, four detected cross-file disagreements, a required unit declaration and a numerical angle normalization that preserves the bottom-side coordinates. These observations make the checks easier to inspect and discuss. Manufacturing release still depends on evidence and decisions that are not contained in the two files alone.
Repeat the exercise
Download the synthetic example files and recorded results (ZIP). Use the BOM checker and placement checker to inspect the examples. The package contains teaching data, not customer production files.
About the author
Chen Guman runs PCBA production in Dongguan for industrial IoT and monitoring hardware at PCBA Partner. His work focuses on build-package readiness, BOM risk, first-article requirements, test definitions and the handoff from prototypes to repeat production.