For the last two decades, the PLM industry has pursued the vision of the Digital Thread. The idea is both simple and powerful: connect product data across the entire lifecycle. Requirements, CAD models, BOMs, manufacturing plans, software configurations, supplier data, quality records, and service information should all be linked together into a continuous flow of information.
It was, and still is, an important vision.
Without a Digital Thread, engineering organizations fragment quickly. Information gets trapped in disconnected systems. Traceability disappears. Changes become risky. Compliance becomes expensive. Manufacturing and engineering drift apart. Service teams lose visibility into what was actually built and shipped.
Digital Thread matured to solv a real problem: it connected product records across lifecycle systems.
But over the last year, as I’ve been writing and speaking about Product Memory, I’ve noticed a consistent reaction from many PLM professionals. The moment they hear terms like “memory,” “context,” “emails,” “conversations,” or “AI reasoning,” many immediately assume this is another attempt to replace PLM with some new single source of truth.
That is not what Product Memory is trying to do (if you missed my previous article, read this one before continue with this article – What is Product Memory?)
The confusion is worth taking seriously, because it reveals something fundamental about how engineering systems evolved over the last thirty years and why the assumptions embedded in those systems are now under pressure.
What Digital Thread Was Never Designed to Capture
A Digital Thread is a good way to connect systems of records holding formal lifecycle artifacts.
When implemented in full scope, it can tell us which requirement led to which design, which revision triggered which ECO, which BOM was released to manufacturing, which supplier provided a component, which configuration was delivered to a customer.
But it very often cannot explain why the decision was made, which alternatives were rejected, which assumptions existed at the time, who raised concerns during the process, what manufacturing workaround became accepted practice, or why a supplier substitution was considered good enough under schedule pressure.
This is not because Digital Thread failed. It is because Digital Thread was designed to preserve lifecycle continuity and traceability, not organizational reasoning. Those are different problems, and the distinction matters more now than it did a decade ago.
The organizational reasoning lives in a parallel space. A BOM can be send via email to contractor for review and come back from comments and then lost after the decision based on this Excel was implemented. Would it be possible to preserve this information? Would it be possible to provide a way to perform these communication in a different way? Those are questions Product Memory is supposed to solve.
Here is a practical example that makes this concrete.
When the Digital Thread Is Complete but the Answer Is Still Missing
During the supply chain disruptions of recent years, many engineering teams had to replace unavailable components quickly. Imagine a company building an industrial control system. One critical electronic component suddenly becomes unavailable with a lead time of more than fifty weeks.
Engineering identifies an alternate supplier. The formal process works correctly. A change request is created, testing is performed, the ECO is approved, the BOM is updated, manufacturing receives the new revision, and ERP and procurement systems synchronize the change.
The Digital Thread is intact.
Three years later, field reliability problems begin appearing in a subset of deployed systems operating in humid environments. Failure rates are still low but increasing. A new engineering team investigates.
The Digital Thread helps significantly. They identify the exact ECO, find the revised BOM, see when the alternate component was introduced, identify affected serial numbers, and trace impacted customer shipments.
But one critical thing is still missing.
Nobody can explain why the organization accepted the alternate component despite concerns raised during early qualification testing.
Eventually, after weeks of investigation, someone finds fragments of the original story. An engineer raised humidity concerns during testing. Manufacturing argued that a production shutdown would cost millions. The supplier promised an updated specification. Management accepted temporary risk under shipment pressure. Teams agreed to revisit the decision after six months.
Most of this discussion happened in Teams chats, during supplier calls, in meeting conversations, in engineering comments that never entered the official workflow.
The organization preserved the decision. It lost the memory surrounding the decision.
That is the distinction.
The Digital Thread preserved lifecycle continuity. Product Memory would have preserved the contextual evidence surrounding how the decision emerged — the concerns, the tradeoffs, the assumptions, the conditions under which the risk was considered acceptable.
Why the Old Model of Human Memory Plus System Records Is Breaking Down
There is a reason Digital Thread never needed to capture reasoning.
For most of the history of engineering organizations, humans were the reasoning layer. Systems carried records. People carried context. That division of labor was never written down as a design principle – it simply emerged from how organizations worked.
A senior engineer who had been with the company for twenty years didn’t need the system to tell her why a supplier substitution was accepted under pressure. She was in the room. She remembered the conversation. She knew which concerns were real and which were political. When a new engineer asked a question, she answered it.
That model worked because three conditions held simultaneously.
Engineering organizations were relatively stable. People stayed. Knowledge traveled with careers, not just with documents. Product complexity was manageable within human memory. A senior team could carry the reasoning behind most critical decisions informally without catastrophic loss. And no machine needed to act on the data. Systems retrieved records. Humans interpreted them.
All three of those conditions are now eroding at the same time.
Engineering turnover has accelerated. The experienced engineer who remembered the supplier decision retired or moved on. The institutional memory that once compensated for what systems never captured is thinning.
Product complexity has outrun what informal networks can carry. The number of components, configurations, suppliers, regulatory requirements, and software dependencies in a modern product has grown beyond what any team can reconstruct socially when something goes wrong.
And AI agents now need to act on product data — not just retrieve it. An AI system asked to evaluate a design change, flag a risk, or recommend a supplier needs to understand context, not just read records. It cannot call the senior engineer who left three years ago.
The old division of labor assumed humans would always be available to supply the reasoning that systems never stored. That assumption is breaking.
Product Memory is not a new idea imposed on engineering organizations. It is the architectural response to the moment when the conditions that made Digital Thread sufficient stopped being true.
The Legitimate Concern: If It’s Not Validated, Can It Be Trusted?
Jos Voskuil presented his concern in the article – Do we need artificial product memory? I understand the skepticism of people with long PLM consulting experience, like Jos. Similar concerns were raised by industry professionals who didn’t believe 3D could be parametric in the 1980s, later by people who thought using credit cards online was dangerous during dot.com, and then by those who questioned whether we could trust the cloud to store engineering data in 2010s. These are normal concerns, and I can see why Jos brought this up.
PLM systems were built around configuration control, authoritative records, governance, validation, revision discipline, and deterministic traceability. For decades, the industry worked hard to reduce ambiguity and eliminate uncontrolled information. When someone proposes capturing discussions, comments, emails, and informal context, the immediate reaction is that this sounds like chaos.
That concern is legitimate. And it leads to the most important objection:
If Product Memory includes unvalidated discussions and informal conversations, how can it be trusted?
This question gets directly to the heart of the misunderstanding – because Product Memory is not trying to become a validated database of truth. That is the role of systems of record. PLM systems validate product state. Product Memory preserves the contextual evidence surrounding how that state emerged. Those are not the same responsibility, and conflating them creates confusion.
Provenance, Not Perfection: How Product Memory Handles Trust
Organizations already make decisions using imperfect contextual information every single day. Engineers rely on hallway conversations, supplier discussions, manufacturing feedback, test interpretations, historical experience, and assumptions under uncertainty. Human organizations have always worked this way.
The problem is not that this information exists. The problem is that most of it disappears. And once it disappears, future engineers cannot reconstruct decisions, organizations repeat mistakes, new employees lose historical context, and AI systems cannot reason about intent or assumptions.
Critics sometimes assume Product Memory means everything captured becomes equally true. But that is not how memory works — in humans or in organizations.
A senior engineer does not trust every piece of information equally. She evaluates who said it, when it was said, whether it matches experience, whether later outcomes validated it, whether it conflicts with other evidence, whether it came from an authoritative source or a local workaround. Humans reason through provenance and context all the time.
Product Memory should do the same.
A mature Product Memory system should know where information came from, whether it was formally approved, who created it, when it was created, whether it contradicts another source, and whether later outcomes validated or disproved it. It should distinguish between official process and local adaptation. It should preserve uncertainty rather than pretending uncertainty never existed.
This is fundamentally different from saying everything in memory is authoritative. In fact, Product Memory becomes more useful precisely because it preserves the confidence levels and conditions surrounding a decision — not just the decision itself.
What AI Agents Need That Digital Thread Cannot Provide
AI makes an existing organizational problem newly visible, but it does not create the problem.
An AI agent can retrieve a BOM, a CAD file, a revision history, a change order. But without Product Memory, it cannot understand why the design changed, what constraints existed at the time, which alternatives failed, which assumptions were temporary, or which supplier decision was driven by schedule pressure rather than technical merit.
This is why Product Memory is best understood not as a replacement for Digital Thread, but as the next architectural layer above it.
The Digital Thread connects lifecycle records. Product Memory preserves the evidence, reasoning, and organizational context surrounding how those records came to exist. They solve adjacent problems, and both are necessary. But only one of them is being built.
Continuity of Understanding, Not Just Continuity of Data
The simplest way to explain the difference: Digital Thread connects the lifecycle. Product Memory explains the lifecycle.But I want to be careful not to make this sound primarily like an AI argument, because it isn’t.
The deeper stakes are human.
Every engineering organization carries knowledge that exists nowhere in its formal systems. Knowledge about why certain architectures were chosen and others abandoned. Why a supplier relationship worked despite performance problems. Why a manufacturing process that looks inefficient on paper has never been changed. Why a product that seems over-engineered is actually exactly right given a failure mode discovered fifteen years ago.
That knowledge lives in people. And it leaves with people.
Digital Thread was never designed to capture it, and that was a reasonable tradeoff when organizations were stable enough to carry it informally. It is a harder tradeoff to accept when engineers are leaving faster, when products are more complex than any team can reconstruct socially, and when AI systems are being asked to reason about decisions they have no way to understand.
AI makes the problem visible. But the problem is organizational, not technological.
Product Memory is the effort to preserve what organizations have always needed to preserve — the reasoning behind the record, the context behind the decision, the understanding behind the data — in a form that survives the people who first created it.
How to capture and organize produce memory? How to prevent organizations from leaking knowledge? How to make this knowledge available for AI agents? Those are questions that I’m going to discuss. AI just made those agents much more urgent.
Digital Thread gave us continuity of data. Product Memory is continuity of understanding.The first was necessary. The second is overdue.
Just my thoughts…
Best, Oleg
Oleg Shilovitsky is the co-founder and CEO of OpenBOM and the author of the Beyond PLM blog, where he writes about the future of product development, PLM, and manufacturing technology.
