Beyond PLM examines trust in product data in the AI era

AI-generated summary

Trustworthy product data requires more than accurate records, approved revisions or connected systems, argues Beyond PLM author Oleg. Information must be suitable for the specific decision being made, with clear applicability, supporting evidence and accountable decision-makers. Exploring the implications for AI-enabled PLM, he examines digital threads, governance and “product memory” as potentially complementary approaches, while leaving open what future architectures should guarantee. A production-readiness scenario illustrates the problem: engineering has an approved design, purchasing has confirmed orders, manufacturing has a production plan, and a supplier has emailed a proposed component substitution. Each record may be correct independently, yet the team cannot confidently proceed without knowing whether the substitution requires an engineering change, whether it has been accepted, and whether orders and plans describe the same configuration. Engineering, purchasing, manufacturing, service and suppliers maintain information for different purposes, so discrepancies can reflect legitimate differences or unfinished handoffs. Drawing on CIMdata’s work on data governance, the article emphasizes policies, responsibilities, decision rights and accountability across organizational boundaries. Connecting records can expose disagreement; resolving it still requires authority and communication. Public sources introduce additional verification challenges. Manufacturer specifications, distributor catalogs, material databases, standards, regulatory notices and discontinuation announcements may inform product decisions, but accessibility does not establish suitability. An AI-discovered claim that two components are interchangeable must be checked against the exact versions, operating conditions and manufacturer documentation. Citing the UK National Cyber Security Centre, Oleg distinguishes provenance—evidence of information’s history—from proof that its contents are true. Organizations must also consider how to preserve external evidence if a webpage changes or disappears. Finding a document should begin evaluation, not automatically make it accepted evidence. Trust is therefore contextual rather than a permanent designation. An approved drawing may support design review but not establish purchasing availability or the installed configuration of a serviced unit. Jos Voskuil and Rob Ferrone’s discussion of data quality reinforces this point: estimated costs can be sufficient during design but inadequate when ordering, while distrust can drive offline reporting and conflicting versions. Oleg proposes five checks: source, applicability to a product/configuration/time period, validation and remaining assumptions, changes since acceptance, and responsibility for resolving uncertainty. The digital thread provides traceability across lifecycle stages and systems, linking requirements to designs, changes to implementation, and delivered units to configuration records. Michael Finocchiaro’s thread-centric PLM perspective connects this architecture with trustworthy engineering AI. Nevertheless, links alone do not establish agreement: connected records may concern different configurations, a visible change may remain unimplemented, and an attached document may not have been accepted. AI must similarly distinguish approved decisions from suggestions, identify revision mismatches and missing evidence, and separate established records from interpretation. The assurance needed should rise with the consequences of summarizing an issue, recommending a substitution or executing an order. AI could help build and maintain these connections by comparing information and flagging misalignments. The article references a pilot described by Ferrone combining expert-defined quality rules, AI anomaly detection and initial human review. Proposed relationships, however, must remain distinguishable from verified ones, be open to inspection and challenge, and potentially be reassessed when sources change. Other possibilities include assembling evidence around individual decisions, sharing context while organizations retain their own systems, and continuously checking whether earlier decisions remain valid. These are exploratory directions, not established solutions. “Product memory” could preserve decisions, assumptions, disagreements and reasoning—for example, why a substitution was approved only under particular operating conditions. It might help people and AI avoid overgeneralizing approvals or revisit them when evidence changes. But explanations can be incomplete, assumptions outdated and informal suggestions never accepted. Voskuil’s challenge about how knowledge graphs “unlearn” underscores the need to correct interpretations rather than merely retain history. Oleg concludes that traceability is foundational but insufficient without context, timing, agreement and authority. He keeps the architectural question open and discloses that his role as OpenBOM co-founder and CEO, including work on connected product data and Product Memory, shapes his perspective.