Reviewing DRC Exceptions Before a PCB Release

A design-rule report with no visible violations is meaningful only when the right rules were enabled and applied to the right objects. Review the rule configuration and intentional exceptions together. The objective is a defensible release decision, not simply an empty error list.

Confirm what was actually checked

Altium’s documentation distinguishes online checking from a batch DRC and recommends checking the routed board before generating final artwork. It also describes rules as scoped constraints. A check cannot evaluate a requirement that is absent, disabled, or assigned to the wrong objects. Altium: design-rule checking; Altium: design-rule types.

Record the board revision, rule set, enabled checks, and report date. Compare manufacturing constraints with the agreed supplier capabilities and electrical constraints with the design requirements. Inspect net classes and rule priorities where they determine which limit applies. A broad rule can be superseded by a more specific rule that was added months earlier.

Make exceptions local and explainable

• Identify the exact feature or objects involved.
• State the violated requirement and the reason for the exception.
• Attach relevant supplier or design-engineer approval.
• Define any compensating inspection or process requirement.
• Record when the exception must be revisited.

For example, one approved fine-pitch footprint may require a local manufacturing rule. Disabling the same check globally hides unrelated violations elsewhere. Use the narrowest appropriate scope and verify that it does not capture additional components unintentionally.

Review changes since the previous report

Late edits to planes, holes, outlines, footprints, or net assignments can invalidate an earlier result. Regenerate copper fills and perform the relevant final checks on the released design state. Resolve unconnected items by understanding their circuit purpose; do not dismiss them solely because the board appears fully routed.

Preserve the evidence

Keep the report, rule configuration, and exception register with the manufacturing outputs. If an exception depends on one fabricator’s process, reassess it before moving to another supplier. The report should make this dependency visible to someone who did not attend the design review.

DRC does not prove schematic correctness, analog performance, mechanical fit, or every manufacturing requirement. Use it as a controlled automated check within the broader release process. A small set of explained exceptions is more informative than a nominally clean report produced by suppressing the checks that would have found them.

Check that saved exclusions still refer to the intended features after annotation or footprint replacement. An exception that survives an unrelated design change deserves renewed review rather than automatic inheritance.