An empty schematic-to-PCB difference report can mean that the two representations agree, or that important difference types were excluded from comparison. Review the comparator configuration before using a clean report as release evidence. The report is meaningful only within the scope it actually examined.
Altium’s project-options documentation describes settings that select which differences are found and which are ignored. These settings can therefore influence the apparent synchronization state without changing either design document.
Define what agreement is required
List the information that must remain synchronized for the project: component identity, connectivity, selected parameters, classes, and other controlled properties. Some purely presentational differences may be intentional. Identify which document owns each controlled field so that synchronization resolves differences in the intended direction and does not overwrite authoritative information with an older local value. Record those separately from information that affects manufacturing or circuit behavior.
Inspect the comparison settings against that list. A setting inherited from a template or an earlier troubleshooting session may no longer match the current project’s release needs. Do not assume the default is appropriate merely because no one remembers changing it.
Use a deliberate difference to validate coverage
In a controlled copy, introduce a known change in a property that must be compared. Run the comparison and confirm the change appears with the expected object identity. Restore the copy afterward; the validation change should never become an accidental design update.
| Information category | Question |
|---|---|
| Components | Are additions, removals, and identity changes visible? |
| Nets | Are required connectivity differences included? |
| Parameters | Which controlled fields are compared? |
| Classes and structure | Are rule-driving associations covered? |
Review exclusions as engineering decisions
For each ignored category, explain why exclusion is acceptable and which alternative check covers any remaining consequence. An ignored property should not be described as verified by the comparator. If no check exists, resolve the gap before release.
Inspect proposed engineering changes before applying them. Turning comparison back on may expose accumulated differences, and accepting the entire list without review can overwrite intentional layout information. Resolve object identity and change direction first.
After the intended updates, rerun the comparison using the approved settings and retain both the report and configuration. A later reviewer needs to know what the clean result covered, especially if the project’s settings change over time.
This review turns “no differences” into a bounded statement that can be trusted. It establishes agreement for the selected controlled information while making deliberate exclusions visible and accountable.
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