A response to Lionel Grealou on Product Memory: why preserving yesterday’s assumptions is what makes tomorrow’s reassessment possible.
Lionel Grealou’s recent article, Product Memory: Are We Remembering What Really Matters?, asks the right question: what should an enterprise actually remember, what must it trace, and what should it be prepared to challenge? Lionel brings an enterprise transformation lens to the topic, and I agree with most of his answer.
He supports challenging old assumptions, keeping historical evidence, and distinguishing past evidence from current guidance. So our difference is narrower than it might first appear. Where I hesitate is the move from deciding which business questions matter to deciding, in advance, which supporting context deserves preservation. Those are different judgments. We can identify important decisions today without reliably predicting which details will explain them tomorrow.
That difference matters more than it seems, because preserving yesterday’s assumptions is what makes tomorrow’s reassessment possible. You cannot unlearn what you never remembered.
For readers new to the term, here is the short version. Product Memory is a persistent, connected, explainable, attributed and recoverable layer of product context. It keeps design rationale and decision context connected to the product data they explain: not only what was decided, but why, by whom, under what constraints, and with what alternatives considered.
Lionel is right that Product Memory does not belong to PLM
Lionel’s first point is one I have been making for a while. Product memory is not a PLM feature. PLM holds the product definition, requirements, configurations and engineering changes. ERP holds suppliers, costs and procurement commitments. MES holds what actually happened on the shop floor. Quality, regulatory and service systems hold the evidence. Each one contributes a piece of the decision story, and none of them holds the whole thing.
His material substitution example makes this concrete. Engineering approves an alternative specification in PLM. ERP knows the supplier, availability and cost. MES knows which batches used the new material. Quality knows whether it conformed. If you ask “why did we switch materials, and was it a good decision?”, the answer is spread across four systems and usually several email threads. I use almost the same scenario in my own writing on component substitution, because it is where the gap between product data and product understanding shows up most clearly.
Lionel also makes the important point that decisions do not only flow from engineering into operations. Supplier constraints, production failures and regulatory changes push decisions back upstream. This is why I describe Product Memory as a layer above PLM, PDM and ERP rather than a module inside any of them. It is also why the right shape is a connected graph of context, not another vault claiming to hold the complete product history. On this, Lionel and I are in full agreement.
Deciding too early what matters repeats a known knowledge management weakness
Here is where I see it differently. Lionel argues that remembering everything is not the objective, and that the enterprise must first establish which decisions are material before deciding how much context to preserve. He asks whether discarded alternatives, supplier quotations and production adjustments should become part of permanent memory, and answers: not necessarily.
I understand the instinct. Nobody wants a landfill of stale assumptions, and Lionel is right that not every record deserves active reuse. But this risks recreating a familiar weakness of knowledge management programs: asking people to decide what future colleagues will need, then document it separately from the work that produced it. Those documentation acts compete with the real work, and the real work usually wins.
The deeper problem is that nobody knows at decision time which details will matter later. Consider a team that evaluates three suppliers and rejects one because of lead time. Three years later, an AI agent recommends the same supplier because its price is attractive. The earlier rejection should not automatically disqualify it. It should prompt a question: has the lead-time constraint changed?
That question is only possible if the rejected alternative and the reason for rejecting it were kept. If they were filtered out as not material, the organization either repeats the full evaluation from scratch, or accepts the recommendation without knowing what was learned the first time. Past decisions should become evidence to examine, not instructions to repeat. Without memory, they are neither.
This is why the definition of Product Memory I use explicitly includes the alternatives considered, not only the decision taken. The rejected path is often the most valuable part of the story, not because it should stay rejected, but because it explains what would have to change for it to become the right answer.
Product Memory should capture broadly and activate selectively
Interestingly, Lionel’s own article contains the way out. He notes that a production record may need long-term retention without ever becoming active knowledge for AI reasoning. I think this is the most important sentence in his piece, because it separates two things that usually get mixed together: keeping context and using it.
Once you separate them, the problem changes shape. Capture should be broad, and it should happen as a byproduct of work, not as an extra act. The design review comment, the change discussion, the supplier email, the approval with its conditions: these are produced anyway. The job of Product Memory is to keep them connected to the product objects they are about, so they do not evaporate when the meeting ends or the engineer moves on.
Broad capture does not mean indiscriminate or permanent retention. Organizations still need boundaries for access, confidentiality and retention. Within those boundaries, the aim is to preserve context produced during work without requiring people to predict every future use.
It is also worth being honest about the limits. Connecting reviews, comments and emails preserves the reasoning people actually expressed. It cannot recover an assumption nobody recorded. Some context is never captured at all, and no architecture fixes that on its own. But a great deal of what is lost today was expressed and then dropped in transit, as people manually carried it between systems and teams. That part is recoverable.
Judgment then moves to the point of use. Which context is relevant to this question, for this configuration, at this point in the lifecycle? Which sources are authoritative? What has been superseded? That is where governance, operating model and industry differences belong, and here I fully agree with Lionel that an aerospace OEM and a consumer goods company will draw these lines very differently. What should not differ is the principle that context is captured where work happens. Filtering at capture time throws away the evidence before anyone knows what question it will answer.
Explanation without traceability cannot be trusted
Lionel draws a clear line between traceability and memory. Traceability establishes what happened, when and under whose authority. Decision context explains why. His summary is a good one: “Traceability may be mandatory, while organisational memory must be purposeful.”
The distinction is useful, and Lionel does not argue the two should be disconnected. I would put it more strongly: they need each other. A “why” without a “who, when and under what authority” is just a story. In the framework I use, Product Memory has five properties: persistent, connected, explainable, attributed and recoverable. Traceability is what makes memory attributed.
But attribution is necessary, not sufficient. Knowing who made a statement does not establish that it was accurate. Trust also depends on evidence, on whether the context applies to the configuration and situation at hand, and on validation where safety or compliance is involved.
This matters even more in the AI context, and here Lionel and I agree completely. He warns that relationships discovered by AI are not automatically verified traceability, and that provenance, source authority and validation remain essential. Exactly right. Systems of record keep their authority. An AI agent that finds a link between a supplier email and an engineering change has produced a hypothesis, not a record. Product Memory has to keep that difference visible, with every piece of context carrying where it came from and how much it can be trusted. Without attribution, remembered context is difficult to evaluate and risky to reuse.
You cannot unlearn what you never remembered
The strongest part of Lionel’s article is about challenging what we remember. A supplier choice made for cost and availability, a design that reflected the best technology of its time, a process that was optimal under old conditions: none of these conclusions is permanent. Lionel warns that an enterprise retrieving yesterday’s reasoning without reassessing it may simply become more efficient at repeating obsolete decisions. He ends with a test I like very much: a truly intelligent organization should know not only why it made a decision, but whether it would still make it today.
Jos Voskuil raised a similar question back in May in Do we need artificial product memory?: “How can knowledge graphs unlearn?” He also questioned whether only validated data should enter memory, since perfectly correct data does not exist. Both concerns deserve a direct answer.
Here is mine. Unlearning is not the opposite of memory. It depends on it. To ask “would we still make this decision today?” you need to know what assumptions the original decision rested on: the cost at the time, the supplier situation, the regulation in force, the alternatives that were rejected and why. If those were filtered out as not material, there is nothing to re-examine. You are left with a decision and no way to test it. The organization can only either keep it blindly or reverse it blindly.
This is why I think of persistent and recoverable as properties that work together. Persistent means context is not lost when people, projects or systems change. Recoverable means it can be brought back, in its original form, with its attribution, when someone needs to question it. Lionel says it well: unlearning does not mean deleting evidence or rewriting history, it means superseding knowledge while keeping historical evidence and current guidance distinguishable. That is precisely what a well-built memory does. Superseded is a state, not a deletion.
This also speaks to Jos’s concern about validated data. Product Memory does not need to hold only verified truth. It needs to hold attributed context, with a clear distinction between what came from a system of record, what a person stated, and what an agent inferred, and with corrections recorded rather than overwritten. Understanding changes. Provenance should not.
An enterprise brain still needs a product memory it can trust
Lionel places product memory inside a bigger idea he calls the enterprise brain: the organizational ability to interpret information, reason across constraints, learn and coordinate decisions. He is careful to say that memory is one cognitive capability, not intelligence itself. I agree, and I would add that the reverse is also true. Intelligence without memory is what we see today when AI agents work on top of product data alone. They pick the wrong revision, recommend an unapproved substitute, run incomplete impact analysis, or propose a design that was already rejected. Missing context is a major source of these failures, even when the model is capable.
Lionel also connects this to his cognitive data thread, which extends the digital thread with rationale, assumptions and human judgment. I don’t think we need to argue about names here. My own view is that a thread connects artifacts across the lifecycle, while memory keeps the reasoning around those artifacts across time, so it remains available when the people who carried it between silos are gone. Whatever we call the layer, the requirement is the same.
So where does this leave us? Lionel ends his article by saying the future is about preserving what matters, tracing what is required, discovering what was disconnected and applying it to better decisions. I would adjust that sentence slightly. The future is about capturing what happens, tracing what is required, activating what matters, and keeping enough of the past to challenge it. An enterprise that filters its memory too early will not become more intelligent. It will just forget faster.
Like Digital Thread before it, Product Memory is becoming a shared industry concept that many people shape. I’m glad this discussion is growing beyond its first circle, and I’m looking forward to continuing it with Lionel, Jos and others. If you want the longer version of how I define Product Memory, I wrote it up in What is Product Memory?
I’m developing these ideas in more depth in my upcoming book, From CAD Files to Product Memory.
Frequently asked questions about Product Memory
Should Product Memory remember everything?
No. Product Memory preserves context produced during work within clear boundaries for access, confidentiality and retention, and activates it selectively at the point of use. The goal is to avoid requiring people to predict in advance which details will explain a decision later, such as why an alternative was rejected.
What is the difference between traceability and Product Memory?
Traceability records what happened, when and under whose authority. Product Memory adds why. The two need each other: traceability makes remembered context attributed, while trust also depends on evidence, applicability and validation.
How can Product Memory unlearn outdated decisions?
Unlearning depends on memory. To reassess a past decision, an organization needs the assumptions, constraints and alternatives behind it. Product Memory marks outdated knowledge as superseded while keeping historical evidence recoverable and distinguishable from current guidance.
Is Product Memory part of PLM?
No. Product decision context is distributed across PLM, ERP, MES, quality and service systems. Product Memory is a connected layer above these systems of record, not a module inside any single one.
Just my thoughts…
Best, Oleg
Disclosure: I am the co-founder and CEO of OpenBOM. My work on connected product data and Product Memory shapes my perspective, and my opinion can be unintentionally biased.
