PLM data quality becomes a practical problem whenever people need to make a decision using information from different systems. Engineering has an approved design. Purchasing has an order. Manufacturing has a plan. A supplier has new information. What makes these records reliable enough to act on together?
Michael Finocchiaro put a request for the next Future of PLM Webinar and I thought this topic might be an interesting candidate. The phrase “AI needs a good data” is everywhere, but it doesn’t say “what good looks like”.
I have to agree that AI makes this question more urgent. Before asking whether we trust an AI answer, we should ask whether we trust the information behind it and understand where that information applies.
“Can you trust your product data?” is a question I’d like to explore in an upcoming Future of PLM discussion. We have systems to control access, track revisions, and approve changes. These capabilities matter. But what do they allow us to assume when evidence crosses departments, organizations, and public sources?
The digital thread offers an approach to connecting that evidence. AI could help discover and interpret relationships. Other ideas, including product memory, might preserve the context behind decisions. I want to explore what each approach contributes and what questions remain open.
A Simple Question at a Production Meeting
Imagine a production readiness meeting. Engineering brings an approved design. Purchasing has confirmed orders. Manufacturing has prepared its production plan. Meanwhile, a supplier has sent an email explaining that a component needs to be substituted.
Everyone has information they believe is correct. Can the team proceed?
The answer depends on how these pieces fit together. Does the proposed substitution require an engineering change? Has anyone accepted it? Do the orders and production plan reflect the same configuration?
No single record necessarily contains an error. The records might describe different stages of a decision that has not yet been completed.
Product data can be correct within its own context and still be insufficient for a shared decision.
What should our systems help us recognize before someone acts?
Why Product Data Quality Spans Multiple Systems
Engineering, purchasing, manufacturing, service, and suppliers maintain information for different purposes. Relevant details also appear in spreadsheets, documents, emails, and conversations.
An engineering record describes design intent. A purchase order records a commitment. A manufacturing record describes execution. Differences can be legitimate, or they can reveal an incomplete handoff.
Asking “Which system is right?” might therefore be too narrow. We first need to understand what each record represents and where it applies.
CIMdata’s Data Governance: Establishing and Maintaining Trust in Information brings an organizational perspective to this problem through policies, responsibilities, decision rights, and accountability across the extended enterprise.
Bringing records together can reveal disagreement. Establishing trust also requires someone with the authority to resolve it and communicate the outcome.
I explored a related question in PLM Adoption Challenges: Should We Question the Organization or the Architecture?: how can software and organizational practices develop together to make coordination easier?
Question for discussion: How do we establish trust when evidence and responsibility span multiple systems and organizations?
Can You Trust Public Product Data?
Product decisions can depend on manufacturer specifications, distributor catalogs, material databases, published standards, regulatory notices, and discontinuation announcements.
Public availability makes information accessible. Its suitability for a decision still needs to be established.
Consider an AI agent finding a listing suggesting that two components are interchangeable. Who published the claim? Does it apply to the exact version and operating conditions? What if the manufacturer’s documentation differs?
The UK National Cyber Security Centre makes a useful distinction in its guidance on securing digital trust: provenance provides evidence about information’s history without establishing whether its content is true.
For product decisions, understanding the source is one part of verification. Currency, applicability, and supporting evidence also matter.
There is a preservation question too. If a page changes or disappears, can we reconstruct the evidence used to approve a substitution? Should we retain a dated copy or version reference?
Question for discussion: When does external information become accepted evidence inside the organization, and who validates that step?
An AI agent finding a relevant document should begin that evaluation, not silently complete it.
What Makes Product Data Trustworthy?
Trust becomes more concrete when we connect it to an intended use.
An approved drawing may support a design review. Ordering components requires additional information about availability and authorized substitutions. Servicing a particular unit requires knowing what was installed.
Jos Voskuil and Rob Ferrone address this directly in Data Quality and Data Governance — A Hype?. Rob explains that the required maturity of information depends on timing: an estimated cost may be acceptable during design but insufficient when ordering. Their discussion also describes how distrust encourages offline reports and conflicting versions, making confidence harder to restore.
This suggests five practical questions before acting:
- Source: Where did the information come from?
- Applicability: Which product, configuration, and period does it describe?
- Validation: What was verified, and what remains an assumption?
- Change: What has changed since it was accepted?
- Responsibility: Who can resolve uncertainty or disagreement?
These questions help assess suitability for a decision. They also prevent trust from becoming a permanent label attached to a record.
Question for discussion: Can we meaningfully call data trustworthy without stating what we intend to do with it?
How the Digital Thread Supports Product Data Trust
The digital thread offers an approach to connecting product information and preserving traceability across lifecycle stages and systems.
Can we follow a requirement to the design addressing it? Can we trace a change to implementation? Can we connect a delivered unit to its configuration records?
In What Is Thread-Centric PLM?, Michael Finocchiaro presents the digital thread as an organizing principle for PLM and connects that architecture with trustworthy AI in engineering.
This gives us a useful position to discuss. Traceable relationships provide a path for investigating why information should apply to a decision.
That path may cross company boundaries and reach public sources. It may need to identify the supplier specification consulted during approval.
However, two linked records may describe different configurations. A change may be visible without being implemented. A document may be attached without its contents being accepted.
Question for discussion: What can a digital thread establish about trust, and what still requires verification?
The value of a connection depends partly on whether users understand its meaning, status, and limitations.
Why AI in PLM Depends on Reliable Product Data
Return to the production meeting and imagine an AI agent being asked, “Can we proceed?”
It finds an approved design, confirmed orders, an open change, and a supplier exception. A useful response requires understanding how those records relate and which uncertainties matter.
Can the agent distinguish an accepted decision from a suggestion in an email? Can it recognize that a specification applies to another revision? Can it explain that the answer depends on missing evidence?
Showing sources helps, but those sources must support the conclusion and apply to the situation.
The required assurance should also reflect the action. Summarizing an issue, recommending a substitution, and authorizing an order carry different consequences.
An agent may need to explain the uncertainty and involve someone with the authority to decide. It should make clear which part of its response comes from established records and which part is interpretation.
Question for discussion: What should AI verify before recommending an action, and what additional evidence should it require before executing one?
That is a practical starting point for discussing trust in PLM AI.
Can AI Build and Maintain the Digital Thread?
AI could also help establish the connections needed to investigate trust.
In Data Quality and Data Governance — The WHY and HOW, Jos and Rob explore AI comparing information across teams and flagging misalignments. They acknowledge that discrepancies can be valid depending on context. Rob also describes a pilot combining expert-defined quality rules with AI anomaly detection and initial human review.
This provides a concrete direction to examine. AI might identify that a supplier message concerns an engineering change or flag records that appear inconsistent.
But if AI proposes a relationship, how do we distinguish it from one explicitly established and verified? A plausible connection can support investigation without being sufficient for action.
Users need to inspect the evidence, challenge the interpretation, and see whether it has been validated. Connections may also need reassessment when source information changes.
Question for discussion: How do we prevent an AI-driven digital thread from making uncertain relationships look established?
Finding a discrepancy is valuable. Determining whether it requires action is another responsibility.
What Comes Next for the AI-Driven Digital Thread?
An AI-driven digital thread is one possible direction. We should also consider alternatives and complementary approaches.
Could systems assemble evidence around a specific decision when needed? A substitution review might bring together requirements, specifications, prior approvals, and unresolved exceptions.
Could organizations establish shared context while maintaining information in their own systems? What would they need to agree on about identity, applicability, ownership, and change?
Could continuous checks identify when the conditions supporting an earlier decision no longer hold?
These approaches may overlap with what people already mean by a digital thread. We should clarify the capabilities before settling on terminology.
A practical comparison could begin with the same production decision. Can each approach identify the relevant configuration, expose unresolved disagreements, explain its evidence, and direct questions to the responsible people?
Question for discussion: Are we extending the digital thread, changing how it is created, or exploring a different way to organize product knowledge?
I would like to hear examples of what works and where the effort remains too high.
Could Product Memory Help?
One idea I’m interested in exploring is product memory: preserving decisions, assumptions, disagreements, and explanations behind product data as it changes.
I discussed this concept in What Is Product Memory?. Here, I want to examine whether that context could help people and AI assess why an earlier conclusion was accepted and when it needs reconsideration.
Consider a substitution approved under specific operating conditions. Preserving the reasoning could prevent someone from applying that approval too broadly. Retaining external evidence could help reassess it when the source changes.
Jos raises a valuable challenge in Do We Need Artificial Product Memory?. He questions assumptions about perfectly validated information and asks how knowledge graphs can unlearn.
Those concerns deserve attention. Explanations can be incomplete. Assumptions become outdated. Informal discussions contain suggestions that were never accepted. Preserving history creates a responsibility to distinguish these states and correct earlier interpretations.
Question for discussion: Would product memory complement the digital thread, become part of it, or describe capabilities we already expect PLM to provide?
It should be evaluated against the same practical trust questions as any other approach.
What Is My Conclusion?
Trust in product data depends on our ability to inspect evidence, understand where it applies, and recognize unresolved uncertainty before acting.
Connected information and traceability provide an important foundation. Product decisions also involve authority, agreement, timing, and context. Public information expands the available evidence while adding questions about verification and preservation.
AI makes these issues more visible because it can interpret information and participate in actions. We should expect it to explain what supports a conclusion and recognize when the evidence is insufficient.
For the Future of PLM discussion, I would like to keep the architectural question open. What should a digital thread guarantee? Where could AI help? What alternatives or complementary approaches, including product memory, should we examine?
Have you encountered product data that was technically correct but insufficient for a decision? What was missing: a connection, context, an explanation, or agreement between the people involved?
And final question for the webinar: What should future PLM systems help us verify before we act?
Just my thoughts…
Best, Oleg
Disclaimer: I’m 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.
