A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

From CAD Files to Product Memory

Product data iceberg: structured CAD, BOM, and ERP data above the waterline, unstructured product memory of notes, emails, and decisions below

Why the knowledge that defines a product was never in the files, and how to keep it.

For the last fifty years, engineering and manufacturing companies have built systems to manage product data. CAD helped us define geometry. PDM helped us control files and revisions. PLM helped us manage lifecycle processes. ERP helped us plan and execute production.

But something important was lost along the way.

We kept the files. We kept the records. We kept the revisions. We kept the BOMs.

But we lost the reasons.

Why was this component selected? Why was that supplier rejected? What trade-off was made in the design review? What did the customer issue reveal? Why did the product evolve in this direction and not another?

This is the question at the center of my upcoming book, From CAD Files to Product Memory.

Subscribe to Get Early Chapters

A product is not its files

A product is not only the CAD model, the drawing, the BOM, the part number, or the released revision.

A product is everything an organization owns, knows, and remembers about how and why it came to be.

In real companies, this knowledge is fragmented by nature. It lives across systems, teams, suppliers, spreadsheets, emails, chats, meetings, engineering judgment, manufacturing feedback, and customer experience.

Every handoff creates a gap. Every system sees only part of the picture. Every organization depends on memory that is often informal, disconnected, and fragile.

And the loss happens in two distinct ways. Some knowledge is never captured at all: the trade-off argued in a design review, the supplier rejected before the decision was recorded. Other knowledge is captured once and then disappears in transit, as work crosses systems, teams, and organizations. Better discipline can reduce the second. Nothing in today’s architecture addresses the first.

That is the problem this book explores.

Why Single Source of Truth was never the answer

For decades, the industry’s answer was one system, one database, one truth. It could not work, for two independent reasons: there is no single schema that can hold mechanical, electronic, software, supply chain, and service knowledge without flattening it, and production reality is multiple systems across multiple organizations with no shared authoritative database.

The truth about a product was never going to live in a single source. The truth lives in the connections.

What is Product Memory?

Product Memory is a persistent, connected, and explainable layer of product context.

It captures not only product data such as parts, BOMs, files, revisions, suppliers, and changes, but also the relationships, decisions, rationale, assumptions, and history that explain how a product evolved over time.

Persistent · Connected · Explainable · Attributed · Recoverable

Product Memory is not another database. It is not Knowledge Management 2.0. It is not a request for engineers to document everything twice.

Product Memory is the idea that product knowledge should be captured as work happens, connected across systems, and made recoverable when people, tools, suppliers, and decisions change.

This essay became the foundation of a book. From CAD Files to Product Memory is being written now, and you can read chapters as they are drafted. Get early chapters of the Product Memory book.

Why AI Needs Product Memory?

AI changes the urgency of this problem.

Without Product Memory, AI becomes chat over disconnected files and databases.

With Product Memory, AI can reason over connected product context.

This distinction matters. Large language models will become more available, more capable, and more commoditized. But the harness around them will become the real differentiator: the connected context, the graph of relationships, the history of decisions, the trusted product knowledge.

AI does not eliminate the need for product knowledge. AI depends on it.

What this book is about

From CAD Files to Product Memory is about the next step in the evolution of engineering software.

It explains why Single Source of Truth was never enough, why the truth about a product lives in connections, and why Digital Thread needs to evolve from continuity of data to continuity of understanding.

The book explores:

  • Why engineering and manufacturing data is fragmented by nature
  • Why product knowledge is lost between systems and organizations
  • Why files and records are not enough to explain product evolution
  • How Product Memory differs from PLM, PDM, MBSE, Digital Thread, and Knowledge Management
  • Why AI needs connected product context to become useful in engineering and manufacturing
  • How companies can begin capturing memory as part of everyday work

Who this book is for

This book is written for engineering and manufacturing leaders, and for everyone who works inside the systems they run: PLM and PDM professionals, CAD administrators, ERP teams, product managers, founders, consultants, and researchers.

It is for people who have seen the same pattern repeat for years: systems get better, files get more controlled, workflows get more automated, but the real reasons behind product decisions still disappear.

From keynote to book

The ideas in this book were shaped by decades of work in CAD, PDM, PLM, product data management, and engineering software.

I’m excited to share it during IFIP PLM 2026 keynote, From CAD Files to Product Memory, presented in Lecce, Italy.

The keynote introduced the argument. The book develops it.

Product Memory did not appear overnight. Two essays trace where it started: What Is Product Memory? defines the concept as a persistent, connected, and explainable layer of product context.

Before Software: How Engineering Was Always a Human Memory System tells the older story, of how product knowledge survived for centuries in people, relationships, and shared experience, before we had systems to lose it in.

The idea is beginning to travel. Product Memory is being discussed and applied by others in the PLM and engineering software community, including Brion Carroll’s article on preparing to adopt AI, which explores how companies can start building toward it. That is exactly what a concept should do once it leaves its author’s hands, and the book gives the concept its full definition.

The question this essay asks, what happens to engineering knowledge when the people who hold it leave, became the starting point of a book. From CAD Files to Product Memory is being written now. Follow the book and get early chapters.

[More photo from PLM 2026 conference in Lecce, Italy are coming]

Read it as I write it

I am writing this book now. Subscribers get draft chapters, early ideas, visuals, and the reasoning behind editorial decisions as the work develops, before publication.

If you are interested in Product Memory, AI for engineering, Digital Thread, PLM, PDM, BOM management, or the future of product development, this is where the book takes shape.

Subscribe to Get Early Chapters

No spam, no vendor pitch. Just the book, chapter by chapter.

To the top