Ilan Madjar published Product MemoryWh: Right Idea, Impractical Reality this week, and it is the most serious critique of Product Memory I have read so far. I have known Ilan for close to three decades. He is a founder of xLM and helps companies to implement various PLM systems, build integrations between AI and PLM and I highly value his opinion.
Is Product Memory practical? Not as an enterprise-wide program built all at once. It is practical when it starts at the point of work, in the processes where forgetting costs the most, and grows from there.
Ilans’ argument is simple to state. He agrees with the diagnosis: engineering organizations do not lose data, they lose the reasoning behind it. He challenges the cure. Nine obstacles, plus four more, make an enterprise-wide product memory, in his words, “prohibitively expensive to build and even more expensive to keep correct.”
The LinkedIn thread that followed is just as valuable. Andreas Lindenthal, Jos Voskuil, Rob Ferrone, Patrick Hillberg, Brion Carroll and Marc Young pushed the conversation in directions the article did not. I want to answer all of it in one place, because I think the obstacles are real, and I think most of them point to the same conclusion I reached: Product Memory has to start small, at the point of work, and grow.
Ilan and I agree on more than his title suggests
Let me start from what we agree about. Ilan represents my position fairly and quoted some of my articles. Here are some of them – – Product Memory is not a new database and not a new System of Record. PLM, ERP, MES and CAD stay authoritative for their facts. The memory layer is physically distributed and logically connected, and it is filled largely as a byproduct of everyday work.
I also want accept most of Ilan’s obstacles he mentioned in the article. Much of the reasoning was never digital, silos do speak different languages, people do work around the process. And, of course, things like GDPR, works councils, ITAR and NDAs are real constraints. Then we go to maintenance work – system migrations do break links, retrieval does find what looks relevant rather than what is correct. I have written about several of these myself, and Ilan quotes me on them.
And I accept the most important fact he raises. Nobody has a production deployment of an enterprise-wide product memory today. My own article on PTC Jetstream called it a step toward Product Memory, and Ilan is right about it – these are only steps towards the future.
So the disagreement is narrower than it looks. Ilan says in the thread that he believes in the idea and that it “can be built bit by bit.” His question is about delivering it in its entirety. My answer is that nobody should try to deliver it in its entirety, and that the obstacles he lists are the reason why.
Enterprise-wide is where Product Memory ends up, not where it starts
Read Ilan’s conclusion carefully. A true product memory, he writes, must reach knowledge that was never digital, reconcile every vocabulary, arbitrate every conflict, clear every jurisdiction and absorb every system replacement. Each obstacle is solvable in isolation. Together they compound.
That is true of any system specified as a finished whole. It was true of PDM in the 1990s and of PLM in the 2000s. Companies that tried to deploy PLM as a single enterprise program, every site and every process at once, produced the failure stories our industry still tells. Companies that started with one product line, one change process or one plant, and grew from there, are the ones that got value. Think about implementations of Digital Thread, which is considered a pretty mature concept in PLM implementations.
Product Memory is not different. I have never argued that a manufacturer should connect every silo before getting any benefit. The Capture, Review, Flow model Ilan cites is incremental by design. A decision gets captured where it is made. It is reviewed and connected to its evidence. The next cycle starts with richer context than the last. The memory grows the way a product grows, one release at a time.
Ilan’s own recommendation is to “capture decision context at the point of work” for “the few high-risk processes where lost reasoning is most costly.” I agree with every word of that. I would only add that it is not a smaller version of Product Memory. It is the first chapter of it.
Product Memory is already being built, one moment of work at a time
Ilan’s ninth point is that no one has built one and no vendor can. On the enterprise-wide version, he is right. But look at the examples of companies and products I collected and check the pattern. Several companies, working independently, are each capturing one moment of engineering work with its reasoning attached.
CoLab captures design review. When a new model or drawing is uploaded, it brings up feedback from earlier reviews of similar geometry, with who raised the issue, where it came up and how it was resolved. Feedback left once is reused on every later design. That is capture, review and reuse inside a single moment of work. The result compounds.
PTC Jetstream, launched in October, captures the collaboration around a change. Comments and markups stay tied to the exact version under review, AI summaries record outcomes and owners, and decisions are written back into Windchill so that people can see what was agreed and why.
CADDi comes from the opposite direction, manufacturing and sourcing. It links drawings to design review notes, inspections, nonconformance reports and past decisions, along with procurement history and supplier performance. It shows that memory forms around many kinds of objects, not only the CAD model.
The vocabulary is converging too. Aras describes the digital thread as “a system not only of record, but of understanding,” with context that captures “not just the data, but the reasoning behind it.” Outside our industry, Ashu Garg of Foundation Capital put the same idea in one line: “Salesforce knows what happened. It doesn’t know why.” His argument is that the next large platforms will be systems of record for decisions. When the same idea arrives independently in CRM and in PLM, it is probably not a PLM rebrand.
At OpenBOM we are working on the same problem with BOM Review, which capture review and change context around BOM and CAD data. BOM Review captures the entire history including all changes, comments, tasks, decisions. Like the others, this is a beginning, not a finished product memory.
Here is what none of these examples do yet. Each one captures one moment inside one tool. A design review in CoLab, a change discussion in Windchill, a drawing history in CADDi and a BOM decision in OpenBOM are not yet connected to each other. Capture at the point of work is now proven enough to ship. Connecting those moments across systems is not, and that is the work ahead.
There is also a precedent worth remembering. In the early 2000s, Ken Wallace’s group at the University of Cambridge built DRed, the Design Rationale editor, with Rolls-Royce. By 2013 it was available to about 14,500 Rolls-Royce engineers and was used across Trent XWB engine design and in incident investigations. So design rationale capture has run at enterprise scale before. It also required engineers to document their reasoning as a separate act. That distinction, documentation as an extra task versus capture as a byproduct of work, is exactly why I think this generation of tools can go further.
The 7075 versus 6061 example is the best argument for Product Memory
Ilan’s strongest example comes from his earlier article, Semantic Similarity ≠ Truth. A released drawing specifies Aluminum 7075. An engineer’s email says 6061 is acceptable. Both score almost identically against the same AI search. The model is not hallucinating. It is faithfully reporting a memory that exists. It is simply the wrong one.
I agree with the analysis, but I notice a very specific description – it describes retrieval over raw silos: a search index that holds two pieces of text and knows nothing about either one’s status. That is exactly what happens when there is no product memory.
A memory worthy of the name would hold more than the two texts. It would know that the drawing is released at Rev C under a specific ECO. It would know that the email was a suggestion that never became a change order, or that it did, and under which deviation and for which effectivity. The question “which material?” would come back with the approved answer and the history of the alternative that was considered and not adopted. Brion Carroll made the complementary point in the thread: if a company records a suggestion like 6061 at all, it should record the reason with it, whether equal fitness, lower cost or a supply chain alternative.
This is why the definition matters. Product Memory is a persistent, connected, explainable, attributed and recoverable layer of product context. It preserves not only what was decided, but why, by whom, under what constraints and with what alternatives considered, while PLM, ERP, MES and CAD remain the systems of record. Ilan’s example fails on connected and explainable. The email is not linked to the change process, so nothing explains why it does not count. Semantic similarity is not truth, and I would add that similarity is not memory either. Memory is what knows the difference.
The same applies to his concern about over-reliance on AI, which is well supported by the research he cites. People will trust confident answers. That is a reason to make sure the answer carries its provenance: which record, which approval, which person, which date. An answer with its lineage visible is far easier to question than a fluent paragraph with none.
Product Memory does not decide which truth wins. It records how the decision was made.
Ilan asks the the most important question – if Product Memory has authority over nothing, who decides when the memories misaligned? He illustrates it with a table of four conflicts: PLM says released while QMS says re-test pending, ERP says approved vendor while a memo says do not use at Plant 2, PLM says Rev C while MES says Rev B was built under deviation, and the drawing versus the email. In every row, his honest answer is “it depends.”
Look at what each “it depends” depends on. Whether the re-test was triggered by a deviation. The plant and the date of the memo. The serial number and the effectivity. Whether the email became an ECO. Every one of those conditions is a piece of context that exists at the moment the decision is made, and every one of them is exactly what gets lost today.
So I do not think the answer is a precedence engine that ranks systems against each other. Ilan is right that writing deterministic rules for every attribute across every system pair is a combinatorial exercise that never ends. And he is right that handing the choice to a model moves arbitration from an auditable rule to an opaque probability.
The answer is that the systems of record keep their authority, and Product Memory keeps the reasons that authority was exercised the way it was. The deviation, the effectivity, the plant restriction and the decision not to adopt 6061 are all records of human judgment. Capture them with their links, and the “it depends” stops being a guess. It becomes a lookup with an explanation attached.
There will still be conflicts that no record resolves. That is fine. A memory that can say “these two sources disagree, here is what each one is based on, and here is who owns the decision” is doing its job. Hiding the conflict would be the failure.
Benedict Smith added a requirement in the thread that deserves more attention: we need “a defensible way to make decisions with imperfect knowledge and to know when the available knowledge isn’t sufficient.” Ilan answered with the hardest version of the problem. Justifications go stale too, and keeping them current across all the silos is where the real cost lives.
Both are right, and together they separate two jobs that are easy to confuse. Preserving the reasoning behind a past decision is one job. Deciding whether that reasoning still applies is another. A material substitution approved for one revision, one supplier or one operating condition does not automatically justify the same substitution today. The original reasoning stays valuable as history. Its applicability has to be reviewed.
This is what the Review stage in Capture, Review, Flow is for: checking assumptions, marking decisions that were superseded, and assigning an owner to questions nobody has resolved. Product Memory cannot promise complete knowledge. It should make the limits of its evidence visible. Sometimes the most useful answer it can give is this one: we found the earlier decision, we do not have enough evidence to apply it here, and this is the person accountable for deciding.
The token bill is the cost of forgetting
Ilan’s cost illustration is careful and his arithmetic is correct. Two hundred engineers, twenty cross-system questions a day, 150,000 tokens of context per question, $3 per million input tokens, and 250 working days comes to about $450,000 a year in input tokens alone. He is honest that these are assumed round numbers, and he even notes that a defender could call cost an engineering choice, not a law.
I want to take that defense seriously, because the assumption behind the model is the interesting part. The model assumes that every question rebuilds the “why” from scratch. Read the change orders, the BOM history, the supplier records, the emails and the meeting notes, then reason across all of them, again, for every question and every user.
That is not the cost of having a product memory. It is the cost of not having one. When reasoning is captured and connected at the moment of the decision, the expensive work is done once, when the context is fresh and cheap to record. A later question reads a small, linked record instead of reconstructing the world. Human organizations work the same way. We write a decision memo once so that a hundred people do not have to re-interview the team.
Capture is not free. It costs compute and storage, and it costs people. Ilan reminded Rob in the thread that the AI option does not remove the team: someone still has to keep the connections and mappings alive. Patrick Hillberg added the cost of checking for errors. Both are right, and both costs belong in any honest budget. But the costs of capture are paid at the point of work, they scale with the number of decisions rather than the number of questions, and they produce an asset that gets cheaper to query over time. Reconstruction at query time scales the other way.
Rob Ferrone framed this in the thread as the total cost of PLM: AI and live data, or a team of analysts and decision support that takes days. It is the right frame. The real comparison is not the cost of memory against zero. It is the cost of memory against what we already pay to rediscover lessons, repeat rejected designs and run slow failure investigations. That counterfactual is hard to put on a CFO’s desk, as Ilan says. It is also not imaginary. Every PLM practitioner has paid it.
Mandating documentation fixes context lost in transit, not context never captured
Andreas Lindenthal made the most direct objection in the thread. The reasoning Product Memory wants to preserve, he wrote, “already exists when those decisions are made.” Modern PLM already supports issues, requirements, change orders, design reviews and approvals. The problem is not technology. It is that organizations do not require the reasoning to be captured. The fix is process and governance, not a new layer. He is careful to say this applies to every authoritative system in an organization, not only PLM.
I agree with the first half completely. The reasoning does exist at the moment of the decision. That is precisely why the moment of the decision is where capture has to happen.
Where I disagree is the remedy. I have answered Andreas on this before, so I will be brief. Engineering organizations lose context in two different ways. Some context is lost in transit, when a person carries it across a silo boundary by hand and drops part of it. Better process and discipline can fix that. Other context is never captured at all, because recording it was a separate task that nobody had time for. Mandates have not fixed that in thirty years. The knowledge management programs of the 1990s and 2000s required engineers to document their reasoning as an extra act, and most of them faded. DRed at Rolls-Royce is one of the rare cases that succeeded, because Rolls-Royce built it into its formal engineering process and its graduate training.
Ilan’s own fourth point shows why. Approvals happen in hallways. Deviations are agreed by phone. Engineers write the minimum needed to close a workflow.
So I would put it this way. Andreas is right that governance is required. Someone has to decide which decisions need recorded reasoning, how evidence is evaluated, and who is accountable for the call. No technology replaces that. What changes is how the evidence reaches the governance process. When it depends on engineers writing explanations as an extra step, it keeps losing to deadlines. When the reasoning is captured as a byproduct of the review, the change and the conversation, and connected to the records it depends on, the process Andreas asks for becomes affordable to follow. Byproduct capture is not an alternative to his discipline. It is how that discipline gets fed.
Andreas also argues for reducing the number of disparate systems as much as possible. I agree with that too, and I would encourage every company to do it. But a manufacturer with one CAD, one PLM, one ERP and one MES still has suppliers, contract manufacturers and customers outside all four. The reasoning crosses company boundaries, not just system boundaries.
Legal limits, permissions and forgetting are design requirements, not refutations
Ilan’s legal and governance points are the ones I take most seriously, because they cannot be engineered away. GDPR limits on employee mailboxes, works council rights in Germany and Austria, ITAR and EAR, supplier NDAs, the right to erasure and litigation exposure are all real. I would not advise any company to point an AI at every mailbox and every meeting recording and call the result a product memory.
But each of these constraints tells us how to design the memory, not whether to build it.
Start with scope. A memory captured at the point of work, inside engineering tools, is about engineering decisions: why this material, why this supplier, why this change was rejected. It does not need personal mailboxes or private notes. That is a smaller, more defensible scope, and it is the scope Ilan himself recommends.
On attribution, I want to be precise. Recording who approved a change and on what basis is not new. Every regulated manufacturer already does it for change control, and auditors expect it. That is different from monitoring how employees behave. The line between the two has to be drawn deliberately, and in Europe it has to be drawn with works councils, not around them.
On permissions, Marc Young described the right principle in the thread. An AI assistant should only know what the person asking is allowed to see. A memory that enforces the access rules of its sources, including on every summary and derived link, is harder to build than one that does not. It is also the only kind anyone should deploy. Connecting reasoning also does not mean exposing every record behind it. A memory can tell an engineer that a supplier is restricted for Plant 2, and who decided it, without opening the contract that explains why. That is part of the answer to Jos Voskuil’s question about where the memory border sits.
On forgetting, Jos Voskuil asked the sharpest question: who defines what is irrelevant? Ilan adds that an error in that policy can silently delete the one lesson that mattered. Both are right, and that is why I have argued that curation is part of what memory means. An archive keeps everything at equal weight. A memory has a retention policy, an owner and an audit trail for what it consolidates and what it lets go. Legal holds and litigation concerns belong inside that policy. They do not make the policy impossible. Today most companies forget by accident. A memory makes forgetting a decision.
Memory is what keeps a forward-looking model honest
Rob Ferrone challenged the word itself. “Memory is the wrong word,” he wrote. We do not consult memories of decisions; we consult a model of the world that experience has shaped. Decision support should be forward facing, built on continuously updated models of engineering practice, strategy, customers, supply chain and regulation. And we cannot even say past decisions were good, because a good outcome may simply have been luck.
I like this challenge, and I think it supports the case for memory rather than against it. A forward-looking model has to be trained and corrected on something. In engineering, that something is the record of what was decided, on what evidence, and what happened next. Without it, the model is built on outcomes alone.
Rob’s point about luck is the strongest reason of all to keep the reasoning. If you only keep outcomes, you cannot tell a good decision from a lucky one. You can judge a decision fairly only against what was known when it was made: the assumptions, the alternatives, the constraints and the risks people accepted. That is precisely the information that disappears first. A model that learns from outcomes without that information will learn the luck along with the skill.
This is also why I hold on to the word “memory” rather than “context” or “understanding.” Context is whatever happens to be present right now. Memory is what persists, and it can be lost. The whole problem is that it is being lost. Jos is right that understanding is the goal. Memory is what makes understanding possible a second time, after the people who understood have moved on.
Patrick Hillberg asked a related question in the thread: can memory live without AI? It can. At its core, Product Memory is a structure: decisions linked to their evidence, their alternatives and the people accountable for them. DRed proved that structure can exist without any AI at all. What AI changes is the economics. It makes capture cheap enough to happen as a byproduct of work, and retrieval useful enough that people come back to it. Patrick’s own list is a good test for any decision record: what job was to be done, which assumptions had to hold, and which alternatives were rejected.
Ilan and I still disagree about where the memory lives
After all this agreement, one real difference remains, and I want to state it plainly. Ilan’s practical path captures decision context “inside the authoritative system where the decision is made.” I think that is the right place to capture it. I do not think it is the right place to keep it.
Engineering decisions rarely belong to one system. A change approved in PLM depends on a supplier’s lead time in ERP, a nonconformance in QMS and a test result that lives in a lab system. If each system keeps its own slice of the reasoning, we have rebuilt the silos one level up. The engineer who asks why a part changed still has to visit four systems and connect the answers by hand. That manual bridging is where context gets lost in transit today.
This is also my answer to Ilan’s point that no vendor can build connectors to every homegrown Access database and departmental SharePoint site. He is right, and that is exactly why Product Memory cannot be a feature owned by one vendor’s platform. It has to be connected through open interfaces, APIs and protocols such as MCP, so that the memory can grow across tools a company already runs, including tools from vendors who compete with each other. The industry has not solved that yet. It is the problem worth working on.
Two more of Ilan’s points deserve a straight answer. Much of the memory was never digital, and some of it never will be. The phone call and the hallway agreement will stay invisible unless someone records the outcome. But the share of engineering work that happens inside digital tools grows every year. Design reviews happen in browsers, change discussions happen in shared threads, and meetings are recorded by default in many companies. Product Memory starts where work is already instrumented and grows as more of it is.
And the landscape never stops moving. Brion Carroll put it very straightforward in the thread: Product Memory will never stop needing maintenance. I agree. Neither will PLM, ERP or the documentation that holds a company’s quality system together. A migration from SAP ECC will break links, as Ilan says. A memory that records links with their provenance at least knows what it lost. Today, most companies do not even know that.
What is my conclusion? A small memory that is right is how a large memory begins…
Ilan ends with a line I would happily put on a slide: “a small memory that is right is worth far more than a large memory that is sometimes wrong.” I agree. I would only add that every useful large memory started as a small one that was right.
So here is what would change my mind. If capture at the point of work turns out to be too expensive to run, if engineers reject it the way they rejected documentation mandates, or if connecting captured decisions across systems proves impossible even with open protocols, then Ilan’s skepticism will have been justified. Those are testable claims, and the tools shipping now from CoLab, PTC, CADDi, OpenBOM and others will test them in the next few years.
Until then, I read Ilan’s nine obstacles as a requirements list. Start where the cost of forgetting is highest. Capture reasoning as a byproduct of work, not as extra documentation. Keep the systems of record authoritative and record why their authority was exercised. Enforce the access rules of every source. Make forgetting a decision. Connect through open interfaces instead of waiting for one vendor to own it all.
That is not the enterprise-wide product memory Ilan argues against. It is the one I am trying to build, and the one I am writing about in my book, From CAD Files to Product Memory. Thank you, Ilan, for making the argument sharper. Let’s keep the conversation going.
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.
Frequently asked questions
Is Product Memory practical to implement?
An enterprise-wide product memory built all at once is not practical. Product Memory becomes practical when it starts at the point of work, capturing decision context as a byproduct of design reviews and changes in the processes where lost reasoning costs the most, and grows from there.
Does Product Memory replace PLM or the system of record?
No. PLM, ERP, MES and CAD remain authoritative for their facts. Product Memory records the reasons behind decisions made in those systems, such as deviations, effectivity and rejected alternatives, and connects them to their evidence.
How is Product Memory different from AI search over engineering data?
AI search finds text that looks relevant. Product Memory knows the status and lineage of that text, for example that an approved drawing specifies one material and that an email suggesting another never became a change order.
Which companies are building early forms of Product Memory?
Several vendors capture reasoning at one moment of engineering work: CoLab for design review lessons learned, PTC Jetstream for change collaboration in Windchill, CADDi for drawings linked to quality and sourcing history, and OpenBOM for BOM and CAD review context. None yet connects these moments across systems.
Can Product Memory exist without AI?
Yes. Product Memory is a structure of decisions linked to evidence, alternatives and accountable people. Design rationale tools such as DRed at Rolls-Royce existed before modern AI. AI makes capture cheap enough to happen as a byproduct of work and retrieval useful enough to be used.
