Custom NX Quality Checks
Custom NX Quality Checks: Your Design Rules, Checked on Every Part
Custom NX quality checks turn the rules in your design guideline into tests that Siemens NX runs on every part, assembly and drawing. We build them where they fit your setup: as Check-Mate checkers, as standalone NXOpen checks or as configured rules in DOCUFY DQM. And we tell you before the project which of your rules should stay with an engineer.
Short answer
Custom NX quality checks are company-specific tests that check Siemens NX parts, assemblies and drawings against your own written design rules and modeling standards, such as naming, layers, attributes, model structure, geometry limits, PMI and drawing templates, and report every deviation the same way on every part. In Siemens NX they can be built as Check-Mate checkers in Knowledge Fusion or NX Open, as standalone NXOpen programs, or as configured checks in DOCUFY CAx Quality Manager (DQM).
inteliScience, a Siemens NX, NXOpen and Teamcenter specialist delivering nearshore from Romania and an official DOCUFY partner, does the whole job: rule analysis, check development, tests on your real parts, batch runs over existing data, reporting into your release process, and maintenance across NX releases.
This page is about turning your own rules into custom NX quality checks. Which platform to run them in is compared in DOCUFY DQM versus Siemens NX Check-Mate; the DQM product itself is on our DOCUFY CAx Quality Manager page; the method of turning a written guideline into executable rules is explained in how to check company design rules in Siemens NX, and writing checkers for Siemens’ own framework in Check-Mate customization. The service belongs to our NX workflow automation services.
Custom NX quality checks: the short version
- What they are: your written rules as executable tests, each with a scope, a condition, a severity and an owner, run in NX on parts, assemblies and drawings.
- Where they run: as Check-Mate checkers, as standalone NXOpen checks or as configured checks in DOCUFY DQM, often as a mix, decided per rule rather than per company.
- What we deliver: rule analysis, check development, false-positive tests on your real parts, a batch baseline over existing data, reporting, and maintenance across NX releases.
- What stays human: design intent. Whether a tolerance, a datum strategy or a wall thickness is right is an engineering decision; a check enforces a rule, it does not make that decision.
- What it is not: a new quality product, a replacement for Check-Mate or DQM, or an AI that invents rules.
Three places a company check can live in Siemens NX
Most organizations do not need one tool for all their rules. The question is asked per rule: which platform expresses it cleanly, and who will maintain it. We build on all three and stay neutral between them.
| Route | How a rule is built | Best at | Who maintains it |
|---|---|---|---|
| Check-Mate checker | A custom checking function, traditionally in Knowledge Fusion and since 2021 also in NX Open, run interactively or in batch; results shown with HD3D and savable to Teamcenter | Teams that already run Check-Mate profiles, and rules with geometry-heavy or application-specific logic | Your NX developers or CAD administrators, with our support across NX releases |
| Standalone NXOpen check | An NXOpen program that reads parts, assemblies or drawings and writes a report, on the open part or in batch, outside the Check-Mate framework | Rules that span several files, such as part and drawing consistency, or that need data from outside NX, such as an approved material list | Your developers, with us available for changes |
| DOCUFY DQM configured check | A configuration of DQM’s more than 450 standardized, configurable checks, set up per company guideline, with healing for supported checks and batch processing | Long catalogs of attribute, layer, structure, drawing and PMI rules, owned by methods or quality rather than by developers | Your methods or quality team, with DOCUFY as product vendor and us as partner |
Our rule of thumb is the one from our comparison article. If DQM’s configurable checks can express a rule, configuration is usually the easier path to maintain. If a rule needs arbitrary geometry logic or application-specific behavior, it becomes a Check-Mate checker or NXOpen code, whichever tool you run. And a Check-Mate profile that works and is maintained should not be replaced by a second tool. Siemens describes Check-Mate as a library of hundreds of standard checks plus an authoring tool for custom checking functions (Siemens, CAD model design validation), and its 2021 update added custom checkers in NX Open, with all checker results available in HD3D and savable to Teamcenter (Siemens Designcenter blog, 25 August 2021). DOCUFY’s release note for DQM 2026.1, published on 30 March 2026, lists support for NX versions up to NX 2512 and writing properties to Teamcenter Item Revisions (DOCUFY, DQM 2026.1).
What the custom check service covers
Generic criteria for CAD data already exist. VDA 4955 covers the scope and quality of CAD/CAM data, the SASIG product data quality guideline is published as ISO/PAS 26183, and both Check-Mate and DQM ship standard checks for geometry. Custom checks are for what no public standard knows: your naming convention, your layer template, your material list, your datum strategy per part class, your drawing templates.
Which rules are checkable
Your guideline, rule by rule: the text, the executable condition, the scope, the severity and the owner. Rules that need judgement are listed as such, not forced into a check.
Checks on your platform
Check-Mate checkers, NXOpen checks or DQM configuration, each tied to the rule it implements, so every finding can be traced back to your guideline.
Tested on real parts
Every check runs against known-good and known-bad parts from your data before release, so false positives show up in testing, not on your designers’ desks.
Run on existing data
The finished checks run in batch over existing parts and drawings, so you know how many fail each rule before anyone switches on a gate.
Results where people act
In NX for the designer, as a report per rule for methods, and where you want it, as a condition in your Teamcenter release workflow.
Maintained across NX releases
Before an NX upgrade, the checks run against the new release on the same test set.
How a custom check project runs
Take one written rule: every part carries a material attribute from the approved list. Each rule goes the same way, from the guideline to a check that runs in production.
// Custom NX quality checks: one written rule, one tested check
The rule text
What the guideline says, plus the exceptions that only exist in the heads of senior designers.
Scope, test, severity
Which objects, which condition, information, warning or error, and who may change the rule.
Built and tested
Check-Mate, NXOpen or DQM, tested on your known-good and known-bad parts.
Baseline, then gate
A batch run shows the failure rate; the rule goes live as a warning, then as an error.
A check is only as good as the condition behind it. “Name expressions meaningfully” cannot be checked; “expression names match the pattern and every expression is referenced” can. Most of the work is that translation, and it is done with your methods team, not by us alone.
- Read the rule. What it says, which objects it applies to, and which exceptions exist that nobody wrote down. Some rules turn out to be two rules; some turn out to be preferences.
- Write the condition. The rule becomes a testable condition with a scope, a severity (information, warning or error) and an owner.
- Choose where it lives. Check-Mate, NXOpen or DQM, depending on what expresses the rule cleanly and what you already run.
- Build and test. The check runs against your known-good and known-bad parts until it flags exactly the cases it should.
- Baseline. A batch run over existing data shows how many parts fail and whether the rule as written is realistic.
- Go live. First as a warning; once the failure rate is understood and the correction path is clear, as an error or a release condition.
Where custom checks go wrong, and the safeguards we build in
A checker that flags too much gets switched off. A checker that quietly stops working after an upgrade is worse, because people still trust it. These are the failure modes we design against from the first rule.
| Risk | What happens | Safeguard |
|---|---|---|
| False positives | The check flags parts that are fine: an old template, a purchased part, a justified exception. Designers learn to ignore it. | Known-good test parts, scope and exceptions written into the condition, new checks start as warnings, and every false positive from the pilot becomes a test case |
| Rule drift | The guideline changes and the check does not, or the other way round. The check enforces a rule nobody agreed to. | Each check names the rule and revision it implements; catalog and code or configuration are versioned together, with an owner per rule |
| NX release changes | A new NX release changes API behavior or deprecates a call. A checker fails, or worse, passes everything. | A regression set of parts with expected results; before an upgrade, the checks run against the new release in a test environment and must reproduce them |
| Legacy flood | The first batch run flags most of the vault, because the rule is newer than the data. | Baseline before gate, and an explicit decision per rule: legacy parts exempt, corrected in batch where the platform supports it, or fixed when touched |
| Unchecked looks like passed | A check that cannot evaluate an unusual part reports nothing, and nothing reads as a pass. | “Could not check” reported as its own result where the platform allows, and a run report that lists which parts each rule actually evaluated |
NX release changes deserve a separate word. Checkers written years ago in Knowledge Fusion or early NXOpen, whose authors have left, can be the reason an NX upgrade gets postponed. Documenting and porting them to supported NXOpen APIs, under version control and tests, is the work of our NXOpen legacy code modernization service, and it is often the first step before new checks are added.
Custom NX quality checks and their neighbors on this site
CAD quality touches several of our pages. They cover different steps of the same process; the broader picture is in our guide to Siemens NX CAD quality.
| Page | Step | What it answers |
|---|---|---|
| DOCUFY CAx Quality Manager | Product | What DQM checks out of the box, healing for supported checks, and how an evaluation works |
| DQM vs Check-Mate | Platform decision | Which platform fits your rules, your team and your correction process |
| Company design rules in NX | Method | How a written guideline becomes an executable rule catalog |
| Live Model Check Assistant | Checks while modeling | How a designer sees a rule violation at modeling time, in the words of the rule, with a suggested fix |
| MBD/PMI compliance automation | PMI checks at release | How PMI is checked against customer MBD specifications and works standards before release |
| NXOpen development | Tools beyond checking | Custom NXOpen tools for modeling, assembly validation and integration with other systems |
| Agentic CAD for Siemens NX | AI agents in NX | How a reviewer agent checks an AI’s work against your rules; existing checkers can become its tools |
| Custom NX quality checks (this page) | Your rules as checks | Rule analysis, check development, tests, batch baseline and maintenance, on Check-Mate, NXOpen or DQM |
What this service does not do
Checks enforce rules. They do not decide what a good part is, and they do not replace the quality tools you already own.
Good fit for custom checks
- A written design guideline, or senior designers who can say what it should contain
- Review findings your reviewers write by hand again and again
- A Check-Mate profile, NXOpen code or DQM installation that needs your company rules added
- Existing parts and drawings that have to be brought to a new standard
Limits we state up front
- No design intent: whether a tolerance, a datum strategy or a material is right stays with engineers
- No invented rules: every check implements a rule your methods owner has signed off
- No second tool where a working, maintained Check-Mate profile already does the job
- Automatic correction only where the platform supports it and the fix is deterministic, such as a layer or an attribute format
- A check result can be a release condition; the release itself stays a person’s decision
For checks that run while a designer models, with the finding phrased in the words of your rule, the event-driven live model check assistant is the better pattern, and Check-Mate checks or NXOpen validations you already own can feed it.
Deployment, data and ownership
Custom checks run inside your Siemens NX installation: on the designer’s workstation for interactive checks, and on a machine you provide for batch runs. Part files do not have to leave your network: development and tests can run on a workstation or VDI you provide, or on a set of test parts you choose to share. DQM itself is licensed from DOCUFY; Check-Mate comes from Siemens with NX, depending on your license configuration.
Where AI helps, it helps around the check, not inside it. A language model can draft a first executable condition from your guideline text for an engineer to review, or explain a finding in the terms of your standard; Vision4NX technology from inteliScience is integrated into DQM for that kind of explanation. The pass or fail itself stays deterministic. If AI is used at all, where the models run is decided per project, on premises included.
How we introduce custom checks in your NX
The order matters more than the platform. A rule catalog that nobody owns is the first thing to fix, whichever tool runs the checks.
- Rule catalog. Your guideline converted rule by rule: text, condition, scope, severity and owner. Rules that need judgement are marked as review items.
- Platform per rule. What goes into your Check-Mate profiles, what into DQM, what becomes NXOpen code, and what stays a manual review item.
- First rule family. Usually attributes and layers: they fail often, they break ERP and PLM processes downstream, and they are the easiest to correct.
- Test set and baseline. Known-good and known-bad parts, then a batch run over existing data with a failure rate per rule.
- Warnings first. Checks go live as information or warnings, and methods adjusts the rule text where the baseline shows it is unrealistic.
- Gate. Rules with a clear correction path become errors and, where you want it, a condition in your Teamcenter release workflow.
- Maintenance. Rule changes and NX upgrades go through the same test set before rollout, and the effect over time is tracked with CAD data quality metrics such as findings per part.
Start with five of your written rules
We do not start with the whole guideline. We start with five rules your reviewers flag again and again, and a batch of your parts.
Fixed scope · your parts
NX Sprint
Five of your written rules turned into checks and run on a batch of your parts: the step between a slide and a rollout.
- Five rules, chosen with your methods or quality lead
- Built where they fit: Check-Mate, NXOpen or DQM configuration
- Tested against known-good parts for false positives
- A batch run on your parts, with a failure report per rule
On your infrastructure or with test parts you share
For comparison
Rules in a PDF
The guideline exists; whether it is followed depends on who reviews.
- The same findings written by hand in every review
- Compliance varies by team and by reviewer
- Existing parts never checked against a new rule
Frequently asked questions about custom NX quality checks
What are custom NX quality checks?
Which design rules can be checked automatically in Siemens NX?
How do you create a custom checker in Siemens NX Check-Mate?
Should company design rules be built in Check-Mate, as NXOpen programs or in DOCUFY DQM?
How do you prevent false positives in automated CAD quality checks?
Can NX quality checks run in batch on existing CAD data?
What happens to custom NX quality checks when Siemens NX is upgraded?
Can AI write quality checks for Siemens NX?
Send us one page of your design guideline.
We will tell you which of its rules can become checks, where each one fits best (Check-Mate, NXOpen or DQM), and honestly which ones should stay with your engineers.
Talk to an EngineerSiemens NX, NXOpen and Teamcenter specialists · official DOCUFY partner · nearshore from Romania · on-premises option