AI and the New Intelligence Layer for Product Data

Product data is the layer that tracks what a physical product is, why it was designed this way, and how it changes over time. In theory, PLM and digital thread systems should connect requirements, BOMs, CAD files, test results, design decisions, and compliance documents. In practice, this data is often fragmented across tools and teams. In this landscape, I looked at the new generation of startups using AI to make product data more searchable, connected, and useful, from engineering knowledge graphs and AI-native PLM to requirements traceability, engineering memory, and lifecycle intelligence.

How do Product Data, PLM, and Digital Thread workflows traditionally work?

• At a basic level, a physical product is not only a CAD file. It is also a set of requirements, a bill of materials (BOM), design decisions, change requests, supplier choices, test results, compliance documents, and manufacturing instructions. This is what makes product data so important. It is the memory of how the product was designed, why it was designed this way, and what needs to be true for it to be built correctly.

• This is the role PLM is supposed to play. Product Lifecycle Management tools are meant to be the system of record for the product. They help companies manage versions, parts, BOMs, approvals, changes, and documentation. In theory, PLM should connect the product from early definition to manufacturing and later support. In practice, it often becomes a heavy backbone that only a few specialists really understand.

• The difficulty is that product data is distributed by nature. Requirements may live in one system, CAD in another one, test data somewhere else, and supplier information in ERP. On top of that, many decisions still happen in documents, spreadsheets, email threads, review meetings, or PDFs. So even when a company has a PLM system, the full product story is rarely in one clean place.

• A lot of engineering work is spent searching and reconciling information. Engineers need to find the right version of a file, understand why a change was made, check whether a requirement is covered, or compare what was planned with what was tested. This work is not always visible, but it is central to product development. The bottleneck is often not that the data does not exist. It is that the data is hard to find, hard to trust, and hard to use.

• But this is also why replacing PLM directly is difficult. Incumbent systems like Teamcenter, Windchill, ENOVIA, or SAP PLM are deeply embedded. They contain years of processes and approvals. Large manufacturers are unlikely to rip them out quickly. So the startup opportunity is less about “new PLM replaces old PLM” and more about creating a smarter layer around existing product data.

What does the new generation of Product Data, PLM & Digital Thread AI bring?

• The main direction is not to replace PLM directly, but to build intelligence layers around fragmented engineering data. This is the most important point for me. The incumbents still own the systems of record, but the new startups are trying to make the data inside and around these systems easier to search, connect, and use.

• The first product pattern is engineering knowledge graphs and product twins. The idea is to create a connected representation of the product, instead of leaving every piece of information in a different tool. SPREAD is the clearest example here. It connects data from PLM, CAD, ERP, and ALM into an engineering ontology and product twin. Flow Engineering also fits this direction with its living system of record across requirements, CAD, simulation, code, and test.

• The second pattern is AI-native PLM and BOM intelligence. Some startups are closer to the core product data workflow: parts, BOMs, versions, approvals, and change management. Duro, Bild, oroForge, and Cognyx fit here. Duro and Bild are modern PLM/PDM challengers. oroForge is a lighter PLM for hardware startups. Cognyx is more focused on the BOM itself, turning it from a static list of parts into a more collaborative and intelligent product object.

• The third pattern is requirements and traceability. This is one of the most obvious AI entry points because requirements are still often trapped in documents and disconnected from execution. Trace.Space, Flow Engineering, portal0, Cadenza, and Ketryx all attack this problem from different angles. Trace.Space builds a traceability graph and an AI agent for systems engineers. portal0 turns specs and legacy documents into structured requirements. Cadenza works as an AI layer on top of existing ALM tools. Ketryx applies the same traceability logic to regulated product development.

• The fourth pattern is design intent and engineering memory. A lot of valuable engineering knowledge is created during design reviews, trade-off discussions, and decision making, but then disappears into documents. CoLab and Tandem are strong examples here. CoLab captures review feedback and product decisions. Tandem focuses more on design intent, requirements, and the reasoning behind hardware decisions. Both are trying to make engineering memory reusable.

• The fifth pattern is simulation and test data infrastructure. Simulation results and physical test data are part of the product story too. Monolith AI and Miura Simulation are the two examples in this landscape. Monolith applies AI to test and validation data to reduce physical testing and guide design decisions. Miura focuses on making simulation data cleaner, reusable, and ready for AI workflows.

• The sixth pattern is lifecycle intelligence around cost, carbon, compliance, and supply chain. This is where product data becomes useful beyond the engineering department. Makersite is the clearest example. It connects product data with sustainability, cost, compliance, and supplier-risk information. Ketryx also fits this broader lifecycle view, but from the regulated compliance angle. The common idea is that the product record becomes a decision layer, not only a documentation layer.

• Overall, the category is moving from product data as storage to product data as intelligence. PLM traditionally answers the question: “what is the official record?” These new products try to answer more active questions: what changed, what is impacted, what is missing, what can be reused, and what should happen next? This is why I think the category is important. It is not only making PLM nicer. It is making engineering knowledge operational.

Investment & Acquisition environment

• The funding environment is already mature. There are already several companies with meaningful institutional funding: CoLab, Makersite, SPREAD, Ketryx, and Flow Engineering. 

• The more mature companies are usually the ones that found a clear enterprise pain point before expanding into the broader digital thread story. CoLab started from design reviews. Makersite started from sustainability and product lifecycle intelligence. Ketryx started from regulated compliance. SPREAD started from engineering intelligence for complex products. They all have a concrete entry point.

• There is also a strong “systems of record vs systems of intelligence” investment logic. PLM incumbents own the official product record, but startups are trying to own the intelligence layer around it.

• The seed layer is still very active. Trace.Space, Miura, Tandem, Cognyx, and Bild show that new entry points are still being explored. This makes sense because product data is not one workflow. Requirements, BOMs, test data, design intent, and simulation data are all different entry points into the same broader problem. I would expect more startups to appear in these sub segments.

• Founder market fit looks especially important here. Many founding teams come from mechanical engineering, aerospace, automotive, simulation, regulated software, or product development. The companies that win likely need deep domain credibility.

• The acquisition environment is already visible, which is another sign that the category matters strategically. Duro was acquired by Altium, and Monolith AI was acquired by CoreWeave. These are two different acquisition paths. Duro fits the classic engineering software consolidation logic. Monolith is more surprising because CoreWeave is an infrastructure company, but it shows that engineering AI capabilities may matter beyond traditional PLM incumbents.

• I would expect more acquisitions from engineering software incumbents over time. Siemens, Dassault, PTC, Autodesk, Ansys, Cadence, Synopsys, Altium, and others all have reasons to care about this layer. If AI becomes the interface through which engineers search, validate, and act on product data, incumbents cannot let that layer sit entirely outside their platforms.

• The big open question is whether these startups become standalone platforms or acquisition targets. The answer probably depends on where they sit. A narrow workflow that improves a specific PLM or CAD process may be acquired. A company that becomes the cross-system intelligence layer for engineering data could become much more strategic.