A rule expression containing a bare number may look obvious to its author and still be interpreted in a different unit system. Make physical quantities explicit and verify the expression against known board objects. A syntactically valid expression can select the wrong population without producing a parser error.
Separate displayed units from expression units
KiCad 9’s custom-rule documentation states that expression units are independent of editor display units. It describes explicit suffixes and internal representations for dimensional properties. Consult the particular property’s definition rather than assuming that every number means millimeters.
Distinguish distances, angles, counts, ratios, and text values in the expression. A layer count should not acquire a distance suffix, while a physical clearance should not depend on an unexplained bare value. Record the intended quantity in a nearby human-readable rule description.
Test both sides of the condition
- Select a known object that should match the rule.
- Select a similar object that should not match.
- Inspect their actual properties in the native design.
- Evaluate the expression or use the relevant rule-inspection tool.
- Check the resulting constraint on the selected objects.
Include boundary cases when the rule uses greater-than, less-than, or equality comparisons. The positive and negative scope check provides the broader method. Here the specific concern is whether a dimensional expression means what the engineer intended.
Review conversions deliberately
For example, a rule copied from an inch-based design may contain a value intended as mils. Changing the board display to millimeters does not prove that the copied expression has been converted. Rewrite the quantity with explicit units and compare the resulting selection and constraint. Preserve meaningful precision without adding digits that imply unsupported manufacturing accuracy.
When a rule combines arithmetic and physical values, evaluate a simple known example by hand. Also check whether the expression compares a diameter, radius, width, or some other property. Correct units cannot repair a comparison against the wrong geometric definition.
Use the constraint-migration review when moving rules between systems. Translate the intent first, then test the destination syntax and property model. Archive the verified rule with representative objects or screenshots so a future reviewer can understand the decision without reverse-engineering the author’s assumptions.
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