After my keynote at the IFIP PLM 2026 conference in Lecce earlier this month, someone in the audience asked me the question I put in the title of this article.
I think it is an important question and it requires discussion and some historical perspective on both CAD/PLM industry development and AI development. The first is 40+ years old, going back to the first CAD files and the PDM systems invented to manage them. The second is 4 years old, going back to the first ChatGPT in 2022 and the very primitive AI agents we started to develop after it.
The short answer is no. A System of Record is defined by authority over a set of facts, and authority requires exclusivity. Product Memory has authority over nothing. What it holds is the semantics, the connections, the history, and the attribution that live between systems it does not own. The longer answer is worth the time, because the reasoning is where the substance is, and it runs through both histories.
When an Engineering Change Order Succeeds and the Reasoning Disappears
Every engineering change order, BOM validation, or design review is multi-disciplinary by nature. It brings the need to connect multiple people and domains of knowledge. At the same time, an ECO is usually authoritative. It lives in one system and keeps the records straight.
Here is a story I captured. I removed some details, so you won’t be able to recognize the company behind it.
The engineering change order was processed exactly as it should have been.
A component was being substituted. The original part was going end of life, the replacement was form, fit, and function equivalent, and the documentation said so. The change went through review. The affected assemblies were identified. The approvals were collected from the people who held authority to give them. The revision was released, manufacturing was notified, and the record closed. The maintenance guides were updated and notifications were sent.
If you audit that change today you will find it complete. Nothing was skipped.
Two years later the substituted component caused a field failure.
The replacement was equivalent on every dimension the change order asked about. It was not equivalent on a dimension nobody asked about, because the reason that dimension mattered had been established years earlier, in a different program, by an engineer who tested a similar part and rejected it. That test result was never a document. It was a conclusion carried by a person, applied when it was needed, and never written into any system because there was no field for it and no moment in the process that asked for it.
The formal process succeeded. The organizational reasoning did not survive.
This is the failure I want to examine, and it is not a failure of discipline. Nobody was careless. The systems did what they were designed to do. What went missing was not a fact. Every fact was recorded. What went missing was the history, the human knowledge, and the connection between the systems. The reasoning that would have told someone which facts mattered.
Is Product Memory Another System of Record? The Case for Yes
So let’s come back to the original question. Is Product Memory just another System of Record?
It is the right question, and it deserves a better answer than a quick no. Let me first make the case for yes, because the case is stronger than people expect.
A System of Record is a system that holds authoritative information about some part of the business. It is persistent. It attributes entries to people and events. It is queried by other systems that trust what it returns. It is the place you go when you need to know what is true.
Now describe Product Memory. It persists. It attributes reasoning to the people and moments that produced it. It is explainable and recoverable. Downstream systems, and increasingly AI agents, will query it and act on what it returns. It sits in the enterprise architecture as a durable, trusted, addressable thing.
That is four out of four. On the surface, Product Memory looks exactly like a System of Record, and if it is one, then everything I have argued is a relabeling of the architecture the industry has been building since the 1990s. A skeptic asking this question is not being lazy. They are pattern matching against forty years of evidence, and the pattern is real.
So the answer has to be structural, not rhetorical. To get to it, three histories have to be on the table: how engineering data architecture developed, how AI systems arrived at memory, and what those two paths reveal when you put them side by side.
Forty Years of PDM and PLM Gave the Same Answer Every Time
I have spent my career on one problem, and I did not realize it was one problem until recently.
I started in a world where engineering data meant files. An AutoCAD drawing was a file. A 3D part was a file. A CAD assembly was a file that referenced other files, parts, drawings, and other assemblies, and the reference was a path on a disk. Move the file, break the assembly. Rename a folder, and a design that took three months to build could no longer open. Everyone who worked with CAD in that period learned the same defensive habits, and none of them were taught. You did not move things. You did not rename things. You kept a copy of the folder before you touched anything.
That is where I began building software, and the problem we set out to solve at SmarTeam was exactly this one. Not the design problem. The file problem.
PDM: Making Files Into Objects
The insight behind Product Data Management was that a file is a poor unit of management. What an engineer works on is a part, and a part has a history, an owner, a state, and a relationship to other parts. The file is just the current serialization of it.
So PDM systems put a database in front of the file system. The database held the metadata: part number, revision, lifecycle state, who checked it out, when, and what it referenced. The files themselves went into a vault, a managed directory the user never touched directly. Check-out granted exclusive write access and copied the file to a working directory. Check-in returned it, incremented the revision, and updated the metadata record.
The CAD integration was the hard part, and outsiders consistently misjudge why. The difficulty was never reading the format. Formats get solved, and once they are solved they stay solved. The difficulty was the semantics of what the format contained.
An assembly does not simply reference a part. It references a configuration of that part, at a position, under constraints that resolve against other geometry, and it may reference a component that is itself derived from another file through a relationship the CAD system understands and the file only implies. A drawing depends on the model it views, and that dependency is directional and version-sensitive in ways that differ by system. A part can be modeled in the context of an assembly, so that changing a neighboring component changes its geometry, which means the dependency runs the opposite direction from the one the file structure suggests. Family tables, derived parts, in-place features, and external references each create a distinct kind of link, and the PDM system has to distinguish them, because the correct behavior depends on which one it is.
That is the real requirement. Check-out has to know what else must come with the file. Revision has to know what is invalidated downstream. Where-used has to be complete, or an engineer will release a change believing three assemblies are affected when the number is nine. Every one of those behaviors rests on a dependency graph that the CAD system maintains internally, understands completely, and exposes only partially. Reconstructing that graph faithfully, and keeping it faithful as the design evolved, was where the engineering went.
We solved the file problem. We did it well enough that the industry stopped talking about it.
What we did not solve was that the metadata described the file, not the reasoning. The PDM database knew that revision B superseded revision A. It had the description. But it did not know why. That information existed in the change request, if someone wrote it down, and in the reviewer’s memory, which was the more reliable source and the one nobody could query.
PLM: Expanding the Object Model
The logic of PLM was straightforward, and at the time it looked inevitable. If putting CAD files under managed control produced that much value, then putting everything under managed control would produce more.
So the scope expanded. Requirements, bills of materials, change orders, manufacturing process plans, quality records, supplier data, compliance documentation, service instructions. Each one became an object type in a data model. Each object type got a lifecycle, a set of states, permissions, and a workflow that moved it between states with approvals at each transition.
I was at ENOVIA during the period when Dassault Systèmes was consolidating multiple acquired products into a single foundation, and the technical basis for that foundation was MatrixOne. That gave me an unusually direct view of how a new System of Record gets built. MatrixOne’s data architecture was genuinely advanced for its time. The schema was flexible rather than fixed, business objects and their relationships could be defined and extended without rebuilding the application, and the model was expressive enough to absorb product structures, change processes, requirements, and program data inside one consistent framework. The scalability of MatrixOne servers allowed tens of thousands of users on the same server. It was the most capable answer anyone had produced to the question of how to model the enterprise, and the concepts Dassault brought into it carried forward into what became 3DEXPERIENCE, which is, in my view, another System of Record.
PLM was not the only System of Record being built. The same pattern produced MRP, then MRP II, ERP, MES, CRM, SCM, and many others. Each one became authoritative for its own domain, and each one was defined by the boundary of that domain.
I want to be precise about what that architecture achieved, because the criticism I am building toward is not that PLM failed. PLM worked. A regulated manufacturer can demonstrate, years after the fact, that a specific change was reviewed by specific people who held specific authority, that the affected assemblies were identified, and that the released documentation matched what was manufactured. That capability is real, it is enforced by the software, and modern products could not ship without it.
But the architecture had a property that took me a long time to see clearly. Everything PLM captured had to be modeled or defined first. To store a fact, you needed an object type that could hold it, an attribute defined on that type, and a workflow that produced it. Anything that did not fit the model did not get captured, and the things that did not fit were consistently the same things: the discussion, the alternative that was considered and dropped, the assumption everyone in the room shared and nobody stated.
The workflow captured the decision. The decision was the output of a reasoning process, and the reasoning process was not an object type.
The Database-Native Endgame: Eliminating the CAD File
The most architecturally ambitious version of this idea was the attempt to eliminate the CAD file entirely. CAD files were perceived as the problem. CAD file management was considered a mess. Eliminating them was a reasonable answer.
The argument was clean. Files are the source of the trouble. They are opaque containers that must be checked out as a unit, parsed with format-specific code, and locked to prevent conflict. If geometry lived natively in the database as structured records, then features, parameters, and constraints would be queryable objects. Two engineers could work on one assembly concurrently. Change propagation would be a database operation. Referential integrity would be enforced by the store rather than reconstructed by an integration layer.
Dassault Systèmes pursued this seriously with CATIA V6 and ENOVIA, which later became 3DEXPERIENCE. Cloud CAD systems built afterward took the same position from a clean start. Onshape is my best example, and the engineering behind it is genuinely impressive.
And the result is instructive. The file problem was solved, again, and more thoroughly. What did not change is the thing I have been circling. A database-native geometry store knows the parametric history of a feature in complete detail. It knows every operation that produced the current shape. It does not know why the wall thickness is 3.2 millimeters rather than 3.0, and if the engineer who set it has left, the organization has a perfect record of what was done and no record of why.
Complete capture of the artifact. No capture of the reasoning.
Semantic Search and the Discovery I Did Not Expect
I started Inforbix to solve what I thought was a search problem. Engineering data was scattered across file shares, PDM vaults, PLM systems, ERP, and email. My assumption was that the value was in finding things.
What I found was that the value was in connecting them.
The interesting questions customers asked were never single-system questions. Which suppliers are affected by this change. Where else is this component used. What did this part cost the last three times we bought it. Every one of those questions required assembling an answer from fragments that lived in systems that did not know about each other, and the connecting logic did not exist anywhere. It lived in the head of the one person who knew that the part number in ERP had a prefix the PLM part number did not.
That reframing changed what we built. Keyword search over engineering data returns documents, and a document is the wrong answer to every question above. The model we adopted instead was a semantic graph. Files, parts, suppliers, orders, and revisions became nodes. The relationships between them became first-class objects that could be indexed and traversed, rather than joins someone wrote by hand for a specific report. Answering a question meant walking the graph, not scanning the text.
The analogy I kept coming back to was Google. Search on the web did not become useful because the crawler read pages more carefully. It became useful because links between pages were treated as meaning. A link is evidence of relevance, and enough links form a structure that supports inference no individual page contains. Engineering data has denser and far more precise links than the web does. An assembly reference, a where-used relationship, a supplier assignment, and a revision supersession are all explicit and all typed. They were simply never indexed as connections, because each of them lived inside a system that treated its own boundary as the edge of the world.
That was the first time I understood the problem as structural rather than as a gap in any particular product. The fragments were all captured. The connections between them were not, and no system owned them, because connections span systems by definition and every system we had built was defined by its boundary.
Autodesk: Depth in the Data and the Company Boundary
At Autodesk I worked on delivering lifecycle management as a cloud service and on bringing search into the applications themselves. The cloud changed the deployment model and the cost of entry substantially. It did not change the architecture. The object model was still an object model. Data still had to be modeled before it could be stored.
Two things from that period stayed with me. The first was how much structure customers had already built and how little of it any system could see. Working on search meant looking closely at what customers actually had, and the depth of the object models they had defined was striking, as was the amount of meaning sitting inside the files themselves. Organizations had encoded years of engineering practice into their data. Most of it was invisible to the systems managing it.
The second was that nothing works in isolation. Engineering data does not stop at the company boundary. A design depends on supplier components, contract manufacturers hold the process knowledge, and customers hold the field behavior. The connections that matter most are the ones that cross organizations. But those same organizations have to protect their intellectual property, which means the answer cannot be a shared repository that everyone writes into. Connection without surrendering ownership is the requirement, and it is a hard one.
OpenBOM: Graphs, History, and the Boundary Problem
At OpenBOM we started from a position that would have been controversial earlier in my career. We gave up on the idea that there is a single best database.
Polyglot persistence became the foundation. Different storage technologies do different jobs well, and the architecture should use several rather than force everything through one. What unified them was not a common store but a common data model, and the model we chose was a graph. Parts, documents, suppliers, orders, and revisions are nodes. The relationships between them are explicit, typed, and traversable. Structure is not a table shape imposed in advance. It is the connections themselves, and it can grow without a schema migration.
The second decision mattered more than the first. Capturing data was not enough. History had to be captured too: every change, who made it, when, and against what prior state. Not a version stamp on a record, but a continuous record of how the data arrived at its current form. That is what turns a data model into a collaborative workspace, where multiple people and multiple companies work on the same product information with the data, the connections, and the history all preserved together.
The problem we applied this to looks narrow from the outside. Keeping bill of materials data connected across the boundary between engineering and everything downstream sounds like plumbing. It is not narrow. It is the same structural problem at the point where it hurts most.
The BOM is where design intent meets purchasing, manufacturing, and cost. It is also the artifact that crosses the most boundaries. It moves between departments that use different systems, and it moves between companies that will never share a repository. That is exactly the situation I had run into at Autodesk: connection is mandatory, and shared ownership is impossible. A graph of relationships works there in a way a central database cannot, because participants can be connected without being merged.
And it is where the loss of reasoning becomes expensive fastest. A BOM tells you the product is built from these components. It does not tell you that this capacitor was selected because a different one failed a thermal test in a prior program. When the supplier discontinues it, that test result is exactly what you need, and it is exactly what nobody recorded in a form the BOM could carry.
The Pattern: Every New Problem Produced Another Repository
Look at the sequence and the pattern is unmistakable. I described it in evolution of the digital thread article.
Files were unmanaged, so we built PDM to manage them. Non-CAD data was unmanaged, so we expanded to PLM. Files were still an obstacle, so we moved geometry into the database. Data was scattered across systems, so we built integrations, and then integration platforms, and then a digital thread to connect the platforms.
Every step was correct. Every step delivered real value. And every step took the same form: we found information that mattered, and we built a repository to hold it.
Forty years of this taught the industry to ask one question when anything new appears.
Where should we store it?
That question is why someone in the audience at Lecce asked whether Product Memory is another System of Record. It is not a naive question. It is the correct question to ask if the answer has been yes for four decades.
How AI Systems Arrived at Memory: Prompt, Context, Harness
The path AI systems took to memory was not designed. It was forced, one constraint at a time, and each step was an attempt to work around the failure of the step before it.
Here is a picture represent a historical perspective of the transformation for the last four years
Prompts. The first generation of language model applications had one mechanism: the text you sent. Everything the model knew about your problem had to fit in a few thousand tokens, and everything it knew about the world was frozen in its weights. There was no state. Two consecutive requests were unrelated events. Practitioners called what they did prompt engineering, and it was essentially the craft of compressing a task description into a space too small for it.
Context. The constraint that broke prompting was not quality but scope. A prompt describes a task. It cannot carry the material the task operates on. Three mechanisms appeared to solve this, and each one is worth naming precisely because each has a direct analogue in engineering systems.
Tool calling let the model request information rather than receive it. Instead of pasting a file into the prompt, you gave the model the ability to read files, and it decided which ones it needed. Retrieval augmented generation, RAG, connected the model to a database of documents, retrieved the passages that resembled the question, and inserted them into the request. The Model Context Protocol, MCP, standardized the connection between a model and an external system so that capabilities could be attached without custom integration work.
This period is where the industry learned to call the work context engineering, and the name was accurate. The discipline was no longer writing instructions. It was deciding what information should be present in the model’s working space at the moment it reasoned.
Where context engineering broke. The failure mode is specific and it is the most important thing in this section.
As a task runs longer, the working space fills. Every file read, every tool result, every intermediate conclusion accumulates. When the space is exhausted, the system summarizes its own history to make room and continues working from the summary.
The summary is lossy. That is not a defect in the implementation, it is what a summary is. And the system has no way to detect what the compression removed. It continues with full confidence on a degraded record of its own reasoning. In practice this produces a recognizable pathology: tasks reported as complete that were never attempted, verification steps assumed to have happened, decisions made twice in contradictory directions. Practitioners describe long-running agents as getting less capable the longer they work, and the cause is not the model. It is the accumulated loss from repeated compression.
There is a second, subtler version. Attaching many capabilities to a model consumes the working space before any work begins, because every available tool must be described. Systems with a hundred connected functions spend a substantial share of their capacity describing what they could do rather than doing it, and the descriptions crowd out the material the task actually needs.
Both failures have the same shape. The system’s capacity to reason is consumed by carrying everything that might be relevant.
Harness. The response was to stop treating the model as the system and start treating it as one component inside an execution environment. The term that settled on this is harness, and it names something quite specific: a loop, a small fixed set of primitive operations, a policy governing how work starts and finishes, and explicit management of what enters the working space.
The primitives are worth noting because they are so few. Read a file. Write a file. Search across files. Execute a command. The pattern that emerged is that a general system with four primitives outperforms a specialized system with a hundred purpose-built functions, because the four primitives compose and the hundred functions compete for space.
The loop is the other half. Rather than running one long session until its context degrades, the harness runs bounded iterations. Each iteration begins with a clean working space and reads the current state from files on disk. State lives outside the reasoning process. The model does not remember the previous iteration. It reads what the previous iteration wrote.
That inversion is the architectural move. Persistence moved out of the working space and into an external, inspectable, versioned store.
Memory. The final step is the one that matters for this chapter, and it happened recently enough that it is still contested.
If state lives in files, the question becomes how a system with far more accumulated material than it can hold decides what to load. The answer that emerged is two-stage disclosure. Each unit of accumulated knowledge carries a short description, and only the descriptions are resident. The full content, including instructions, executable code, accumulated data, and history, loads only when the system determines it is relevant to the work at hand. The industry term for these units is skills, and the term will probably not survive. The mechanism will.
The consequence is that a system can hold a hundred capabilities where it previously choked on thirty, and the reason is not a larger working space. It is that the working space now holds an index rather than the contents.
Notice what this architecture is not. It is not a larger context window. It is not a better summarization algorithm. It is not a single unified store. It is an index of what exists, a set of relationships that determines what to pull, and a retrieval decision made by the reasoning system at the moment of need rather than by a retrieval pipeline before reasoning begins.
The systems that reason over the most material are the ones that hold the least of it at once.
Why Product Memory Is Not a System of Record
Put the two histories next to each other.
Engineering software spent forty years answering the question “where should we store this” by building another authoritative repository. AI systems spent four years answering the question “how does an intelligent system remember” and arrived somewhere else entirely: an index of what exists, relationships that determine what to pull, and retrieval decided at the moment of reasoning.
Two fields, working on unrelated problems, with no shared literature. One converged on centralization. The other converged on connection. That divergence is the answer to the question asked in Lecce, and here is why.
A System of Record Is Defined by Authority, and Authority Requires Exclusivity
This is the part that usually goes unstated. A System of Record is not simply a place where data lives. It is the place that is right when systems disagree. If two systems hold a part number and they differ, one of them is the record and the other is a copy. That is the entire function. It is what makes reconciliation possible, what makes audit possible, and what makes a change process enforceable.
Exclusivity is not a design preference. It is definitional. Two authoritative sources for one fact is not two Systems of Record. It is a data quality incident.
Product Memory Has Authority Over Nothing
CAD owns geometry. PDM owns revisions and the dependency graph. PLM owns product structure, change process, and lifecycle state. ERP owns transactions. MES owns what was actually produced. Quality owns compliance evidence. Every one of these systems is authoritative, and Product Memory does not compete with any of them for a single fact.
It writes nothing that they own. What it holds is the material that falls between them:
- the semantics that make a part in one system the same part in another
- the connections that link a design decision to the test that motivated it and the supplier who was affected by it
- the history of how the current state came to be, not just what it is
- the attribution that says who reasoned this way, when, and on what basis
None of that is a fact any System of Record claims. All of it is what you need when the reasoning is gone.
This Is Why the Question Dissolves Rather Than Getting a Yes or a No
Product Memory cannot be a System of Record, because its entire value comes from spanning systems it does not own. The moment you give it authority over facts, you have to define its boundary, and the moment you define its boundary you have rebuilt the thing that created the problem: another repository, with another data model, that everything must be migrated into and reconciled against.
We have watched this happen in the CAD and PLM industry for four decades. The next repository is always positioned as the one that finally unifies everything. It never does, because the fragments were never the problem. The connections between them were.
Notice that this argument applies to Product Memory itself. In my keynote I argued that the Single Source of Truth (SSOT) is not a hard goal but a structural impossibility, because every system is defined by a boundary and reasoning crosses boundaries. If Product Memory became authoritative, the same critique would land on it with full force. The only version of Product Memory that survives its own argument is one that owns nothing.
It is not built on top of Systems of Record. There is no top. It runs across them.
What It Produces Is Distilled Context, and Distilled Context Is Memory
This is where the AI parallel stops being an analogy and becomes the same mechanism.
An agent that carries everything degrades. An agent that summarizes loses the ability to know what it lost. The architecture that works holds an index and pulls the specific material a decision requires at the moment the decision is made. What makes that possible is not storage. It is that the relationships are captured well enough for the system to know what to pull.
An engineering organization has exactly this problem at a scale of decades. Nobody can hold a program in their head. Documents accumulate faster than anyone can read them. The formal record compresses each decision into an approved outcome, and the compression is invisible, so the organization proceeds with confidence on a lossy summary of its own reasoning and cannot tell that anything is missing.
Product Memory is the layer that makes distillation possible without loss. Not by storing more. By preserving the connections and the history so that the reasoning behind any given fact can be reconstructed on demand, by a person or by an agent, at the moment it is needed.
Systems of Record preserve facts. Product Memory preserves understanding.
The facts are already captured. They have been captured well for forty years. What was never captured is the structure that explains them, and that structure is not a repository. It is a graph of semantics, connections, history, and attribution that lives across the systems we already have.
That is why Product Memory is not another System of Record. It is not a competing authority. It is the connective layer that turns authoritative fragments back into something an organization can reason with.
What Product Memory Forgets
One question follows immediately, and I want to name it rather than answer it here.
If Product Memory preserves reasoning, does it preserve all of it? The instinct in this industry is total retention. Storage is cheap, deletion is risk, and no one was ever audited for keeping too much. But a store that holds everything at equal weight is not memory. It is an archive, and archives are what we already have.
The AI systems that arrived at memory arrived at this too. The architectures that work include curation as a design feature: material that has not been used decays in prominence, small fragments consolidate into larger ones, and what survives does so because it kept proving useful. Forgetting is not a defect in those systems. It is what keeps the index small enough to reason over.
Persistent and recoverable are not the same as permanent, and the difference is where this argument goes next.
Back to the Change That Was Approved Correctly
The component substitution was reviewed properly. Every fact about it was recorded in a system with authority to record it.
What would a system built on connection rather than authority have preserved? Not another approval field. The link between this part and the prior program where a similar component was evaluated. The test result, attributed to the engineer who ran it, connected to the conclusion he drew. The reason the equivalence criteria used in that review were the ones that mattered.
None of that is a new fact. All of it existed. It was simply never connected to anything, because connection was nobody’s job and no system’s responsibility.
For forty years we asked where product data should be stored, and we answered well. The better question now is different.
What should this organization be able to reconstruct?
Just my thoughts…
Best, Oleg
Frequently Asked Questions
What is a System of Record?
A System of Record is the system that holds authoritative information about a defined set of facts. When two systems disagree, the System of Record is the one that is right and the other is a copy. Authority requires exclusivity, which is what makes reconciliation, audit, and enforceable change processes possible.
What is Product Memory in engineering and manufacturing?
Product Memory is a persistent layer that preserves the reasoning behind product decisions, not just the artifacts those decisions produced. It captures the semantics that connect data across systems, the relationships between decisions and the evidence that motivated them, the history of how the current state was reached, and the attribution of who reasoned and why.
Is Product Memory the same as a Digital Thread?
No. A Digital Thread connects artifacts across the lifecycle so a fact can be traced from requirement to design to production. Product Memory preserves the reasoning between those artifacts: the alternatives rejected, the assumptions made, and the evidence that shaped the outcome. The thread traces what happened. Memory explains why.
Why can’t PLM capture engineering reasoning?
PLM captures only what has been modeled first. Storing a fact requires an object type to hold it, an attribute defined on that type, and a workflow that produces it. Discussions, rejected alternatives, and unstated assumptions have no object type, so they are never captured even when the process runs correctly.
Does Product Memory replace PLM, ERP, or CAD?
No. Those systems remain authoritative for geometry, product structure, transactions, and lifecycle state. Product Memory owns none of those facts. It connects them, which is why it complements Systems of Record rather than competing with them.
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.
