I continue my article series about IFIP PLM 2026 in Lecce, Italy. If you missed my previous articles, check them out here: [IFIP PLM 2026 in Lecce: Digital Thread, AI, and a Community Thinking About What Comes Next] and [40 Years of PLM: From Documents to Intelligence — Martin Eigner’s Pioneer Keynote at IFIP PLM 2026].
Today I want to share my own keynote, “From CAD Files to Product Memory”: the argument behind it, and the reaction from the industrial and academic community. I also want to share the announcement I made at the end: my upcoming book on Product Memory.
Where Does It All Start?
It starts with a childhood memory of my father, who managed a team of engineers in the design office of a metallurgical factory in the Soviet Union. I remember that place: design blueprints and drawing boards. I also remember asking my dad how they did this work, and he explained it to me: projects, engineers working on specific designs of heavy machinery, and how the projects were managed together by people remembering what they did, what the requirements were, what the issues were, and many other things that needed to be clarified before a specific piece of machinery would be assembled and installed in the factory.
When they came back to a specific project for adjustments or changes, they were able to find project drawings and blueprints, but they also remembered what changed, why they made specific decisions, and what deviations were made because of some infrastructure, equipment, or process constraint. This is a human memory of when a change happened and why.
I see the same thing happening in organizations today. A change is triggered by customer support: field reports come in about a component. Support escalates. Engineering investigates. A supplier change in ERP, a contractor’s redesign in an Excel file, an ECO in PLM, decisions in meeting minutes and message threads. A year later, someone asks two questions: when did this change happen, and why?
When is easy. Every system has a timestamp. Why is gone, unless you can find the engineers and records related to this specific question. Those records “sit” in different systems, and also in the memory of multiple people across the organization.
That story is the whole story. Its conclusion, and the thesis of the keynote:
A product is not its files. A product is everything an organization remembers about how and why it came to be.
For fifty years, our field has run on a quiet assumption: capture the artifacts, and you have captured the product. The drawing, the model, the BOM, the ECO. Capture them, control them, and the product is preserved. This is the whole story of the Single Source of Truth.
That assumption fails, because there is no single source of truth, and the why does not live in any artifact. The data is siloed, and the why lives in the connections between artifacts, and in the people who carry those connections in their heads. The systems hold the fragments. The people hold the connections.
The Archipelago, and Two Failure Modes
Look at the history of our tools as a sequence of genuine victories. CAD took geometry off the drafting board. PDM took the chaos of files and versions under control. PLM connected records and processes. Then came ERP for the business, MES for the shop floor, support systems, procurement, and project tools. And underneath everything, the unofficial infrastructure that never appears on architecture diagrams: Excel, email, chat.
Every generation solved a problem. Every generation added a silo.
So the real landscape of a manufacturing organization is not a pyramid with PLM at the center. It is an archipelago. The memory of the product is distributed across the islands and, critically, across the water between them: the exports, the handoffs, the conversations where one system’s data was translated into another system’s terms.
The memory gets lost in exactly two ways. Failure mode one: the connections are never made. The field report in the support system and the ECO in PLM are the same story, but no system knows that. Each system faithfully records its fragment and is structurally blind to the rest. Nothing was deleted, but a memory that exists only in disconnected fragments is not a memory. It is an archaeology site.
Failure mode two: context is destroyed in transit. Every time product data crosses a boundary (engineering to procurement, EBOM to MBOM, your systems to your contractor’s systems), a human bridges the gap by hand. Export, re-key, reformat, email a spreadsheet. The number survives the crossing. The reason does not.
The key point: neither failure mode is an implementation problem. Implement every system perfectly, by the book, and both run at full strength, because every system is doing exactly what it was designed to do.
Why Single Source of Truth Was Never the Answer
For the last 30+ years, the industry has lived with the promise of a single source of truth. Here is the evolution I presented in my keynote. It evolved, but it never achieved the result.
Here is my conclusion: there is no single source of truth. I argued that SSOT cannot work. Not that it is hard, but that it is structurally impossible, for two reasons. First, you cannot put all the data in a single database even if you genuinely want to. The why of a change lives in field reports, meeting minutes, Excel files, message threads, negotiations. What schema holds a negotiation? Second, no product today is built by one organization. A single authoritative database spanning all trace types and all organizations in a product network has no counterexample in the real world, and never will.
Fragmentation is a structural reality of every engineering and manufacturing organization.
The truth about a product was never going to live in a single source. The truth lives in the connections.
To be precise about scope (this is a research conference, and precision matters): within one company, for structured data, centralization works and should be done. The impossibility claim is about the full memory of the product across all trace types and organizational boundaries.
And federation (OSLC, linked data, federated PLM) was right to abandon SSOT, but it links data. It does not capture the reasoning and semantic translation humans still perform at every boundary. The thread gives you continuity of data. It does not give you continuity of understanding.
Product Memory: The Definition
Here is the definition I put on the screen:
Product Memory is a persistent, connected, and explainable layer of product context. It captures not only product data (parts, BOMs, files, revisions, suppliers, and changes) but also the relationships, decisions, rationale, assumptions, and history that explain how a product evolved over time. Persistent. Connected. Explainable. Attributed. Recoverable.
Why is this possible now, when design rationale capture largely failed? Because those systems required capture as a separate act, and separate acts do not survive contact with a deadline. What changed is that the traces now exist as byproducts of everyday work, and machines can read, structure, and propose the connections between them. Machine-proposed, human-validated, fully attributed. That changes the cost structure of the problem.
And the AI connection runs in the direction most people get backwards. Nearly every AI failure I have examined in engineering settings over the past two years was, underneath, a connection failure before it was a model failure. An AI making form-fit-function decisions without product memory is not automating engineering judgment: it is automating the absence of judgment, faster and at scale. AI does not create the need for Product Memory. AI depends on it.
I presented the context graph as the technological foundation of Product Memory: the evolution of graph models (graph → knowledge graph → context graph).
From a systems perspective, we moved from Files (traditional PDM/PLM) to Data APIs (SaaS models) to Context (including AI enablement).
From a work perspective, I see the importance of rethinking workflows as we introduce AI and the Product Memory vision to engineering and manufacturing organizations.
In practical terms, I described the Product Memory flywheel: Capture (bring product knowledge into a connected structure from CAD, files, and engineering work), Review (validate, compare, and understand what changed, why, and what it means downstream), and Flow (move structured, contextual product knowledge across teams, suppliers, ERP, and lifecycle stages). The goal is not to replace your systems. It is to connect the knowledge that currently lives between them.
The Open Questions
Because this was a mixed industry and academic audience, I wanted to be equally honest about what is unsolved. Three foundations seem clear to me: the underlying model is a graph, not a vault; capture must live inside existing workflows; and the memory layer must cross system and organization boundaries, because the seams are exactly where memory dies today.
But here is what we do not know. Who owns Product Memory when it spans engineering, manufacturing, contractors, and suppliers? What is the lifecycle of memory itself: what should be forgotten, when, and who decides? How do we validate memory, so a badly captured reason does not become a permanently trusted one? And what does shared memory look like across organizations whose incentives to remember and to forget are not aligned?
These are not implementation details. These are the research questions of the next decade of this field, and they are largely unclaimed. Judging by the Q&A and the hallway conversations afterward, this landed. Several researchers approached me about exactly these questions, and I hope some of them become PhD topics.
One more thing I insisted on, because it would be easy to hear all this as a technology story. It is not. The engineer from my opening story is not incidental to how engineering works; she is the current architecture. Product Memory is not about replacing her. It is about making her connections outlive her, because the day she retires, the semantic layer of the organization walks out the door while every file stays perfectly preserved in the vault. AI needs Product Memory. And Product Memory needs people. Both halves are true, and the second half is the one this field should not forget.
Does Product Memory Replace PLM?
This question was one of the most honest and important ones I received. Just as you cannot eliminate decades of investment in existing systems, you cannot replace those systems overnight. The ecosystem will continue to evolve, and companies that have invested billions in their systems will build a Product Memory semantic layer on top of them.
The Book: Product Memory
At the end of the keynote, I made an announcement I’ve been looking forward to for a long time: I am writing a book about Product Memory. The keynote was, in many ways, a preview of its core argument: the history of how our systems fragmented product knowledge, why single source of truth was never the answer, what a memory layer for products looks like, and what it means for AI in engineering.
You can find more information and sign up for updates here: https://beyondplm.com/product-memory-book/
The book website will be an evolving project over the coming months, where I’d love to collaborate with you and share updates about my research and upcoming publications.
I closed the talk with four lines, and I’ll close this article the same way:
CAD tells us what the product looks like. BOM tells us what it is made of. PLM tells us how it was controlled. Product Memory tells us why it became what it is.
Here is the full slide deck of my presentation.
What Is My Conclusion?
For fifty years, we built systems to make sure engineering organizations never lose a file. I think the work of the next decade is to make sure they never lose their minds. What made IFIP PLM 2026 special for me was seeing this idea resonate with the research community, and seeing Martin Eigner, from a completely independent 40-year trajectory, arrive at a strikingly similar architecture: semantic graphs, connected context, AI orchestration on top. Here is a picture of me and Martin Eigner after the keynotes in Lecce, Italy (picture credit Sven Klaua)
The conversation about PLM is changing from files and records to knowledge and memory. If you want to be part of that conversation, check out the book page, and as always, I’d love to hear what you think. Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams. My opinion can be unintentionally biased.
