Why AI needs the product situation, not only the product definition
Imagine an engineer asking an AI assistant a simple question: can we replace this motor with an equivalent model? The assistant compares power, speed, torque, dimensions, voltage, and mounting interfaces. It finds a motor with nearly identical technical characteristics and produces a confident recommendation. On the surface, this is exactly the kind of work AI should perform well.
You can see how engineering AI and chatbots provided by PLM tools demo similar capabilities searching in existing PDM/PLM databases and online catalogs. This is actually very encouraging The specifications are available, the comparison is clear, and the answer is technically plausible. It can still be the wrong decision.
But here is the thing… The proposed motor may not satisfy a customer-specific noise requirement. It may come from a supplier that is not approved for production. Its connector may fit, but the factory may not have the tooling required to terminate it. The replacement may invalidate a certification, interfere with a service procedure, or create an incompatibility with thousands of products already installed in the field. A previous engineering change may have considered and rejected exactly the same alternative after a vibration test. Procurement may know the supplier cannot meet the required volume. Quality may have an open corrective action. Support may already be seeing a failure pattern that has not yet reached engineering.
Every technical fact in the AI’s answer can be correct, and the recommendation can still be wrong. The AI understood the component. It did not understand the product situation.
Product Definition Is Not Product Situation
This distinction is, in my view, the central problem of AI in product development and manufacturing. So, let me formulate it precisely.
The product definition is what our industry has spent forty years learning to manage: CAD models, specifications, BOMs, requirements, revisions, configurations, and the change processes that govern them. This is the territory of PDM and PLM, and it remains essential. A company that cannot control its product definition has no foundation to build on.
But let’s think about situational awareness and decision support. The product situation is larger. It includes supplier capacity and approval status, inventory of existing components, active quality holds, manufacturing constraints on specific production lines, the configurations delivered to specific customers, the installed base in the field, service history, and the current business conditions surrounding a decision. The product definition tells you what the product is. The product situation tells you what is happening to the product now, how it reached this state, and what will be affected by the next decision. The word is deliberate. Aerospace and operations teams have long distinguished knowing the system from situational awareness, and product organizations making decisions with AI need exactly that awareness: not a better description of the product, but an understanding of the situation the product is in.
AI does not need access only to the product definition. It needs access to the product situation for decision support and actions.
A useful way to think about this is to separate three levels of context. System context is what one application knows. Domain context is what one function knows. Product decision context is what must be assembled across systems and domains to understand and act on a particular situation. The motor question looks like an engineering question, but answering it correctly requires the third level. It touches requirements, engineering, procurement, supply chain, production, quality, service, and the customers who own the installed products. No single system holds that picture, and no single function does either.
Context Is Produced, Not Retrieved
The most common enterprise response to this problem is to give AI more access. Connect more systems, index more documents, build a larger data lake, deploy more retrieval infrastructure, and use models with bigger context windows. Access improves, but understanding does not automatically follow. A larger collection can contain current and obsolete drawings, conflicting BOM exports, expired and active supplier quotes, proposed and approved changes, several meanings of the word “approved,” and different identifiers for the same physical component. Without a way to determine identity, authority, applicability, and time, more data can mean more ambiguity. I wrote about this in more detail in Bigger AI Context Windows Will Not Fix Your BOM. The context window is a container. Product context is a constructed model of the decision.
This leads to a distinction that I think matters more than any specific AI technique: context is not simply found, it is produced. Someone or something must establish the scope of the question, resolve identities across systems, select the applicable configuration, determine which source is authoritative, follow the relationships that matter, reconcile conflicting evidence, and identify what is missing. Retrieval, connectors, and knowledge graphs deliver ingredients. They do not perform this assembly on their own.
Three Ways Missing Context Becomes a Confident Wrong Answer
Let me start from a personal story. I bought a microphone that didn’t fit my existing boom arm. I contacted support and received a precise and straightforward answer: “You need a connector. Here is a link, buy it.” I did, but it didn’t work. After multiple back-and-forth exchanges, I shared photos of the microphone, its packaging, and the user guide with ChatGPT, which identified the problem: Amazon had mistakenly shipped me an EU package. Without the correct context, the vendor’s support team failed to provide the right answer.
When AI produces a wrong answer in an engineering environment, we usually describe the failure in the language of the large language model, or how we usually say it: it hallucinated, it made something up, it was confidently wrong. That language obscures the actual mechanism. In many product situations, the model performed its task competently in the context it was given. The failure happened because a piece of context was missing, and the system had no way to know it was missing. Here are three examples to demonstrate the pattern.
The first is the wrong revision. An assistant retrieves a specification for a component and answers a question about its dimensions and ratings. Every fact in the answer is accurate, but the retrieved document describes revision C while the active product configuration uses revision E. Nothing in the document collection told the system which revision applied, so it answered correctly about the wrong product state. This is not a hallucination. It is missing temporal and configuration context.
The second is the technically valid but unapproved substitute. A candidate component matches form, fit, and basic function, and the assistant recommends it. What it could not see, or could not connect, was the qualification test the candidate failed two years earlier, the customer restriction that excludes the supplier, or the ECO discussion in which the same alternative was evaluated and rejected. The model solved component matching. It failed the product decision.
The third is the misleading cost comparison. The assistant compares two supplier quotes and recommends the cheaper one. It does not know that one price includes tooling amortization, that the other applies only above a volume threshold, that one quote expired last quarter, or that the preferred supplier currently has a quality hold. The numbers were present in the context. Their meaning, applicability, and current operational state were not.
There are many other examples and I will talk about them later. But the pattern across all three is the same. Many apparent AI failures are not failures of the language model. They are failures of context architecture. In the book chapter behind this article, I describe that architecture as having seven dimensions: identity (are we discussing the same object across systems?), structure (how is it connected, and to what?), semantics (what does “approved” or “equivalent” mean in each domain?), time and configuration (when and where was it true?), decision history (why was this choice made?), operational state (what is happening right now?), and governance (what is allowed, and who is accountable?). The three failures above are not mysterious once you have these names. The wrong revision is missing time and configuration. The unapproved substitute is missing decision history and governance. The cost comparison is missing semantics and operational state.
That diagnosis matters, because the two readings lead organizations in opposite directions. If the model is the problem, the answer is better prompts and bigger models. If the context architecture is the problem, the answer is building the layer that can assemble the product situation around a decision.
From Plausible Answers to Applicable Decisions
Return to the motor question. A genuinely useful AI assistant should not merely report that the replacement motor matches the technical specification. It should be able to show which product configuration it evaluated, which requirements apply, which supplier and factory constraints were considered, which products and customers would be affected, what evidence is missing, and who must review and approve the decision. Everything on that list exists somewhere in the organization. Almost none of it lives in one system, and none of it arrives in an AI prompt by accident.
This is the role I see for Product Memory: a persistent, connected, and explainable layer of product context that can assemble the product situation around a decision, while PLM, ERP, MES, QMS, and service systems remain the authoritative owners of their own records. Not another database, and not a replacement for any of these systems, but the layer that makes their knowledge meaningful together.
AI does not become reliable in product development because the model is larger, the prompt is longer, or every application has a chatbot. It becomes reliable when the organization can provide the model with enough context to distinguish a plausible answer from an applicable decision. Context does not make AI infallible. It makes AI’s reasoning bounded, traceable, and reviewable. In engineering and manufacturing, that is the difference between an impressive answer and a useful assistant.
I develop this argument in full in my upcoming book, From CAD Files to Product Memory, where an entire chapter examines the seven dimensions of product context and what happens to AI when each one is missing. This article is an extract from Part V, “AI and the Future of Engineering Transformation,” Chapter 16, “Why AI Needs Context.” Subscribers to the book get draft chapters and the reasoning behind them as the work develops. Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
