AI for Engineering Knowledge Management
An engineering knowledge graph links parts, BOMs, documents, and suppliers so AI can answer multi-hop questions across siloed PDM, PLM, and ERP data.
·
⏱
9 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
Your product data is not missing, it is disconnected. An engineering knowledge graph stores the relationships between parts, assemblies, documents, suppliers, and requirements, which is what turns a pile of searchable files into something that can answer a real question. It does not replace PDM or PLM. It reads them and records how their contents relate, including across system boundaries no single tool owns. AI makes it practical by extracting relationships at scale, resolving the same part across three naming schemes, and keeping the result current. Start with one question that costs measurable time, connect only the systems holding that answer, fix part identity first, and insist on citations so every answer can be audited. Expand question by question. The organisations getting value from AI in engineering are the ones that gave it a structure to reason over.
An engineer asks a simple question: can this bracket get thicker without breaking anything downstream? The answer already exists inside the company. Part of it sits in the CAD model. Part of it sits in a released BOM. Part of it sits in a supplier agreement in the ERP system, a qualification report in a network folder, and a decision someone made in a design review three years ago. Every piece is available. None of the pieces are connected.
That gap is what an engineering knowledge graph is built to close. Instead of storing product information as isolated files and rows, a graph stores the relationships between them, so a question can travel from a part to its assemblies, from those assemblies to their suppliers, and from there to the standards the design has to satisfy.
The reason this matters more in 2026 than it did five years ago is AI. Language models answer engineering questions well when the underlying data explains how things relate to each other, and badly when it does not. A model pointed at a pile of disconnected documents produces confident summaries of the wrong document. The same model pointed at a structured set of relationships can show its work.
This guide covers what a knowledge graph is in engineering terms, why product data fragments in the first place, which questions become answerable, and how to start without committing to a two-year data program.
What an Engineering Knowledge Graph Actually Is
A knowledge graph stores two things: entities and the typed relationships between them. In engineering, the entities are the objects you already work with. Parts. Assemblies. Drawings. Materials. Suppliers. Requirements. Test results. Change orders. The people who approved them.
The relationships are the part most systems throw away. A bracket is used in four assemblies. It supersedes an earlier revision. It is made from a specific alloy that has an approved-source list. It satisfies a load requirement that traces back to a customer specification. It was released under a particular ECO, and an alternative design was rejected during that review. Each of those is a named, directional link between two entities.
The contrast with the storage models engineers live in every day is what makes the idea concrete. A folder tree gives every file exactly one parent, which is why a part used in three products has to live somewhere arbitrary. A relational table can express relationships, but only the ones someone anticipated when the schema was designed, and crossing five of them means writing five joins. A graph treats the relationship as a first-class object, so traversing from a part to its suppliers to their qualification records is a walk across edges rather than a schema change.
Two clarifications matter before anyone starts a project. First, a knowledge graph is not a replacement for PDM or PLM. Those systems remain the source of truth for vaulting, revision control, and the release process. The graph is a layer above them that reads their contents and records how those contents relate, including relationships that cross system boundaries.
Second, a graph is not the same thing as a vector index. Embeddings are good at finding text that resembles other text, which is useful and insufficient. Similarity does not tell you that the document you just found was superseded eighteen months ago. Structure does. In practice the two work together: similarity to find candidates, the graph to establish which candidate is current, released, and relevant.
IN PRACTICE
It surfaces the relevant internal material, previous design decisions, past calculations, and backs everything with a cited source I can actually click on and verify.
- Yuval F., Clalit
Why Product Data Ends Up Siloed in the First Place
Fragmentation is rarely the result of negligence. It is the result of each system being bought to do one job well. A PDM vault exists to control files and revisions. A PLM system exists to run change and release. An ERP system exists to manage cost, procurement, and inventory. Simulation results live wherever the analysis tool wrote them. Older programs sit on a network directory that predates all of it.
Four structural causes turn that reasonable history into a daily problem.
Different identity schemes. The same physical part is a file name in the vault, an item number in PLM, and a purchasing record in ERP, with no reliable key connecting the three.
Relationships that were never modeled. A BOM knows which parts are in an assembly, but nothing records that a qualification report, a supplier deviation, and a tolerance study all describe that same part.
Migration debt. Acquisitions, tool changes, and vault consolidations leave several generations of naming conventions coexisting, each internally consistent and mutually unintelligible.
Knowledge that never entered a system at all. The reason a wall thickness is 3.2 mm rather than 3.0 mm often exists only in the memory of the engineer who made the call.
The cost shows up as search time. Engineers rediscover parts that already exist, repeat analyses that were already run, and make decisions without the context that would have changed them. We have written before about the real cost of bad PDM search and about capturing tribal knowledge before it walks out the door, and both problems have the same root: the information is present, and the connections are missing.
This is also why data cleanup projects tend to stall. Cleaning each system individually improves each system individually. It does not create the cross-system links that the hard questions depend on, because no single system was ever responsible for holding them.
What a Graph Lets You Ask That a Search Box Cannot
The practical test of a knowledge graph is whether it answers multi-hop questions: questions where the answer requires following a chain of relationships rather than matching a phrase. Five classes of question account for most of the value.
Impact. Which assemblies, drawings, fixtures, and machining programs are affected if this component changes? This is the question behind every change order, and getting it wrong is expensive in a way that only surfaces later. A structured where-used and impact analysis is the canonical graph query.
Reuse. Has something functionally equivalent already been designed, approved, and stocked? Answering it means combining geometric similarity with release state and supplier availability, which is the intersection of part reuse and engineering search.
Traceability. Which requirement, standard, or test result justifies this dimension or material choice, and is that justification still current?
Provenance. Who approved this, under which change order, and what alternative was considered and rejected at the time?
Concentration risk. Which released products depend on a single supplier, a single approved source, or a component heading toward end of life?
A keyword search cannot answer any of these, because each one requires knowing what a result is connected to, not merely that a phrase appears in it. Search returns documents. A graph returns a path.
The path is the underrated part. When an answer arrives as a chain of records, an engineer can audit it: this part, in this assembly, released under this ECO, sourced from this supplier, qualified by this report. Every hop is a record someone can open. That auditability is what separates an answer an engineer will act on from a plausible paragraph they have to verify by hand, which is the failure mode that quietly kills trust in AI tooling.
How AI Builds and Maintains the Graph
Building a graph by hand is not realistic at the scale of a real product portfolio. Nobody is going to hand-label the relationships between a hundred thousand parts and the documents that describe them. This is where AI earns its place, in three distinct jobs.
The first is extraction. Structured sources give up their relationships readily: BOM structures, assembly mates, feature trees, title blocks, ECO records, and purchasing tables all encode links that only need to be read and normalised. Unstructured sources are harder and more valuable. Qualification reports, deviation notices, supplier emails, and design review notes contain relationships stated in prose, and a language model can propose typed links from that text for review.
The second is entity resolution: deciding that the file in the vault, the item in PLM, and the purchasing record in ERP describe one physical part. Names will not carry this. Geometry sometimes will, which is why shape-based comparison matters for parts that share no naming convention, alongside attribute matching on material, mass, and dimensional signature.
The third is maintenance. A graph built once is wrong within a quarter. Useful implementations stay connected to their source systems and update as those systems change, rather than running as a one-time extraction into a separate database that immediately begins to drift.
This is the layer Leo AI is built to be. Leo is an AI assistant for mechanical engineers, trained on more than a million pages of standards, books, and technical articles, and it connects to an organisation's own knowledge base: PDM, PLM, local and network directories, and ERP. Leo offers integrations with leading PDM and PLM platforms, including SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, and Arena PLM, among others. It sits on top of those systems rather than replacing them, which is the same architectural point covered in our guide to how AI CAD tools integrate with PLM and ERP.
Two properties decide whether engineers keep using it. Answers carry citations back to the source record, so a claim about a tolerance or a material property can be checked rather than trusted. And the data stays protected: Leo is SOC-2 certified and GDPR compliant, no AI is trained on customer data, and customer intellectual property remains the customer's.
How to Start Without a Two-Year Data Project
The most common way this initiative fails is ambition. A team decides to model the enterprise ontology first, spends nine months in workshops defining entity types, and delivers a diagram. The alternative is to start from a question that already costs measurable time and let the model grow behind it.
Pick one expensive question. Where-used analysis and duplicate part detection are the usual first choices because both have a cost anyone can quantify.
Connect only the systems that hold that answer. Two or three, not all of them. A graph covering part of the estate that answers a real question beats complete coverage that answers none.
Fix identity before anything else. One resolvable identifier per physical part, mapped across systems, is the foundation everything else sits on.
Model a small set of relations. Five to eight typed edges cover most of the first use case. Resist the temptation to define fifty.
Require citations on every answer, and track how often engineers accept them. Acceptance rate is a better health metric than graph size.
Expand by question, not by system. Each new question tells you which entities and edges are actually worth adding.
Measure the things the business already tracks: time to find a released part and its context, the rate at which new part numbers are created for components that already existed, and change order cycle time. Graph node counts impress nobody and predict nothing.
One organisational point is worth stating plainly. This is not purely an IT project. The typed relationships that make the graph useful encode engineering judgement about what depends on what, and that judgement lives with the engineers. Teams that treat it as a data migration produce a technically correct graph nobody queries, and the fix is not more modelling but putting the engineers who hold the judgement in the room while the relations are defined.
FAQ
Connect Your Engineering Knowledge
See how Leo answers engineering questions across PDM, PLM, and ERP data.
Leo AI connects to your existing product data and answers technical questions with citations you can verify, so engineers stop hunting through disconnected systems.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
