Check Which Rules Actually Ran Before Accepting a Clean DRC Report

A clean design-rule report means little if the relevant checks were disabled or scoped away from the objects of interest. Before accepting zero violations as release evidence, verify the rules and check modes that actually ran. Coverage is a prerequisite for interpreting the result.

Altium’s DRC documentation distinguishes online and batch checking and states that checks operate against enabled rules. A quiet interactive editor is therefore not a substitute for a defined release check with known configuration.

Start from the design requirements

List the rule families needed for this board, based on its electrical, fabrication, and assembly constraints. Identify the source of their values. A default project configuration may not contain the specific checks needed for a new technology or supplier requirement.

Inspect both rule enablement and execution settings. A rule may exist with the intended value but not participate in the selected check mode. Record exceptions separately from disabled checks so that a deliberate waiver does not become a hidden loss of coverage. Include the reason and affected objects for each exception; disabling an entire rule to silence one accepted condition can hide unrelated violations elsewhere on the board.

Review coverage dimensions

Use a controlled negative example to confirm a critical check when practical. In a disposable copy, create a known violation and verify that the intended rule reports it. Restore the original design and run the final check again. This validates coverage more directly than reading a settings screenshot alone.

Capture the final check context

1. Confirm current copper and design data.
2. Run the agreed batch check configuration.
3. Review violations and documented exceptions.
4. Save the report with the design and rule-set identities.
5. Generate outputs from the reviewed state.

Revisit coverage when importing rules, migrating CAD workflows, or copying a project template. These operations can preserve familiar rule names while altering scopes or enablement. Compare configuration meaning rather than only counting how many rules exist.

Do not claim that DRC proves every aspect of manufacturability or circuit function. It evaluates the checks represented in the configured tool. The release record should state that boundary while still providing strong evidence that the required represented constraints were actually exercised. The rule scope control guide develops the targeted verification method for individual constraints.