Beyond PLM explores persistent product memory for engineering AI

AI-generated summary

Beyond PLM argues that engineering AI needs persistent “Product Memory” that preserves not only product data but also the reasoning, evidence and conditions behind decisions. The author, Oleg, proposes creating and maintaining that memory through ordinary engineering work rather than treating it as a separate knowledge-management exercise. He discloses that he is OpenBOM’s co-founder and CEO and that his work on connected product data and Product Memory shapes his perspective. The discussion builds on Robert Hauser’s “What If AI Knew What It Knows?”, which asks why AI repeatedly reconstructs previously analyzed knowledge. Hauser draws inspiration from Netflix’s use of specialized judges and targeted checks to assess synopsis accuracy, then independently proposes persistent series-level memory covering synopsis principles, characters, chronology and episode details. That proposal is a thought experiment, not an existing Netflix implementation. Oleg agrees that memory needs provenance, must distinguish interpretation from fact, and must justify its construction and maintenance costs. Engineering adds a complication: unlike released episodes, products continually change as components become obsolete, suppliers alter processes and requirements evolve. Querying PLM, ERP and supplier systems can reveal current BOMs, suppliers, change orders and revision histories, but often not why a decision was made or where it remains valid. That rationale may reside in emails, meeting notes or engineers’ recollections—or may never have been recorded. Consequently, more reasoning over current records cannot always reconstruct missing context. The proposed “Capture → Review → Flow” flywheel would capture context linked to its item, revision, configuration and source; review its evidence, status and applicability; and carry it into subsequent activities while bringing outcomes back. Memory would retain rejected alternatives, unresolved questions and failed approaches as well as formal approvals. Capture should primarily connect material already generated by work, including BOM differences, change orders, supplier quotes, review comments and test results, while preserving links to authoritative records across existing systems. The proposal does not require centralizing everything or migrating systems. Existing decision points could request missing rationale, with AI drafting context for engineers to confirm or correct. Uncaptured knowledge should remain an explicit gap rather than become a plausible AI interpretation. Review should likewise use established gates, such as change approval, BOM review and supplier qualification. Supplier claims, assumptions, calculations, measurements and approved decisions must retain distinct authority, scope and uncertainty; repeated reuse must not turn an unverified conclusion into fact. An illustrative composite shows why those distinctions matter. Product A’s specified 105°C electrolytic capacitor has a 26-week lead time, so an engineer approves an available 85°C substitute for revision C’s first 500 units, based on predicted board temperatures below 70°C and pending production testing. Six weeks later, testing measures 78°C under maximum load, and approval expands to all revision C units. Six months later, an agent considering the same substitute for Product B, specified for 95°C operation, should recognize that the earlier approval does not transfer. The datasheet, thermal results and derating reasoning can still accelerate Product B’s independent review. Returning outcomes makes the system a learning loop, but benefits are conditional. Test results, field failures, supplier changes and rejected AI recommendations must link back to the specific decisions they inform, and subsequent work must consult that context. Otherwise, summaries can strip approval conditions, repeated interpretations can acquire false authority, source changes can leave memory stale, and capture can outpace review. The author therefore calls for explicit status, scope, evidence links and accountable governance—not capture alone. To test value rather than assume it, the article proposes replaying a year of closed engineering changes and substitutions with two agents: one accessing current systems only, the other also accessing scoped, status-labeled context. Assessment would cover accuracy, inappropriate reuse of earlier decisions, time to explain past reasoning and review effort, alongside capture, review and link-maintenance costs. The author expects greater benefit where parts, suppliers and design patterns recur than in one-off work, but labels this a hypothesis. His conclusion is that every engineering task should leave useful context that the next person or agent can verify, understand within its limits and build upon.