NX AI Requirements: The Short Version
NX AI requirements are the things NX and Teamcenter users expect from an assistant: documentation answers per version, method advice under company rules, gated actions through NXOpen, Teamcenter customization help, ticket-based error handling and sovereign operation. This whitepaper maps 21 real user expectations to capabilities and ends with an RFP checklist inteliScience uses in fixed-price pilots.
| Question | Answer in one line |
|---|---|
| Where do the requirements come from? | A DACH machine builder’s CAD administration asked its NX and Teamcenter users what they expect from an “NX AI”. The 21 answers, anonymized, are the spine of this document. |
| What do users actually want? | Six things: documentation answers, method advice, actions in NX, administration work, Teamcenter customization help and ticket-based troubleshooting. Two more are conditions: company-specific knowledge and sovereign operation. |
| What does “training on our data” mean? | In practice retrieval over your documents, data model exports, ticket history and code, plus tool access. Fine-tuning is the exception, not the plan. |
| What does it take to deliver? | Three capabilities: knowledge (NX docs per version plus your standards), tools (NXOpen and Teamcenter SOA behind a gate) and memory of your own artefacts. Plus a deployment that fits your data rules. |
| Where to start? | A fixed-price pilot on one use case with agreed metrics, then a phased adoption: answers first, preparation second, gated actions third. |
1. Why This Whitepaper: A User List Beats a Feature Matrix
Vendor feature matrices describe what a product can do. A list of what users expect describes what a product must do. The second list is rarer, and when a customer hands us one, it is worth more than any demo.
The CAD and PLM administration of a DACH machine builder asked its NX and Teamcenter users one question: what do you expect from an NX AI? The answers came back in six blocks, from “how do I switch off automatic constraints in the legacy sketch on a drawing” to “hardware, installation, operation, costs, cloud, on-premise”. Nobody asked for a chatbot. Everybody asked for a colleague who knows NX, knows the company and can, when asked, do something.
We publish the list here (paraphrased, without any identifying detail) because it is the best requirements document for an engineering AI we have seen in 2026. It is concrete, it mixes trivial and hard questions the way real work does, and it exposes the difference between a model that talks about NX and a system that works in it. Siemens’ own numbers show how much room there is: Designcenter 2606, the June 2026 release that renamed NX to Designcenter, ships Designcenter Copilot, and Siemens reports its AI capabilities being used over 500,000 times a month. Those uses are documentation-grounded answers. The user list below asks for more than that, and it asks for it under company rules.
The audience of this whitepaper is the person who has to write the requirements: the CAD manager, the PLM lead, the engineering IT architect. If you are evaluating vendors rather than specifying, our buyer’s framework for evaluating engineering AI assistants covers the scoring side; this document covers what to score against.
2. Six Expectation Classes Derived From the List
Read the 21 expectations once and they look like a random collection. Sort them by what a correct answer requires and six classes appear. The class is more useful than the question, because it tells you which capability a system needs before it can answer any question of that kind.
| # | What the users asked (paraphrased) | Class | Capability required |
|---|---|---|---|
| 1 | Switch automatic constraint creation on or off in the legacy sketch on a drawing | Documentation | NX documentation for the installed version; setting lookup |
| 2 | Create a 3D part from a sketch and a sketch path (sweep along a path) | Documentation | NX documentation for the installed version; command lookup |
| 3 | Where and how to attach the callout for a component change on the drawing | Method | Company drawing standard; NX documentation |
| 4 | Create stable, associative WAVE links | Method | Company modelling guideline; NX documentation |
| 5 | Repair broken WAVE links | Method, then action | NX documentation; read tool over the assembly; gated relink tool |
| 6 | “Design a keyway of type xy in this shaft for me” | Action | Standard table; read tools; gated NXOpen build tool |
| 7 | Parametric feature “undercut DIN 509 type E” driven by shaft diameter | Administration | Standard table; expression and feature template preparation; admin validation |
| 8 | Add material xyz to the material database | Administration | Library entry preparation; admin applies |
| 9 | Add hole xyz to the hole table | Administration | Table entry preparation; admin applies |
| 10 | In role Standard, application Modeling, Home tab, add a button that runs program xy | Administration | Customization preparation; admin applies |
| 11 | The program reports error xy, what do I do? | Support ticket | Ticket history; company code; log reading |
| 12 | Set value x to y in the preferences | Administration | NX documentation; customer defaults; gated where scripted |
| 13 | Which preference enables function …? | Documentation | NX documentation for the installed version |
| 14 | NXOpen programming | Action (code) | NXOpen API reference per version; company code library |
| 15 | Can the AI be trained on our Teamcenter data model, workflows and processes? | Teamcenter customization | BMIDE and workflow template exports as retrieval sources |
| 16 | Help with workflow creation and knowledge of the handlers | Teamcenter customization | Handler documentation; own workflow templates |
| 17 | Building stylesheets | Teamcenter customization | Own stylesheet (XRT) exports; documentation |
| 18 | SOA programming | Teamcenter customization | SOA documentation per version; own service code |
| 19 | Train on our ticket system for AI-based error handling | Support ticket | Ticket export with resolution field; access rules |
| 20 | Training on our data, programs, documentation | Cross-cutting: knowledge | Retrieval platform with refresh cadence (chapter 4) |
| 21 | Hardware, installation, operation, costs, cloud, on-premise | Cross-cutting: operations | Deployment option and cost model (chapters 8 to 10) |
Three observations from the sort.
The documentation class is the smallest and the easiest, and it is the one Siemens now covers well with Designcenter Copilot. Any vendor who demos only this class is demoing the part of the problem that is already solved.
The method class is where company rules enter. Where a change callout goes on a drawing is not in the NX manual; it is in your drawing standard. How to keep WAVE links stable is half NX knowledge (link to stable, named geometry rather than to faces that regenerate) and half your modelling guideline. An assistant that answers method questions from public knowledge alone will be technically plausible and wrong for you.
The administration and Teamcenter classes are the ones a general chatbot cannot touch at all, and together they are the largest group on the list: 9 of 21 expectations. They need the company’s own artefacts in the loop and a clear line between what the assistant prepares and what the administrator applies.
3. The Capability Model: Knowledge, Tools, Memory
Every expectation on the list resolves to one or more of three capabilities. We name them plainly because vendor language (“copilot”, “agent”, “trained model”) hides which one is meant.
| Capability | What it is | Which expectations it serves | What it must never do |
|---|---|---|---|
| Knowledge | Retrieval over NX and Teamcenter documentation for the installed version, plus your standards, guidelines and templates, with a citation on every answer | 1, 2, 3, 4, 12, 13, 16, 18 | Answer from a different NX version; answer without a source |
| Tools | Typed NXOpen and Teamcenter SOA operations exposed to the assistant, read tools free, write tools behind preview, confirm, undo and audit | 5, 6, 7, 12, 14 | Execute a write without confirmation; run free-form journals |
| Memory of your artefacts | Indexed exports of your data model (BMIDE), workflow templates, stylesheets, ticket history, NXOpen and SOA code, with access rules mirrored | 7 to 11, 15 to 19 | Leak an artefact to a user who may not read it; go stale silently |
The three are not optional layers you add over time in any order. Knowledge without memory answers generically. Tools without knowledge act without knowing your rules. Memory without tools can explain last year’s ticket but cannot check whether the same error is on your screen now.
Our clear recommendation, after every project of this kind: build knowledge and memory first, ship them read-only, and add tools only after users trust the answers. The architecture that makes the tool layer safe (the gate, undo marks, role scopes, audit log) is described in our NX MCP whitepaper, and we do not repeat it here. What this document adds is the requirement view: which expectation needs which capability, and what “trained on our data” has to mean for the memory layer to work.
4. “Company-Specific Training”, Explained Honestly
Expectation 20 is the one every customer states and almost every vendor answers loosely: “train the AI on our data, programs and documentation”. Precision matters here because the two things the phrase can mean have very different costs, refresh behaviour and data-protection profiles.
Retrieval means the model stays as delivered and your material is indexed. At question time the system finds the relevant passages (from a guideline, a BMIDE export, a ticket, a source file), hands them to the model with the question, and the model answers from them with a citation. Update a document, re-index it, and the next answer reflects the change. Nothing about your company enters the model’s weights.
Fine-tuning means adjusting the model’s weights on examples from your data. It changes how the model writes and what patterns it prefers. It does not give the model a reliable memory of specific facts, it cannot cite a source, it goes stale the moment a standard changes, and it requires your data to be used as training material, which is exactly what most data-protection reviews forbid.
For the 21 expectations on the list, retrieval covers every one that involves knowing something. We advise against fine-tuning on customer data for engineering assistants, and we do not do it in our deployments. The only place fine-tuning earns a discussion is a narrow, stable, high-volume classification task, and the ticket-routing case in chapter 7 is the closest the list comes to one. Even there, retrieval with a good ticket export is the first thing to try.
What retrieval needs is a corpus, a refresh cadence and access rules. The table below is the version we agree with customers in a pilot.
| Source | Format we ingest | Refresh | Access rule | Must never leave the company |
|---|---|---|---|---|
| NX and Teamcenter documentation | Vendor documentation for the installed release, tagged with the version | Per release upgrade | All users | No (vendor material), but licence terms apply |
| Company standards, guidelines, drawing rules | PDF, Word, wiki pages | On change, at least monthly | Per document ACL | Yes |
| BMIDE data model | Template export (XML) | On every BMIDE deployment | PLM admins, developers | Yes |
| Workflow templates, handler arguments | Workflow Designer export | On every template change | PLM admins | Yes |
| Stylesheets (XRT) | Dataset export from Teamcenter | On change | PLM admins, developers | Yes |
| NXOpen and SOA code | Source repository | On every merge | Developers, CAD admins | Yes |
| Support tickets | Export with problem, resolution, product, version fields | Daily | Support, CAD admins; personal data removed | Yes |
| Customer defaults, preferences | Exported defaults files | On change | CAD admins | Yes |
Two rules make or break this table. Access rules carry over: whoever may not open a source must not receive an answer derived from it, evaluated per user at question time. And every corpus is version-tagged: NX 2412 documentation must not answer a Designcenter 2606 question, and a stylesheet from the previous Teamcenter release must not be cited as current.
5. The NX Side: Documentation, Company Rules, or NXOpen Execution
Expectations 1 to 14 are NX questions, and the useful requirement is not “answer NX questions” but “know which kind of answer each question needs”. We sort them into three tiers because each tier has a different failure mode and a different acceptance test.
| Tier | Questions from the list | Answer comes from | Acceptance test |
|---|---|---|---|
| Answerable from documentation | 1 (legacy sketch constraints), 2 (sweep along a path), 13 (which preference) | NX documentation for the installed version, cited | Correct for the installed release; says so when a command changed between releases |
| Needs company rules | 3 (change callout placement), 4 (stable WAVE links), 12 (preference values) | Your drawing standard, modelling guideline and customer defaults, cited alongside the NX documentation | Cites the company document, not a generic best practice; declines when no company rule exists |
| Needs NXOpen execution | 5 (repair WAVE links), 6 (keyway), 14 (NXOpen code) | Read tools on the open part, then a gated build tool or generated code the user reviews | Preview before any change; every parameter traceable; undo mark and audit entry on apply |
A few notes on the individual questions, with the caution the brief demands: where we have not verified an NX behaviour against Siemens material, we say what the assistant must look up rather than asserting the answer.
Question 1 is a settings question with a version twist. “Create Inferred Constraints” is a sketch setting in NX, and Siemens Community threads document that NX can disable it automatically on large sketches with a performance alert. A good answer therefore names the setting, states the release it applies to, and mentions the automatic behaviour, because the user who asks “how do I switch it on” may be fighting NX switching it off. A general model will give the first half and miss the second.
Question 2 is the cleanest documentation case. NX has a Sweep Along Guide command for exactly this construction; the assistant has to find the command in the documentation for the installed release, explain the section and guide selection, and stop. No company rule, no action.
Questions 4 and 5 belong together and are the best illustration of the tiers. Stable WAVE links are a method question: the NX documentation explains the WAVE Geometry Linker, but whether your company links to bodies, faces or named geometry, and whether links are allowed across assembly levels, is in your modelling guideline. Broken links are an action question: NX exposes a Relinker through NXOpen (the Assemblies.RelinkerBuilder class, which can search WAVE links and interpart expressions, filter for broken ones and relink them to a new source). An assistant that can list the broken links on the open assembly (read tool) and propose a relink per link (gated write) turns a two-hour manual job into a review. An assistant that just explains what a WAVE link is has answered the wrong tier.
Question 6, the keyway, is the action request everybody remembers from the list. It is answerable, but only when the assistant gathers every parameter from a source before it proposes anything: the shaft diameter from the model, the keyway width and depth from the standard’s table for that diameter, the length and position from the user, and the feature to use from your feature library.
A tool call without provenance for every parameter should fail the requirement, not because the numbers are wrong, but because nobody can check whether they are.
Question 14, NXOpen programming, is where general models fail most visibly: they invent API members. The requirement is version-aware API grounding, which means the NXOpen reference for the installed release is in the retrieval corpus and your own code library is in the memory layer, so proposals use your naming and your wrappers. The generated code is reviewed by a developer like any other pull request; the assistant is a faster colleague, not a release process.
6. The Teamcenter Side: What the Assistant Prepares, What Stays With the Admin
Expectation 15 asks the key question directly: Teamcenter is heavily customized, can the AI be trained on our data model, workflows and processes? Yes, in the retrieval sense of chapter 4, and it is the single most valuable corpus a Teamcenter team can index, because nothing about a customized Teamcenter is in any public documentation.
What the assistant can and cannot do per artefact is the requirement that matters, because Teamcenter customization is where an over-eager assistant does the most damage.
| Artefact | The assistant can prepare | Stays with the administrator or developer |
|---|---|---|
| Data model (BMIDE) | Explain your item types, properties, LOVs and relations from the template export; draft a change description; find where a property is used | Every BMIDE change, deployment and database update |
| Workflow templates and handlers | Explain what a template does from its export; look up handler purposes and arguments (action handlers perform actions on a task, rule handlers decide whether a task may proceed); draft a template design and the handler argument list | Building and testing the template in Workflow Designer; releasing it |
| Stylesheets (XRT) | Read your existing stylesheets; propose the XML for a new section or property block in your conventions; explain rendering rules | Registering the dataset; testing in the clients; release |
| SOA services and ITK | Propose service calls and client code from the SOA documentation for your release and your own service library; explain an existing custom service | Compiling, deploying, permission review |
| Runtime actions (workflow start, ECR draft, property updates) | Draft the action, resolve affected items, show the preview | Confirmation, executed in the user’s own session and permissions |
The line is consistent: the assistant reads, explains and drafts; a human with the right role applies. For the runtime actions in the last row, our Teamcenter AI offer describes the assistant that executes under the user’s own permissions with one confirm gate per action, and the same rule applies: it never approves, never releases, never changes a workflow definition.
Expectation 16 deserves a specific note. “Knowledge of the handlers” is a request for something Siemens documentation provides in principle but nobody reads in practice: which handler exists for which job, and what its arguments are. Indexing the handler documentation for your release and, more importantly, your own templates (which show how your predecessors combined them) gives a PLM admin the reference they have wanted for years. This is a read-only knowledge use case, ships in the first phase, and is the Teamcenter task we would start with.
7. Support Tickets as a Knowledge Source
Expectation 19 asks whether the ticket system can train the AI for error handling. It can, as a retrieval corpus, and it is the one source on the list that pays back fastest, because tickets contain the exact pairing an assistant needs: a symptom in the user’s words and a resolution in the administrator’s.
Three conditions decide whether a ticket corpus is useful.
The resolution field must be filled. A ticket that closes with “fixed” teaches nothing. Before indexing, measure the share of tickets with a substantive resolution; if it is low, the pilot starts with the administrators writing resolutions properly for a month, which is worth doing regardless of AI.
Personal data is removed before indexing. Reporter names, e-mail addresses and free-text fields with personal details are stripped or pseudonymized in the export. This is both a data-protection requirement and a quality improvement, because names are noise to retrieval.
Product and version fields are kept. An NXOpen error against one release may have a different cause in the next; the assistant must be able to say “this matched three tickets, two of them on your current release”.
With those conditions met, expectation 11 (“the program reports error xy, what do I do?”) becomes a retrieval question over tickets, code and, where the assistant has a read tool, the log of the running session. The answer cites the tickets it matched. What the assistant must not do is close the ticket, change a configuration or run a repair without the confirmation gate; error handling is advice until a human applies it.
This runs as a POC. What’s missing for production: GDPR compliance, SSO/Entra, scaling, monitoring, operations. We close the gap from “runs on my machine” to “runs in the enterprise”: scope a fixed-price NX AI pilot project.
8. Deployment Options: Cloud API, EU Region, Private, On-Premise, Air-Gapped
Expectation 21 lists the operational questions in one breath: hardware, installation, operation, costs, cloud, on-premise. The first decision is where the reasoning model runs, because it determines everything else. Four options exist in 2026, and all four are real; the differences are data residency, model choice and who carries the operational load.
One fact anchors the table. A frontier model no longer implies a single vendor endpoint. Anthropic lists Claude Opus 5.5 (model ID claude-opus-5-5, released 22 September 2026) as available on the Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry and Claude Platform on AWS, and Amazon Bedrock documents regional endpoints for the EU that route traffic through a specific geography for data residency requirements, at a 10 percent premium over global endpoints. On the open-weight side, OpenAI’s gpt-oss-120b is published under Apache 2.0 and is designed to run on a single 80 GB GPU, and Mistral Small 3.1 (24B) is Apache 2.0 with about 55 GB of VRAM at bf16, or a single consumer GPU when quantized. Sovereign operation is a configuration choice, not a compromise on capability.
| Option | Data residency | Model choice | Operations effort | Who patches what | Fits when |
|---|---|---|---|---|---|
| Vendor cloud API | Vendor’s terms and regions | Frontier models, latest first | Lowest: no model operations | Vendor patches the model and API; you patch the assistant, connector and index | Non-sensitive corpora; fastest start; data-protection review accepts the vendor’s terms |
| Hyperscaler in an EU region (Bedrock, Vertex AI, Foundry) | Your tenant, EU region selectable; regional endpoints for guaranteed routing | Frontier models with a short lag behind the vendor API | Low: tenant, IAM and network setup | Hyperscaler patches the model runtime; you patch the assistant, connector and index | Most DACH manufacturers with an existing cloud tenant and a residency requirement |
| Private cloud or on-premise with open-weight models | Your infrastructure, your network | Open-weight models (gpt-oss, Mistral, others) | Medium to high: GPU servers, inference runtime, model updates | You (or your partner) patch everything: runtime, model versions, assistant, index | Part data or standards may not leave the building; existing GPU capacity or willingness to buy it |
| Air-gapped | No external connection at all | Open-weight models only, updated by physical transfer | Highest: everything offline, including documentation updates | You patch everything, on a schedule, from verified media | Defence, export-controlled programs, IP-critical development |
Our position for the DACH machine builder profile on the list: the EU-region hyperscaler option is the default to evaluate first, because it keeps the frontier model, satisfies residency, and leaves the connector, the index, the audit log and all part data on the customer’s side. Full on-premise is the right answer when the security review says so, not because it sounds safer; it brings operational duties that a CAD department rarely wants. Air-gapped is a category of its own, and our page on sovereign, air-gapped engineering AI for defence covers what changes when even documentation updates arrive on a disk.
Whatever the option, one requirement does not change: the NX-side connector, the tool layer, the retrieval index and the audit log run where the parts are. The model can be remote; the gate cannot. We wrote up the wider argument in our piece on sovereign agentic AI in European manufacturing.
9. Hardware and Operations: What Drives Sizing and Who Does What
Hardware questions get invented answers more often than any other topic in this field. We give none. What we can give is the list of variables that drive sizing, so you can ask a vendor for numbers against your values instead of accepting a generic GPU count.
Sizing is driven by five variables. Concurrent users during the peak hour, not licensed users, because an assistant is bursty. Context per request: how many retrieved chunks plus tool results travel with each question; a Teamcenter data model question carries more than a preference lookup. Retrieval index size: chunks times embedding dimension, which for a document corpus is small next to the model itself, but ingestion compute in the first week is not. Model size and precision, which set the memory floor; the two Apache 2.0 models above illustrate the range from a single consumer GPU (quantized 24B) to a single 80 GB data-centre GPU (gpt-oss-120b). And latency target: a read tool answering inside NX at conversational speed needs headroom that a nightly batch does not.
For the cloud options, hardware is not your problem, and cost becomes tokens (chapter 10). For on-premise, ask the vendor to size against your five values and to state the model, precision and inference runtime the number assumes.
Installation and operation split cleanly once the components are named. This is the table we agree in every rollout, and it is also a useful RFP attachment.
| Component | Installs | Operates day to day | Patches and upgrades | Owns the data |
|---|---|---|---|---|
| NX-side connector | Integration partner with CAD admin | CAD admin | Integration partner, tested per NX release | Customer |
| Tool layer (MCP server, Teamcenter SOA client) | Integration partner | CAD/PLM admin | Integration partner; customer for tool additions after handover | Customer |
| Retrieval index and ingestion jobs | Integration partner | Engineering IT | Engineering IT (jobs), partner (pipeline changes) | Customer |
| Knowledge curation (standards, templates, ticket quality) | CAD/PLM admin | CAD/PLM admin, standards owner | Continuous | Customer |
| Model runtime, cloud | Hyperscaler or vendor | Hyperscaler or vendor | Hyperscaler or vendor | Customer’s tenant data per contract |
| Model runtime, on-premise | Engineering IT with partner | Engineering IT | Engineering IT (runtime), partner (model version tests) | Customer |
| Identity and access (SSO, role scopes) | Engineering IT | Engineering IT | Engineering IT | Customer |
| Audit log | Integration partner | CAD manager | Integration partner | Customer |
Two rows are underestimated in every first budget. Knowledge curation is a permanent job for the CAD administration, because the assistant faithfully cites outdated standards, and the pilot month tends to surface more stale documents than the previous review year. And the model runtime row for on-premise is an engineering IT duty with a release cadence of its own; if nobody in the organisation wants that row, choose a cloud option.
10. The Cost Model, and Why a Fixed-Price Pilot Comes First
Costs on the list (“costs, cloud, on-premise”) cannot be answered with a number before the deployment option and the scope are fixed. They can be answered with a driver model, which is what a budget owner needs to compare proposals.
| Cost driver | Cloud options | On-premise and air-gapped | What moves it |
|---|---|---|---|
| Model access | Tokens per request, priced per million input and output tokens | GPU hardware, power, inference runtime; no per-token fee | Concurrent users, context per request, answer length |
| Hardware | None beyond the tenant | GPU servers sized in chapter 9 | Model size, precision, latency target |
| Integration | NXOpen connector, tool layer, Teamcenter SOA mapping, SSO | Same, plus runtime setup | Number of tools, custom features and Teamcenter object types mapped |
| Knowledge curation | Corpus preparation, access-rule mapping, ticket clean-up | Same | Corpus size and quality; number of access groups |
| Operations | Index refresh, monitoring, audit review | Same, plus model and runtime patching | Refresh cadence, number of sources, on-premise duties |
| Licences | NX and Teamcenter seats unchanged: the assistant runs under the user’s own licence and permissions | Same | Nothing, unless a vendor product adds seats |
The honest observation is that integration and knowledge curation, not model access, dominate the first year for a customized Teamcenter environment. Token bills are visible and easy to argue about; the weeks spent mapping BMIDE object types and cleaning ticket resolutions are where the money goes, and they are also where the value comes from.
That is why we insist on a fixed-price pilot as the first step, with the scope and the metrics agreed before anything is built. Each assistant in our NX AI assistant family has a fixed-scope proof of concept, and the NX Proof-of-Value Sprint on the pilot offer page is €12,900 fixed for one use case selected with your stakeholders, a running prototype evaluated against agreed metrics in two to three weeks, fully credited against the follow-up project, with every solution able to run fully on-premise, including air-gapped.
What a pilot must measure is more important than what it costs. Four numbers, on your questions and your parts:
- Grounded-answer rate. Share of answers with a correct citation to your material or the vendor documentation for the installed release. Include unanswerable questions on purpose; “not in your material” is a correct answer.
- Version accuracy. Share of documentation answers that are correct for the installed NX or Teamcenter release, not for a neighbouring one.
- Preparation acceptance. For administration and Teamcenter drafts, the share accepted by the administrator without rework, and minutes saved per accepted draft.
- Gate behaviour. For any action tier in scope, the share of previews accepted, edited and discarded, and the rollback rate after confirmation.
A pilot that reports usage counts instead of these four has not been evaluated.
11. Requirements Checklist for an RFP
The list below is written so that it can be pasted into a requirements document. Each item is testable; several are the direct translation of a user expectation from chapter 2.
- The assistant answers NX and Teamcenter documentation questions for the installed release and states the release it answered for.
- Every answer carries a citation to the document, ticket, code file or standard it was derived from; answers without a source are declined, not improvised.
- Company standards, guidelines and drawing rules are indexed and take precedence over generic best practice when they conflict.
- Access rules from the source systems are evaluated per user at question time; no user receives answers derived from material they may not open.
- Each corpus is tagged with the product version it belongs to; corpora of different releases are never mixed in one answer.
- Refresh cadence per source is documented (release, on change, daily) and refresh is incremental.
- No customer data is used to train or fine-tune any model, and no prompts or answers are retained by a third party beyond the contractually agreed period.
- The Teamcenter data model (BMIDE export), workflow templates, handler documentation and stylesheets can be indexed and explained; the assistant prepares changes but does not deploy them.
- Support tickets can be indexed with personal data removed and resolution, product and version fields preserved.
- Read tools over the open NX part and the Teamcenter session are available without confirmation and are the first tier delivered.
- Every write to NX or Teamcenter is previewed, requires explicit confirmation, sets an undo mark or equivalent, and is logged with user, timestamp, tool, parameters and result.
- Every parameter in a proposed action carries provenance (model read, standard table, company rule or user input).
- No free-form journal or script execution by the assistant; write operations are typed tools with engineering units.
- Actions in Teamcenter execute in the requesting user’s own session and permissions; the assistant holds no privileged service account and never approves or releases.
- Role-scoped tool access is enforced through the company identity provider (SSO).
- The deployment option (vendor API, EU-region hyperscaler, on-premise, air-gapped) is selectable, and the connector, tool layer, index and audit log run on the customer’s infrastructure in every option.
- The model is replaceable without rewriting the tool layer or the index (protocol-based integration, model-agnostic).
- Sizing for on-premise operation is stated against the customer’s concurrent users, context per request, index size and latency target, with the assumed model and precision named.
- Installation, operation and patching responsibilities are listed per component before contract signature.
- The pilot is fixed-price, fixed-scope, reports the four metrics in chapter 10 on the customer’s own questions, and its price is credited against the rollout.
Item 2 alone eliminates most demos. Item 12 is the one CAD managers thank us for later.
12. Adoption Path in Phases
The list’s expectations can be delivered in an order that builds trust before it builds risk. The order is the same in every deployment option; only the phase lengths change with corpus quality.
| Phase | Scope from the list | Delivers | Exit criterion |
|---|---|---|---|
| 0. Corpus and rules (weeks 1 to 2) | Expectations 20, 21 | Deployment option chosen; standards, documentation and one Teamcenter export indexed with access rules; pilot metrics agreed | Corpus builds reproducibly; access mapping verified by IT |
| 1. Answers (weeks 2 to 5) | 1, 2, 3, 4, 12, 13, 15, 16, 17, 18 | Read-only assistant answering NX and Teamcenter questions with citations, for a pilot group | Grounded-answer rate and version accuracy measured on the team’s real questions |
| 2. Preparation (weeks 4 to 8) | 7, 8, 9, 10, 11, 19 | Administration and Teamcenter drafts (feature specs, library entries, customization steps, handler lists, stylesheet blocks); tickets indexed | Preparation acceptance rate measured with the administrators |
| 3. Read tools (weeks 6 to 9) | 5 (list broken links), 14 (API grounding) | Assistant sees the open part and the Teamcenter session; NXOpen proposals from your library | Designers use read tools daily; zero writes so far |
| 4. Gated actions (from week 9) | 5 (relink), 6 (keyway), 12 (scripted defaults), Teamcenter runtime actions | One narrow write tier at a time, each with preview, confirm, undo and audit | Gate behaviour measured per tool; CAD manager signs the rollout |
| 5. Rollout | All | Role scopes, SSO, monitoring, refresh jobs handed to engineering IT; curation duties with the CAD administration | Responsibilities table (chapter 9) signed |
Phase 1 is where the users on the list get most of what they asked for, and it carries no write risk. Phase 4 is where the keyway gets designed, and it should arrive only after phases 1 to 3 have earned it. If a vendor proposes to start at phase 4, the demo will be impressive and the CAD manager will not sign it.
Frequently Asked Questions
What are the NX AI requirements an engineering team should put in an RFP?
Version-aware documentation answers with citations, company standards indexed with per-user access rules, retrieval over Teamcenter exports and tickets, read tools before write tools, a preview-and-confirm gate with undo and audit on every write, provenance for every parameter, execution under the user’s own permissions, a selectable deployment option with the connector and index on your infrastructure, and a fixed-price pilot with agreed metrics. Chapter 11 lists all twenty items in pasteable form.
Can an AI be trained on our NX documentation, Teamcenter data model and ticket system?
Yes, in the sense that matters: your documentation, BMIDE exports, workflow templates, stylesheets, code and tickets are indexed, and the assistant answers from them with citations. That is retrieval, not fine-tuning. Fine-tuning changes model weights, cannot cite, goes stale and requires your data as training material; we do not use it on customer data. Retrieval covers every knowledge expectation on the list and refreshes when a document changes.
How much does an NX AI pilot cost?
Our NX Proof-of-Value Sprint is €12,900 fixed for one use case, a running prototype evaluated against agreed metrics in two to three weeks, fully credited against the follow-up project. Rollout cost then depends mainly on integration depth and knowledge curation rather than on model access.
Cloud or on-premise for an NX AI: which is better?
For most DACH manufacturers, a hyperscaler tenant in an EU region is the first option to evaluate: it keeps a current frontier model such as Claude Opus 5.5, satisfies data residency through regional endpoints, and leaves the connector, index, part data and audit log on your side. On-premise with an Apache 2.0 open-weight model such as gpt-oss-120b is right when part data or standards may not leave the building, and it brings model and runtime operations into engineering IT. Air-gapped is a separate category for defence and export-controlled work.
Can the assistant change our NX models or Teamcenter data on its own?
No. Read tools are free; every write is previewed, applied only after explicit confirmation, wrapped in an undo mark and logged. In Teamcenter, actions run in the requesting user’s own session and permissions, and the assistant never approves, releases or changes a workflow definition or the data model. What you may not do in Teamcenter, it cannot do for you.
Next Step
Send us your own version of the list: the questions your NX and Teamcenter users would ask an assistant first. We will map each one to a class and a capability, tell you which ones a pilot can answer in three weeks, and which ones need your standards cleaned up first.
Related Topics
- Fixed-price NX AI pilot project
- Private AI knowledge assistant case study
- Where Siemens’ Teamcenter Copilot helps and where it stops
Sources
- Siemens, “Designcenter is for everyone, June 2026 release”, blogs.sw.siemens.com, 23 June 2026 (Designcenter 2606, Designcenter Copilot, AI capabilities used over 500,000 times a month), retrieved 24 September 2026
- Anthropic, “Models overview” and “Claude Opus 5.5” (model ID
claude-opus-5-5, released 22 September 2026; availability on Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry, Claude Platform on AWS), platform.claude.com, retrieved 24 September 2026 - Anthropic, “Claude on Amazon Bedrock” (global versus regional endpoints, EU regional endpoints for data residency, 10 percent premium), platform.claude.com, retrieved 24 September 2026
- OpenAI, gpt-oss-120b model card (Apache 2.0, 117B parameters with 5.1B active, designed for a single 80 GB GPU), huggingface.co, retrieved 24 September 2026
- Mistral AI, Mistral Small 3.1 24B Instruct model card (Apache 2.0, about 55 GB VRAM at bf16, single RTX 4090 or 32 GB Mac when quantized), huggingface.co, retrieved 24 September 2026
- Siemens, NXOpen .NET Reference Guide,
NXOpen.Assemblies.RelinkerBuilder(search and relink WAVE links and interpart expressions, broken-link filter, break-WAVE-link option), docs.sw.siemens.com, NX 1926 API reference, retrieved 24 September 2026 - Siemens Community, “How do I stop NX from automatically disabling Create Inferred Constraints on a sketch?” and “Sweep along guide question”, community.sw.siemens.com, retrieved 24 September 2026
- Siemens, Teamcenter Gateway generic configuration guide, “Workflow rule handler documentation” (rule handlers return EPM_go or EPM_nogo), docs.plm.automation.siemens.com, and Siemens Community, “Workflow handlers” thread, retrieved 24 September 2026
- DIN 509 (undercut forms E, F, G, H) and DIN 6885-1 (parallel keys and keyways), referenced as standards; table values must be taken from the licensed standard text for the installed revision
- inteliScience, “NX AI Pilot Project” offer page (NX Proof-of-Value Sprint, €12,900 fixed, 2 to 3 weeks, fully credited), “NX AI Assistants & Chatbots” service hub, “NX MCP Whitepaper” (gate architecture), “Engineering AI Assistant Evaluation” (buyer’s framework), inteliscience.net, 2026