AI for Engineering Knowledge Management
How to evaluate an AI tool for Windchill in 2026: the WTPart to CAD association, view specific BOMs, the change object network, domain and lifecycle permissions, and a 30 day test.
·
⏱
8 min read
Dr. Maor Farid
Maor Farid is the Co-Founder and CEO of Leo AI, the first AI platform purpose-built for mechanical engineers. He holds a PhD in Mechanical Engineering and completed postdoctoral research at MIT as a Fulbright fellow. A Forbes 30 Under 30 honoree and former AI researcher and Mechanical Engineer in an elite military intelligence, Maor leads Leo AI's mission to transform how engineering teams design better products faster.
BOTTOM LINE
There is no single best AI tool for Windchill in 2026, and any ranking that claims otherwise is not looking at your data model. Windchill separates WTParts from the CAD documents that define them, maintains distinct design and manufacturing views of the same product, records rationale in a linked network of change objects, and enforces permissions per object type, per lifecycle state, per participant. Those four facts are the evaluation criteria. A tool that traverses the part and CAD association, names the view it answered from, cites the change object behind a decision, and resolves permissions per user at query time will survive contact with your vault. One that does three of the four will pass the demo and fail the audit. Test all four on your own data, with questions written before the vendor arrives.
If your engineering organisation runs on Windchill, the useful question in 2026 is not whether AI can help. It is which AI actually understands what Windchill is holding. Most tools on the market were designed against a generic document store, and Windchill is not one. It keeps parts separate from the CAD files that define them, holds more than one structural view of the same product, routes every released change through a network of linked objects, and decides who sees what through a rule set most search tools never read. A tool that ignores any of those four things will demo well and stall in week three. Below are the four questions that separate the two, each written against how Windchill actually stores your data.
What Windchill Already Does, and Where the Gap Actually Is
Start by being fair to the system of record. Windchill is good at what it was built for: typed objects with controlled attributes, iteration and revision history, workflow-driven change, configurable lifecycle states, and attribute and keyword search across all of it. If you know the part number, Windchill hands you the part. If you know the attribute, a saved search hands you the set.
The gap is not storage and it is not governance. It is retrieval across object boundaries, and the reasoning that sits on top of it. Consider what an engineer actually asks at the start of a new design: has anyone here solved this before, and what did we decide? Answering means assembling the part, the CAD document defining its geometry, the change notice that released the current revision, the review comments attached to that change, and a load calculation someone filed separately three years ago. That is five object types, potentially in four contexts, each with its own permissions.
Windchill can show you every one of those if you already know what to ask for. Knowing what to ask for is the part that does not scale, and the part that leaves with the engineer who retires. So the category worth evaluating is not a better search box. It is an intelligence layer that reads across the object model and cites what it found. For the generic version of this framework across any PLM system, see our guide to evaluating an AI tool for PLM. What follows is the Windchill-specific cut.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
Question One: Does It Traverse Parts and CAD Documents as One Graph
This is the distinction that breaks the most tools, and it is specific to Windchill. A part in Windchill is a WTPart, a business object with its own attributes, structure and lifecycle state. The CAD file that defines that part is a different object entirely, a subtype of the EPMDocument type, which Windchill uses to manage parts, assemblies, drawings, layouts and manufacturing files. The two are associated, not merged.
The associations themselves carry information. PTC documents that an Owner association produces an EPMBuildRule link connecting the latest CAD document to the part, plus an EPMBuildHistory link for each iteration, while an EPMDescribeLink covers content associations between a WTPart and an EPMDocument. In other words, the history of which geometry built which part revision is recorded in the link structure, not in either object on its own.
Now picture a tool that indexes only one side. Index filenames and you return the drawing with no idea of the part's release state. Index WTPart attributes and you never see the geometry, so you cannot answer any question about shape, and reuse questions are almost always shape questions. This is where an intelligence layer earns its place rather than duplicating the vault: it has to read the part and the CAD document as one connected object and walk the links between them. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), sitting on top of those systems rather than replacing them, so one question can cross the boundary the object model draws. Our overview of AI for PLM search covers what that traversal looks like in practice.
Three things to demand in a demo, on your own data:
Ask which assemblies consume a given component, then ask for the current lifecycle state of each. A tool that answers the first and not the second is reading structure without reading the part object.
Ask for a part that resembles a shape you describe, then ask for the drawing that documents it. That requires both sides of the association.
Ask what the geometry looked like two revisions ago. That requires the iteration history on the build links, not just the latest file.
Question Two: Can It Read View Specific Structures and the EBOM to MBOM Handoff
Windchill does not keep one structure per product, and this is deliberate. The EBOM is the as-designed structure carrying the form, fit and function that define the product. The MBOM is the as-planned structure, the list of parts and quantities actually required to build it. They diverge for good manufacturing reasons: process-specific consumables, differently grouped subassemblies, phantom levels that exist only in engineering.
Windchill MPMLink is built around that divergence. It allows design engineers and manufacturing engineers to modify their respective bills of materials while maintaining associative equivalent links between the two, so a design change is communicated downstream rather than silently lost. The BOM Transformer exists to view and manage that structure and those associative relationships, with an upstream engineering BOM on one side and its downstream manufacturing BOM on the other.
Here is why that matters for an AI layer more than for a human. A human looking at a BOM knows which window they opened. A retrieval system that flattens both views into one index does not, and the questions engineers ask are exactly the ones where the difference decides the answer. How many of these do we buy? What does this assembly cost? How many levels deep is this structure? Each of those has two different correct answers depending on the view, and a tool that averages them produces a number that is wrong in a way nobody catches, because it looks plausible.
The test is simple and worth insisting on. Ask a quantity or cost question, and require the tool to state which view it answered from and cite the object. If it cannot name the view, it is not reading Windchill, it is reading a copy with the structure removed. For why the two structures diverge, see our walkthrough of the EBOM to MBOM handoff.
Question Three: Does It Understand the Change Object Network
The most valuable question in an engineering organisation is not what, it is why. Why is this wall 3 mm and not 2.5 mm. Why did we move to this supplier's connector. Why does this bracket carry a torque sequence note. In Windchill the answer to all three lives in the change record, not in the part.
Windchill implements a formal change process in five steps, each driven by an automated workflow. An issue is identified, typically captured in a problem report. One or more validated issues is then addressed by a change request carrying the technical and business justification. Change requests can run a simplified fast track workflow when the change does not affect orders, production or retrofits to fielded units, or a full track process when the change is complicated, costly or large in scope. Once accepted, a change notice records the implementation plan, made up of change tasks distributed to the people who update the documentation and capture the new configuration. Variances from specification are then handled through a deviation and waiver process.
PTC describes the four basic change objects as linked into a network that is created starting from the problem report and moving toward the change task, then resolved in the opposite order. That structure is the reasoning chain your organisation already wrote down. Read forward and you get the justification for a decision. Read backward and you get its consequences.
A tool that indexes only the current iteration of each part can tell you the state of the design and nothing about its rationale. Ask a candidate why a specific dimension changed, and grade the answer on whether it cites the change object rather than paraphrasing the drawing note. Our piece on engineering change order automation covers where the time in that chain goes.
Question Four: Does It Inherit Domain Policies and Lifecycle States
Windchill access control is more granular than most retrieval tools are designed to respect, and getting this wrong is the fastest way to end a pilot. An access control rule for a domain is a mapping between an object type, a lifecycle state, a participant and their associated permissions. So a rule can grant the Publications group read access to a document type in the Engineering domain only while it sits in the Under Review state, and deny it elsewhere.
Two kinds of inheritance compound that. Domains are hierarchical, so rules defined for a domain are inherited by descendant domains. Types are hierarchical too, so an object inherits rules from its ancestor types, meaning more than one rule can apply to a single object. The ACLs actually enforced are derived from a domain's policy plus the policies of all its ancestor domains, used alongside ad hoc ACLs on specific objects. Participants can be individual users, groups, dynamic context and organisation roles, pseudo roles, or whole organisations.
The requirement that follows is strict: an AI layer has to resolve permissions at query time, per user, per object, per state, and return nothing the asking engineer could not already open. Anything that pre-builds one flat index for everybody has quietly created a second copy of your vault with none of your rules on it. That is a compliance problem before it is an engineering one. On the connection side, ask how a vendor actually reads Windchill. Windchill REST Services is the module that configures OData services in Windchill, OData being an OASIS standard for RESTful data access, and its API catalog is a Swagger specification of the available endpoints. A vendor who can name the endpoints they read is describing an integration. One who cannot is describing an export. For the wider picture, see our piece on engineering knowledge graphs.
A 30 day evaluation that produces evidence rather than impressions:
Write 25 questions from your last two release cycles before you see any demo, including five you already know are hard.
Run all of them against your own Windchill data, not a sample vault, and score each answer as correct, incomplete or wrong.
Require a citation you can open for every answer, and check the cited object actually supports the claim.
Repeat the five hardest questions as two users with different permissions, and confirm the answers differ where your ACLs say they should.
Record time to answer alongside accuracy. An answer that arrives after the design review is not an answer.
On the security review running in parallel, the baseline to ask any vendor for is the one we hold ourselves to: SOC-2 certified, GDPR compliant, no AI trained on customer data, and your intellectual property protected.
FAQ
Test these four criteria on Windchill
Bring 25 real questions and run them against your own vault
Leo reads across the PLM and PDM data you already have and answers engineering questions with citations back to the source object, so your team can grade it on parts it knows.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
