Design Rules in Siemens NX: The Short Version
Company design rules in Siemens NX become enforceable when they run as checks instead of living in a guideline: naming, layers, model structure, geometry limits, PMI standards, drawing templates and attributes. NX offers Check-Mate for custom checkers; DOCUFY CAx Quality Manager offers configurable checking processes. inteliScience, an official DOCUFY partner, encodes the rules and wires them into the release.
| Written rule (guideline PDF) | Executable rule (check) |
|---|---|
| “Expressions must be named meaningfully” | Expression name matches p_<feature>_<quantity>, unreferenced expressions flagged |
| “Use the company layer standard” | Solids on 1, sketches on 21, datums on 61, PMI on 101; anything else flagged |
| “Fill in the material” | Attribute MATERIAL present, value from the approved list |
| “Follow the datum strategy for housings” | Part class housing: datums A, B, C exist and are attached to the faces the standard names |
| “Use standard parts from the library” | Fasteners not from the reuse library flagged |
| “Drawings on A3 or A2 with the current template” | Sheet size in {A3, A2}, template revision current, title block filled from attributes |
The Problem: Standards Exist, Enforcement Depends on People
Most engineering organizations on Siemens NX have a design guideline. It was written by a senior designer, approved by methods, stored on the intranet and read in the first week of onboarding. From then on, compliance depends on memory, habit and the one reviewer who knows the document by heart. When that reviewer is on holiday, the rules are on holiday.
The symptoms are familiar: attributes filled differently by every team, layer usage that drifts per project, three naming conventions for the same feature, PMI that follows the standard on new parts and not on modified old ones, drawings whose title block says one thing and whose attributes say another. Nobody broke the rules on purpose. The rules were never executable.
Written Rules vs Executable Rules
A written rule describes intent for a human reader. An executable rule is a test with a defined scope, a condition and a result. The difference is precision: “name expressions meaningfully” cannot be checked; “expression names match the pattern and every expression is referenced” can. Converting the first into the second is the real work of automating design rules, and it forces a useful conversation. Some rules turn out to be two rules, some turn out to be preferences, and some turn out to have exceptions nobody had written down.
Our clear recommendation: convert the guideline rule by rule into a catalogue with four columns, the rule text, the executable condition, the severity (information, warning, error) and the owner. Every rule that cannot be filled in is a rule that will be discussed, not checked.
Which Requirements Can Be Automated?
Almost every rule that describes the CAD data can be automated. Rules that describe design intent cannot.
| Can be checked automatically | Requires human judgement |
|---|---|
| Naming patterns for parts, features, expressions, components | Whether a name is descriptive |
| Layer assignment per object type | Whether a construction sketch is still needed |
| Attribute presence, format and allowed values | Whether the material is the right choice |
| Feature order rules, suppressed features, unused sketches, broken links | Whether the modelling approach is sensible |
| Geometry thresholds: minimum wall, face size, body count, sliver faces | Whether a wall thickness suits the load case |
| PMI completeness: tolerance, datum reference, attachment, semantic type | Whether the tolerance is right |
| Drawing template, sheet size, view currency, title block from attributes | Whether the views communicate the part |
| Standard parts from the reuse library | Whether a custom part is justified |
The right-hand column is not a limitation of the tools. It is the reason engineers exist.
Encoding the Six Rule Families
Naming conventions
Naming rules are regular expressions plus a scope: part numbers, component names, feature names, expression names, dataset names. In Check-Mate a naming rule is a custom checker; in DOCUFY DQM it is a configured check. Either way, decide first which objects the rule applies to and what happens to legacy objects that predate the rule, or the first batch run will flag every part in the vault.
Layers
A layer rule maps object types to layer categories from the company template. It is the most mechanical rule family and the most rewarding to automate, because layer errors are invisible to their author and disruptive to drafting, exchange and viewers. Healing applies here: moving an object to the correct layer is a deterministic correction.
Model structure
Structure rules cover unused sketches, datums and expressions, suppressed features in released parts, WAVE link status, reference sets, and feature counts or orders where a template prescribes them. These rules protect the next engineer who changes the part; they are the difference between a model that can be modified and one that must be rebuilt.
Geometry
Geometry rules are thresholds and integrity checks: closed solids, no sliver faces below a limit, no self-intersections, minimum wall thickness per material class, allowed body count. Thresholds must come from manufacturing, not from methods alone; a minimum wall rule that CAM did not agree to will be ignored.
PMI
PMI rules are the fastest-growing family as organizations move toward model-based definition: every feature control frame has a tolerance and a datum reference, datums exist and are attached to faces, model views are organized per the MBD template, no orphan annotations, view counts within limits. DQM 2026.1 added PMI view validation with attribute correction and PMI view count limits [1]; Check-Mate’s standard library includes PMI checks [2].
Drawings
Drawing rules verify template and sheet size, view currency, title-block values derived from attributes, standard notes and view alignment. The rule that saves the most rework is the simplest: no released drawing with an out-of-date view.
Attributes
Attribute rules are usually the first family to go live because ERP and Teamcenter depend on them: required attributes present, values from lists, formats correct, consistency between part and drawing. They are also the family with the highest share of automatic healing, since filling a default or reformatting a value is deterministic.
Repeatable Validation: Interactive, at Save, in Batch
A rule that is checked once is a review. A rule that is checked every time is a standard. Three execution modes cover the lifecycle: interactive checks while the designer works, checks at save or check-in that stop non-compliant data from entering Teamcenter, and batch runs over the vault that measure compliance and catch legacy data. Check-Mate runs interactively or in batch mode [2]; DOCUFY positions DQM’s batch processing for large data volumes and standards roll-outs [3]. The baseline batch run before a rule goes live is not optional; it is how you learn whether the rule is realistic.
How Company-Specific Checking Fits Into DQM
DOCUFY CAx Quality Manager ships with more than 450 standardized and configurable best-practice checks and states that checking processes can be adapted to individual requirements, including company guidelines, engineering standards and design rules [3]. In practice the rule catalogue from the section above is mapped onto the configurable checks; the ones that can be expressed as configuration go live quickly, and findings are shown inside NX with guided correction instructions or, for supported checks, automated healing. Rules that fall outside the configurable range remain custom work, in Check-Mate custom checkers or NX Open, and we say so during the assessment rather than after the licence.
The alternative route, Check-Mate custom checkers written in Knowledge Fusion or NX Open, gives complete freedom and requires a developer who owns the checkers through every NX release. We compared the two operating models in our article on DOCUFY DQM versus Siemens NX Check-Mate; our DOCUFY CAx Quality Manager page describes the product and the evaluation package.
Your standards, as checks that run on every part. As a DOCUFY partner we convert the guideline into an executable rule catalogue, configure the checks, run the baseline over your vault and wire the results into your Teamcenter release. Turn your engineering standards into repeatable Siemens NX quality checks
Where Vision4NX Fits
Vision4NX technology from inteliScience is integrated into DQM. In a design-rule workflow it explains a finding in the words of the standard it comes from and gives the engineer the context to decide about an exception; the check itself stays deterministic, and Vision4NX neither writes rules nor waives them.
Roll-Out Considerations
- Start with the family that fails most and heals easiest. Attributes and layers, almost always.
- Baseline before gate. Batch run over the vault, publish the failure rate, fix the rule text where the rate says the rule is unrealistic.
- Severity discipline. Errors block, warnings inform. A rule with ten thousand warnings is noise.
- Owners and versions. Every rule has an owner in methods or quality; the catalogue and the configuration are versioned like the NX template.
- Gate in Teamcenter. Check results as release conditions, not as emails. DQM writes results to Item Revisions and the Validation Master Form since 2026.1 [1]; Check-Mate results can be saved to Teamcenter [2].
- Legacy strategy. Decide explicitly whether legacy parts are exempt, healed in batch or fixed on touch.
For the step from rule catalogue to working check, read our guide to Check-Mate customization. If you want it done for you, see custom NX quality checks.
Frequently Asked Questions
How do you automate design rules in Siemens NX?
Convert each written rule into an executable condition with scope, severity and owner, then implement it as a Check-Mate custom checker or as a configured check in DOCUFY CAx Quality Manager. Run the checks interactively, at save and in batch, and make the result a release condition in Teamcenter.
Which design rules can be checked automatically in NX?
Naming patterns, layer assignment, attribute presence and format, model structure (unused sketches, suppressed features, broken links), geometry thresholds, PMI completeness and drawing template rules. Rules about design intent, such as whether a tolerance is right, remain with the engineer.
Check-Mate custom checkers vs DQM configured checks: which is better for company rules?
Custom checkers give complete freedom and need a developer who maintains them through NX releases. Configured DQM checks are faster to stand up and easier to hand over to methods, within the range the configurable checks can express. Many organizations use both.
How much effort is a design-rule automation project?
The catalogue work dominates: converting a typical guideline of 30 to 80 rules into executable conditions takes days of methods time. Configuration and the baseline batch run follow within weeks. DOCUFY’s 90-day evaluation package includes customizing and consultant support, which is where this work usually happens.
Can automated checks fix the deviations they find?
For deterministic corrections such as layers, attribute defaults and formats, DQM provides automated healing for supported checks; other findings come with guided correction instructions. Check-Mate reports the finding and leaves the correction to the engineer or to automation you build.
Next Step
Related Topics
- Siemens NX CAD quality: how to automate model validation
- DOCUFY CAx Quality Manager for Siemens NX
- The Siemens NX CAD Quality Playbook (whitepaper)
References
- DOCUFY GmbH, “NX-Datenqualität sichern: Neue Version des DOCUFY CAx Quality Managers” (DQM 2026.1), 30 March 2026.
- Siemens, “CAD model design validation,” Designcenter NX product page, and “NX Check-Mate / NX Quick Check” fact sheet.
- DOCUFY GmbH, “DOCUFY CAx Quality Manager,” product page.