AI-Generated PMI in NX: The Short Version
AI-generated PMI means an LLM proposes dimensions and tolerances from a written guideline and NXOpen places them on the model. inteliScience ran this on a demo part with our own chatbot, our own NXOpen bridge, and our internal PMI guideline: dimensional PMI came out usable, GD&T was not in scope, and a human still signed off every annotation.
The Problem: PMI Authoring Is Slow Because the Rules Live in People
Placing a dimension in Siemens NX (Designcenter) is a few clicks. Deciding which feature gets a dimension, which tolerance class applies, which model view it belongs in, and which note goes with it is the slow part. That decision sits in a guideline half the team has skimmed and in the head of the methods engineer who wrote it.
Siemens describes PMI in Designcenter as the annotations and metadata that define how a part is manufactured: dimensions, tolerances, feature control frames, datums, surface finish, notes, organised in model views. The official Designcenter model-based definition page also covers Convert to PMI for legacy drawing views.
Whether the model or the drawing should be the master is a decision we wrote up in MBD or drawing as the master. This article assumes the model wins and asks the next question: who writes the PMI, and from which rules.
Could an LLM read our guideline and do the first pass? We tried it.
What we built: a chatbot, an NXOpen bridge, and a guideline in the middle
Three pieces, all ours: an LLM-based assistant (a current hosted LLM behind it, the model is interchangeable), an NXOpen bridge that runs against a live NX session, and our internal PMI/MBD guideline as the only domain input. Not a Siemens product, not a marketplace plugin. The guideline (dimensioning rules per feature type, tolerance classes by size range, view and note conventions) went in unchanged, which turned out to be the most instructive mistake of the experiment.
The loop: the assistant reads the guideline and proposes PMI for the demo part through the bridge (the same kind of LLM-to-NX connection we described for MCP). The bridge checks every proposal against the model and the guideline, creates only what passes, and hands the result to a human in NX.
House rule, and we do not bend it: the AI proposes, NXOpen executes, rules and a human validate. The LLM never calls NX directly and never gets to say “pass”.
And because the question always comes: Designcenter Copilot does not do this. Siemens’ Copilot tips page (12 May 2026) describes guidance grounded in documentation, with highlighted words in a response acting as direct links to commands. NX plus Copilot for “how do I”, NX plus a bridge like ours for “author my PMI from our rules”.
What the assistant got right and what needed a human pass
It worked for the straightforward cases: through holes, plate thickness, overall dimensions, anywhere the guideline has one rule per feature type and one tolerance row per size range. It needed a human pass wherever the guideline needs interpretation, and wherever the guideline is silent.
What went well: the assistant read the guideline’s structure correctly, so feature type plus size range led to the right tolerance row more often than we expected from a document written for humans. Dimensions landed on the features it named, with the bridge’s measurements as nominals, in the prescribed view. And a guideline citation on every proposal changed the review: instead of “is this right?”, the reviewer asks “does paragraph 4.2 really say that?”.
What needed a human pass, the kind of thing you check every time:
- Wrong feature reference where two features look alike but serve different functions (a locating hole next to a same-size clearance hole).
- Tolerance class from the neighbouring table row where a size sits on the border between two ranges.
- Duplicate PMI on symmetric features where the guideline expects one dimension with a repeat note.
- PMI on a plane that is legal but not the one a machinist would read.
- Confident gap-filling: where the guideline said nothing, the assistant proposed something plausible. Plausible is the dangerous word in this whole topic.
Review time did not go to zero, and we would not want it to. The reviewer changed from author to auditor, with a citation to check on every line.
Why the guideline document matters more than the model
Swap the LLM and the result moves a little. Swap the guideline and the result changes completely. That is the main finding.
Company PMI guidelines sit downstream of two standards. ASME Y14.41, Digital Product Definition Data Practices, establishes the requirements for preparing and revising digital product definition data sets. ISO 16792:2021 is the ISO counterpart and covers both 3D model-only and model-plus-drawing data sets. We did not feed either standard to the assistant. Our guideline is the company layer on top: house tolerance tables, view conventions, exceptions.
That guideline was written for readers who fill gaps with experience. An LLM fills gaps with plausibility. So most failure modes above are guideline failures wearing an AI costume: “see typical values” instead of a table, an “applies when” that lives in the author’s head, two rules that quietly conflict.
What an LLM-ready guideline needs, from what we had to fix: every tolerance rule as an explicit table row; an “applies when” condition per rule, tied to a feature type the bridge can detect; conflicts resolved on paper; a glossary mapping guideline terms to NX feature types and views; and a version number, so every proposal is traceable.
Our clear recommendation: before you spend anything on model selection, spend the time on the guideline. It survives every model swap and pays off even if the AI never arrives.
This works on a demo part. What is missing for production: guideline versioning, validation rules that block instead of warn, Teamcenter release, an audit trail per annotation, GD&T and datum systems, and a human sign-off step that cannot be skipped. We close that gap as a scoped project: MBD PMI authoring assistant for Siemens NX.
AI-Generated PMI vs Rule-Based NXOpen vs Manual Authoring
Three ways to get PMI on a model, and they are not rivals. Rule-based NXOpen is right when the rules are complete and stable. LLM-assisted authoring is right when the rules are prose with gaps. Manual stays for everything that carries release risk today.
| Criterion | Manual PMI authoring | Rule-based NXOpen automation | LLM-assisted (AI-generated PMI) |
|---|---|---|---|
| Rule source | Designer’s head plus the guideline | Rules coded and reviewed | Guideline in context, bridge enforces |
| Handles ambiguity | Yes, by experience | No, undefined case fails or is skipped | Yes, by guessing, hence the human check |
| Repeatability | Low between designers | Total | High for covered cases, not guaranteed |
| Explainability | “Because I know” | Rule ID in the log | Guideline citation per annotation |
| Who validates | Peer review, if any | Rules, then release check | Rules first, then a human, always |
| GD&T and datums today | Yes | Yes, where rules exist | Not in our run |
| Best for | Novel parts, low volume | Stable families, high volume | Prose guidelines, mixed parts, first pass |
The rule-based column is not theory. The automotive PMI automation case study is exactly that: coded rules creating PMI in NXOpen with no LLM in the loop. If your rules already fit in code, we would advise against adding an LLM; it adds a validation burden you do not need. The LLM earns its place where the guideline is mostly rules, partly judgement, never quite finished.
What is not there yet: GD&T, datums, release
No feature control frames, no datum systems, no Teamcenter release in this run. Those are the next step, and harder: a datum scheme is a decision about how the part functions and how it will be fixtured, not a table lookup.
GD&T comes after datums, so the order is fixed. We want the assistant to propose a datum scheme with a functional justification and a human to accept or rewrite it before a single feature control frame is generated.
Release is the other gap. A production version needs an audit trail per annotation: which assistant and guideline version proposed it, which rules it passed, who approved it, when it entered the Teamcenter release state. The AI never decides pass or fail on a released model.
Siemens’ June 2026 Designcenter release (the one that renamed NX to Designcenter) lists concurrent multi-user PMI operations in Live Share, and the Early Access Program for Designcenter 2612 ran in September 2026. A bridge that pins its guideline version and its NX version survives that cadence. A demo does not.
How to try this in your own team
You can reproduce the useful part of this experiment without our bridge; the first four steps need no AI at all.
- Pick one demo part with holes, faces and a symmetric feature. Never customer geometry for the first run.
- Audit the guideline: tables, “applies when”, resolved conflicts, glossary, version number.
- Write the bridge contract before writing code: what a proposal contains, what gets rejected, what gets logged.
- Define the human gate. Who reviews, what they check, and what “approved” means in your PLM.
- Start with dimensional PMI only. GD&T and datums are round two.
- Sort every correction into “guideline problem” or “model problem”. Expect the first pile to be bigger.
- Decide the route. Mostly rule gaps: fix the guideline, consider rule-based NXOpen. Mostly judgement calls: the LLM stays, and so does the reviewer.
Step 2 alone already improves manual PMI authoring.
Frequently Asked Questions
What is AI-generated PMI in Siemens NX?
AI-generated PMI is product and manufacturing information (dimensions and tolerances, later GD&T) that an LLM proposes from a written guideline and an NXOpen program creates on the model. The LLM never touches NX directly: it outputs structured proposals, the bridge validates them, and a person approves the result.
Can Designcenter Copilot create PMI from my guideline?
Not as Siemens describes it. Designcenter Copilot answers questions grounded in Siemens documentation and links you to the right commands. Authoring PMI from your own company rules is a different job, hence our own assistant and NXOpen bridge.
AI-generated PMI vs rule-based NXOpen PMI automation: which should we start with?
Rule-based if your guideline already reads like code: complete tables, no judgement calls. LLM-assisted if it is prose with gaps and you want a first pass a reviewer can audit. Either way the guideline clean-up comes first, and a human owns the release.
How much does an AI PMI authoring pilot cost?
It depends more on the state of your guideline than on the AI. Explicit tables keep the bridge contract short; a prose guideline means the pilot starts with methods work. We scope it as a fixed project after reading your guideline, not from a price list.
Does the AI decide whether the PMI is correct?
No, and it should not. The bridge rejects anything that does not match the model or the guideline tables, and a person signs off every annotation before release. The AI proposes, NXOpen executes, rules and a human validate.
Next Step
Want to see your own PMI guideline run against a demo part? Book a free strategy call and bring the guideline. Talk to our engineers about AI-generated PMI in NX