AI for Engineering Knowledge Management
What a hardware-first PLM exposes to an AI agent: Duro's GraphQL record layer, the BOM and change-order detail it returns, and the CAD geometry that stays outside it.
·
⏱
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
Duro being built for hardware teams and exposed through a single GraphQL interface makes its product data genuinely reachable. Components carry explicit state, assemblies carry typed BOM lines with quantities and reference designators, part numbers are generated and validated for uniqueness, and the change order lifecycle emits events granular enough to reconstruct an approval. An assistant working over that layer can answer structural and sourcing questions without inference. The boundary is not a quota or a pricing tier. It is that CAD files sit in Duro as attachments with metadata, so every question whose answer lives inside the geometry falls outside what any PLM query returns. Closing that gap is a retrieval problem solved on top of the PLM, not a reason to move off it.
Duro describes itself as an AI-native, API-first PLM platform built for hardware engineering teams. For anyone working out what an AI assistant can actually do on top of it, that one sentence decides most of the answer.
A PLM system's usefulness to an agent has little to do with how much data it holds. It depends on how much of that data is addressable: queryable by a machine, carrying stable identifiers, explicit relationships, and a revision history that can be traversed rather than guessed at. This post looks at what a hardware-first PLM exposes, what an assistant can answer from it, and the one category of question that no amount of record access will cover.
What Building for Hardware Teams Changes
Most PLM systems grew up around large discrete manufacturing and were adapted to smaller hardware teams later. Duro was written for those teams from the start, and the consequences show up in its data model rather than in its marketing.
The clearest one is BOM scope. Duro's own description is that it combines bills of materials from mechanical, electrical, industrial and manufacturing disciplines into a single structure. For an assistant, a combined BOM means one traversal answers a question that would otherwise need three systems reconciled by hand first. Asking which parts in a released assembly carry a long lead time does not require someone to merge a mechanical BOM with an electrical one before the question can even be posed.
The second consequence is that part records are populated for procurement, not for drawing release. Duro publishes a short list of what it treats as the minimum a bill of materials needs: part name, customer part number, quantity, manufacturer, and manufacturer part number. That list is deliberately procurement-shaped. Its own framing is that someone unfamiliar with the product should be able to buy the right parts in the right quantities with nothing but the BOM and a credit card.
That matters more for retrieval than it first appears. An assistant answering a sourcing question is only as good as the fields that are actually filled in. A record layer that treats a manufacturer and an MPN as part of a complete line produces far fewer dead ends than one where those fields exist but are usually blank.
IN PRACTICE
We've started reusing parts we didn't even know we had, and that has real downstream impact on procurement and BOM costs.
- Verified User, Defense & Space
The Record Layer an Agent Can Reach
Duro exposes a GraphQL API, and its stated position is that every core object and workflow in the product is available through the same interface that powers the application itself, with no read-only tier and no separate enterprise gate. Its own phrasing is that if you can do something in the interface, you can do it programmatically.
The shape of that API matters as much as its coverage. A component carries an id, a name and description, a revision value, a version counter, a state of either released or modified, a status, and a category whose type is part, assembly or document. Category-specific data sits in attribute values, validated against rules the category defines.
Assemblies are components whose category type is assembly, and the bill of materials hangs off them as children. Each BOM line carries the child, a quantity, a reference designator, an item number and notes. Sourcing lives in its own area, where manufacturer part numbers, distributor part numbers and primary-source ranking are held against the component.
Three properties of that layout do real work for an assistant:
Relationships are explicit. A BOM line is a typed edge carrying a quantity and a reference designator, not a row in a spreadsheet that happens to sit under a heading.
State is a field rather than an inference. Released and modified are readable directly, so an answer can be scoped to what is genuinely released without reading a workflow log and interpreting it.
One query can cross structures. Duro's own description of the benefit is traversing BOMs, revisions and change orders in a single query, which is what stops an agent stitching four paginated calls together and introducing drift between them.
That layer is the difference between a PLM an assistant can work over and one it can only sample. The wider comparison of what different systems expose sits in our guide to the best AI tool for PLM in 2026.
Why Part Numbering Decides the Quality of the Answers
Duro generates customer part numbers from a configurable scheme rather than leaving them to be typed in, and it validates a proposed number before it is committed, reporting whether the result is deterministic and whether it is unique.
Those two flags are quietly important. Determinism means the same inputs always produce the same number, so an identifier can be reconstructed rather than looked up. Uniqueness means a number resolves to exactly one record, which is the precondition for any answer that claims to be about a specific part.
Where identifier hygiene breaks down, retrieval degrades in a recognizable way. An assistant asked how many distinct fasteners a product uses will return a count that is too high, because the same fastener was entered three times under three numbers. The answer is not wrong because the model reasoned badly. It is wrong because the data says there are three parts. We have written about the trade-offs between numbering schemes in our comparison of intelligent and non-significant part numbering, and about matching an incoming number against what is already on file in our piece on supplier part number cross-referencing.
Revision values follow the same pattern. Duro builds them from configurable segments, letters or integers, combined with delimiters, so a value such as A.1 or B.2 has a defined structure rather than a convention someone remembers. A structured revision value can be compared and sorted. A free-text one has to be interpreted, and interpretation is where an assistant starts guessing.
Change History an Agent Can Follow
Change orders in Duro are first-class records moving through a staged workflow, and the events they emit are specific enough to reconstruct what happened without polling for it.
Its webhook catalogue covers component creation, update and deletion, then the change order lifecycle in detail: opened, updated, deleted, stage transition, individual reviewer decision, resolution, and closed. A reviewer approving at one stage is a distinct event from the change order reaching a final resolution, and both are distinct from the order closing.
For an assistant, that granularity is the difference between two kinds of answer. Coarse events support "this part changed last Tuesday". Granular ones support "this part changed last Tuesday, it was approved by two of three reviewers at the engineering stage, and it closed four days later". The second is the answer the engineer was actually asking for.
The same granularity makes an assistant's account of history reported rather than reconstructed. When approval state and stage transitions are readable as records, an agent repeats them. When they are not, it infers them from timestamps and comment threads, and inference is where confident, wrong answers come from. What a change record has to carry before any of this works is set out in our piece on the engineering change order data model.
Where Geometry Still Sits Outside the Record
Everything above describes structured records. The limit of a hardware-first PLM, and of every PLM, is that the design itself is not one.
Duro attaches files to components through direct file references and a documents array, and it records which document formats a component generates, described as the derived files a CAD integration produces. It offers integrations with SolidWorks, Onshape and Altium 365. So the CAD file is in the system, associated with the right component at the right revision.
What it is not is readable. The record layer knows that a file exists, what it is called, which component it belongs to and which revision it arrived at. It does not know what is inside it. No query against a component returns the wall thickness of the part, which features changed between revision A.1 and A.2, or whether two components in different categories are the same bracket at two lengths. The file is an attachment with metadata, and metadata about geometry is not geometry.
That gap is the one an intelligence layer has to close, and it is why Leo is built to sit on top of PDM and PLM rather than replace either. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), and reads across both the structured records and the documents and geometry those records point at, returning a citation with each answer. The PLM stays the system of record. Questions that need the contents of a file, rather than the row describing it, stop being unanswerable, which is also what turns part reuse into something measurable. We cover that side in our guide to the best AI tool for BOM management in 2026.
FAQ
See what Leo reads from your PLM
A walkthrough on your own part data, with a citation on every answer.
Bring a released assembly and the CAD files attached to it. We will show what a retrieval layer returns from inside those files, and which record each answer came from.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
