The conversation about Product Memory reached an important milestone last week. For the first time, the concept started traveling without me. Brion Carroll (II) published a post titled “Why AI Needs Product Memory“, making the argument from the AI side: an AI system can summarize documents and search information, but it cannot understand decades of engineering decisions, supplier trade-offs, design intent, and manufacturing lessons if that knowledge is fragmented across systems and people. Thank you to Brion and to everyone who commented, challenged, and asked questions. This is exactly the discussion I hoped to start.
The discussion also produced the best questions the concept has received so far. Andreas Lindenthal asked [link to the comment and discussion]:
So where does this “product memory” live?
My short answer was that it will live in every system that implements this layer. Think about ChatGPT, which has memory, and practically every AI agent that is developing some form of it. Andreas followed with a sharper question:
Can you clarify what you are proposing? What does this “layer” consist of? A separate database and user interface? And how will this “product memory” be filled with information, ie how do the decisions, choices, etc get into the “product memory”?
These are the right questions, and I want to answer them properly, because they expose the most natural misreading of the concept. When engineering software people hear about a new capability, thirty years of enterprise architecture push us toward one question: which system will own it? Where is the database? What is the user interface? It is a completely reasonable instinct, and it is exactly the instinct Product Memory asks us to suspend. Product Memory is not another database, and the question “where does it live” applies System of Record logic to a problem that System of Record logic cannot solve.
Why “Which Database” Is the Wrong First Question
There is a historical reason why the database question feels so natural. In the 1990s, the entire data management decision process in engineering could be drawn as a flowchart with a single diamond. Does the information look like a document? If yes, use Microsoft Office or CAD. If no, use a SQL database. Every piece of engineering information had to be classified as either a file or a set of records, and the entire data management technology stack grew from one of those two answers. PDM and PLM inherited this world. They were built to manage files and to manage records, and they became very good at both.
So when a new capability appears, the trained instinct is to place it on one side of the old diamond. Is Product Memory a set of documents? Is it a database with a user interface? The difficulty is that the context Product Memory preserves was never a file and never a record. It was produced between them, in discussions, decisions, and trade-offs that the old classification had no place for. The question “which database” is not wrong because databases are wrong. It is wrong because it comes from a classification that excludes exactly the information we are trying to preserve.
Enterprise product architecture is organized around authority. PLM is authoritative for product structures, revisions, and changes. ERP is authoritative for suppliers, costs, and transactions. CAD is authoritative for geometry. MES is authoritative for manufacturing execution, and quality systems for inspection and compliance records. The boundaries vary from company to company, but the principle is stable: for every important product fact, there should be one trusted record. This is one of the great accomplishments of enterprise software, and nothing about Product Memory challenges it.
Now ask a different kind of question. Why is this supplier approved only for one plant? Why did the team accept a higher cost? Why does this drawing carry a tolerance that manufacturing dislikes? The answer may involve a part in PLM, supplier information in ERP, test evidence in a quality system, a discussion in a collaboration tool, and manufacturing feedback in yet another application. No single system owns the complete explanation, and none of them was designed to. Each system is authoritative about its own facts. The explanation lives between them.
This is the structural point, and it changes what kind of solution is possible. If no single system owns the explanation, then adding one more authoritative system cannot be the answer. A new “Product Memory database” that companies are supposed to fill would simply become another silo, competing for authority with the systems that already work, and recreating the exact fragmentation it claims to solve. The problem is not that one more category of record is missing. The problem is that the reasoning connecting the existing records was never treated as something worth preserving.
A Layer, Not a Place
When I use the word layer, I mean a logical capability, not a physical destination. Product Memory can be implemented inside existing systems, inside new applications, inside AI agents, or inside services that connect multiple systems. A PLM system can implement Product Memory. A BOM management environment can implement it. A design review application can implement it. An AI agent working across several systems can participate in creating and using it. There may eventually be dedicated Product Memory platforms as well. The important point is not where the bits are physically stored. The important point is whether meaningful product context remains connected to the product and can be recovered when a relevant question appears.
A database will certainly be part of any implementation. Graph databases, relational databases, vector stores, event logs, and document stores may all play a role, and different vendors will make different choices. But a database by itself is not memory. Putting ten thousand meeting transcripts into a repository does not create memory, and storing every chat conversation forever does not create it either. That creates an archive. An organization that stores everything but can recover nothing at the moment of decision has an archive with excellent coverage and no memory at all. Memory requires context that stays connected to the product elements it explains, attribution that tells us where the information came from, and the ability to recover what matters when new work begins.
What the Layer Actually Contains
Here is a concrete example I use in my coming book – From CAD Files to Product Memory. A component was substituted three years ago. PLM can tell us that the old component was A, the new component is B, the change was released in Revision C, and the ECO was approved on March 18. These are important and authoritative facts, and they should stay exactly where they are.
But an engineer investigating a field failure today asks different questions. Why did we choose B? Which alternatives were considered and why were they rejected? What risk worried manufacturing? Was B intended as a permanent solution or a temporary workaround until a redesign that never happened? Did someone warn about the failure mode now being investigated? The answers were real. They existed in meetings, emails, test discussions, and the judgment of people who may have since left the company. No System of Record lost them, because no System of Record was ever asked to hold them.
The Product Memory layer is the persistent context surrounding product objects and product events. A part accumulates memory. A BOM, a requirement, an engineering change, a supplier, a design review, and a quality investigation all accumulate memory: decisions, alternatives, evidence, assumptions, objections, and eventually outcomes. What makes it memory rather than an archive is that this context remains attached to what it explains and discoverable from the context of current work.
How Does the Memory Get Filled?
Andreas’s last question may be the most important one, and it deserves its own article, so I will give the short version here. If Product Memory requires engineers to stop working and document everything they know, it will fail. Nobody wants another documentation system, and the knowledge management wave of the 1990s already demonstrated what happens when capturing knowledge is a separate act from doing the work.
Product Memory has to emerge largely as a residue of work that is already happening. Engineers already identify problems in design reviews, evaluate alternatives during engineering changes, and collect evidence during quality investigations. Decisions are already made, challenged, and approved. The context is produced every day. What is missing is the mechanism that captures it, connects it to the affected product objects, and preserves it beyond the meeting, the email thread, and the memory of the participants. This is where AI changes the equation, because an agent participating in the workflow can identify findings, summarize the discussion, recognize the decision, and attach the resulting context to the product without anyone playing historian. How that works in practice is the subject of a future article.
Product Memory Is Not AI Memory Either
Since my first answer to Andreas pointed at ChatGPT, I want to draw one boundary carefully. The analogy is useful because it explains why memory as a capability matters: a useful assistant cannot treat every interaction as if nothing happened before, and the same is true for an AI agent reviewing a BOM. If the agent finds ten problems, engineers correct six and explain why three are intentional, and the session ends with nothing preserved, the next review starts from zero. Memory is what turns interactions into accumulated understanding.
But the analogy stops there. ChatGPT memory belongs to an agent and a user account. Product Memory belongs to the product and the organization. Industrial products remain in service for decades, while AI models, vendors, and architectures will change many times over that period. AI will become one of the most important creators and consumers of Product Memory. It is not the memory itself, and the memory must outlive every agent that touches it.
The Distinction in Three Lines
A System of Record tells us what is authoritative. A Digital Thread connects what is related. Product Memory preserves the context that explains what happened and why. The thread gives us a path through product history, and memory helps us understand what we find along that path.
So my answer to Andreas is this. Product Memory does not live in a new database, and it is not a user interface. It is a capability implemented as a layer around product work, physically distributed across systems and logically connected through the product. The underlying data can stay where it is authoritative. The database is an implementation detail. The memory is the understanding we are trying to preserve.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
