AI for Engineering Knowledge Management
What an AI assistant reaches inside Autodesk Upchain: items, revisions and versions, project BOMs and change requests, and where the CAD geometry stops.
·
⏱
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
Upchain is unusually friendly to retrieval, because it writes down the things most systems leave implicit: the structure of the product, the approval state of every item, and the separation between a revision that was released and a version somebody is still editing. An assistant that respects that model answers traceability and history questions well, and it answers them with a record you can open. The limit is geometry. Item attributes describe a file, not what is inside it, so wall thickness, draft, hole patterns and drawing callouts stay out of reach of anything that only reads records. Evaluate on your own data, ask at least one question that can only be answered from the model, and treat an answer with no citation attached as an answer you have not actually received.
Autodesk Upchain is the third Autodesk data product a lot of engineering teams run without much guidance on what an AI assistant can actually do with it. Vault keeps files and items on infrastructure you own. Fusion Manage organizes records into workspaces. Upchain sits somewhere else again: a cloud system that registers CAD from several different applications, builds a bill of materials out of what it finds there, and moves items toward release with revisions and versions counted separately.
That structure is good news for retrieval, because most of what an engineer needs to know is already a record rather than a buried file. It is also where the confusion starts, because the thing an engineer calls a part is not the thing Upchain calls an item. This is what an agent reaches across Upchain data in 2026, and what it does not.
What Upchain Actually Stores
Upchain is organized around the item, and Autodesk's own training material defines an item as a level within the bill of materials rather than as a file. Each item, in Autodesk's wording, contains item attributes, CAD files, translations, documents and markups. One item can therefore gather several CAD files, a viewable translation of each, a specification PDF, a supplier note and a markup thread, all under a single record that the rest of the business can refer to.
An item is identified by three things together, not one: the item number, the major and minor revision, and the item version number. Every item also carries a release status, and Autodesk documents three of them. Development means the item is editable. Pending means it is locked from editing. Released means it is locked except for a small set of attributes and has been formally approved.
CAD gets into that structure through the Upchain CAD Connector, which Autodesk describes as the hub from which you launch the plugin for supported CAD applications and the Generic plugin. The connector detects the CAD applications installed on a machine and lists a plugin for each one it supports, with Siemens NX, Autodesk Inventor, AutoCAD, SOLIDWORKS and PTC Creo all named in the documentation. From inside CAD, an engineer registers files into a project, associates them with bill of materials items, downloads in read-only mode or checks out in write mode.
So before any assistant is involved, three things are already true of a team running Upchain:
The structure of the product is a record, not an inference drawn from a folder tree.
The approval state of every item is written down rather than remembered.
CAD from more than one application can hang off the same item.
All three matter, because they decide what a retrieval layer can answer without opening a single model.
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
Revisions, Versions and Why Retrieval Gets Hard
The single most useful thing to understand about Upchain data, and the thing that trips up most search, is that revisions and versions count different events. Autodesk puts it plainly: revision numbers only change when the item is released, indicating it has been formally approved. Version numbers move during development. And to begin a new revision of a released item, a new item version must be created, which arrives in a development state.
That is a clean model, and it means a question as ordinary as "what is the current bracket" has at least three defensible answers at any moment. There is the latest released revision, which is what manufacturing is entitled to build. There is the latest item version, which is what the designer is working in and which nobody downstream should be quoting. And there is whatever revision is sitting on the project BOM a buyer priced from three weeks ago. All three are correct answers to different questions, and a keyword search that returns the newest record returns the wrong one roughly two times in three.
The BOM views compound this. Upchain training material distinguishes the project BOM from the cBOM and the eBOM, and an engineer moving between them is moving between three legitimate pictures of the same product. Layer change requests on top, where items are sent to a change request and the workflow completing is what releases the item, and the honest description of Upchain is not that the data is messy. It is that the data is precise in a way that punishes imprecise questions. The same trap shows up in every system that separates the record of a change from the thing being changed, which we worked through in detail in our piece on the engineering change order data model.
What an Agent Reaches Across Upchain Data
Because Upchain keeps so much as structured records, a retrieval layer sitting over it reaches further than it would over a plain file store. The parts of the system that answer well are the parts that were written down on purpose:
Item attributes and release status, which answer whether something is approved to build and who last touched it.
BOM structure in both directions, so that where-used questions are as cheap as what-is-in-this questions.
Change request history, which is the only durable record of why a design is shaped the way it is.
Non-CAD documents attached to items, where the specifications, test reports and supplier correspondence actually live.
Markups and investigation requests, which capture the disagreement that preceded a decision.
The fifth one is the quiet prize. A released revision tells you what was decided. The markup thread and the change request behind it tell you why, and that is the knowledge that leaves when an engineer leaves. An assistant that can retrieve it turns a question that used to need a meeting into one that needs a sentence, which is the same argument for putting a layer over any PLM system rather than migrating off it.
Leo is built for this shape of problem. It offers integrations with leading PDM and PLM platforms, including SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM and others, alongside local and network directories and ERP, and it reads the records and the files behind them rather than only their titles. Every answer comes back with the internal source attached, so an engineer can open the item or the document and check it instead of trusting the summary. It is SOC-2 certified and GDPR compliant, no customer data is used to train the models, and your intellectual property stays yours. The point is not to replace the system of record. The point is to read what your team already maintains, which is the same reasoning behind treating BOM management as a retrieval problem first.
Where the CAD Geometry Still Sits Outside
Here is the limit worth being honest about. Upchain holds CAD files and their viewable translations against items, and it manages those translations as a documented part of the system. But the record layer describes the file. It does not describe the geometry inside it.
An item attribute can tell you the part number, the material field somebody typed, the release status and the revision. It cannot tell you the minimum wall thickness, whether the draft angle clears the tool, how many of the sixteen holes share a pattern, what thread is cut into the boss, or what the feature control frame on the drawing demands. None of that is an attribute. It is geometry and annotation, and it is sitting inside a file that the record merely points at.
This produces a useful test when a vendor demonstrates anything to you. Ask a question whose answer is only inside the model, not in any field. Ask which parts in this assembly have a feature that cannot be machined in one setup. A tool reading records will answer confidently and generically. A tool reading geometry will answer specifically or say it cannot. The same split decides what is possible over Autodesk Vault, where the file and item divide is explicit, and over Fusion Manage, where the records are rich and the native geometry stops at the workspace boundary.
Neither half is the whole job. A metadata layer that cannot read geometry will never answer a design question. A geometry reader with no access to release status will happily describe a part that was superseded two revisions ago. What an engineering team needs is one assistant that holds both at once, and the honest way to evaluate any tool for Upchain in 2026 is to find out which half it is quietly missing.
How to Evaluate an AI Tool for Upchain in 2026
Most evaluations go wrong by testing retrieval on questions the team already knows the answer to. These six hold up better, and each one maps to something specific in the Upchain data model:
Ask for the current released revision of a part that has an item version open in development. A tool that returns the development version has not understood that revisions only move on release.
Ask a where-used question about a fastener that appears in several assemblies. This tests whether BOM structure is being traversed or whether the tool is matching strings in part names.
Ask why a change was made, not what changed. The answer should come from a change request or a markup thread, with the record cited.
Ask something that lives only in an attached PDF specification rather than in any item attribute, and check whether the tool opened the attachment or guessed from the title.
Ask a question whose answer is only in the geometry, and watch whether the tool admits the limit or invents a number.
Ask the same question twice, a week apart, after someone has released an item in between. Consistency over time is what separates a retrieval system from a demonstration.
Run those against your own data, not a sample set. A tool that handles the first three is a competent record reader and will save a team real hours on traceability. A tool that handles all six is reading the files as well as the records, and that is the difference between faster lookup and faster engineering.
One more practical note. Because Upchain registers CAD from several different applications into the same structure, any assistant you put over it needs to stay useful when the assembly in front of it mixes files that came in through different plugins. Ask to see that case specifically. It is common in real Upchain tenants and it is rarely in the demonstration.
FAQ
Put an assistant over your Upchain data
One question, one answer, drawn from your items, BOMs and change requests.
Leo connects to the PDM and PLM platforms your team already runs, reads the records and the files behind them, and attaches the internal source to every answer.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
