For years, BOM review was often treated as a procedural step between engineering and release. Teams created bills of materials, checked them manually, fixed obvious mistakes, and eventually pushed the data downstream into procurement, manufacturing, ERP, and supply chain systems.
It was never a glamorous part of PLM.
But AI is changing the economics of BOM quality very quickly.
The more companies invest in AI-driven workflows, the more dangerous incomplete or context-free BOM data becomes. AI agents can now analyze structures, recommend suppliers, compare alternatives, route workflows, generate procurement actions, validate compliance, and coordinate downstream processes at a speed impossible for humans alone. This creates enormous opportunities for engineering and manufacturing organizations. But it also introduces a new risk.
AI amplifies both good and bad product data.
For decades, companies could survive with fragmented product information because humans compensated for missing context through meetings, tribal knowledge, spreadsheets, email threads, supplier calls, and engineering intuition. Engineering organizations became surprisingly good at operating despite disconnected systems and incomplete records.
AI does not work this way.
AI agents cannot reason reliably from isolated BOM tables alone. They require connected context assembled from multiple engineering and business systems. And this is exactly where traditional BOM release processes begin to show their limitations.
Why Traditional BOM Release Workflows Were Not Designed for AI
Most PLM workflows still operate around a relatively simple model: Draft, Review, Release.
This model assumes that the BOM itself is already sufficiently complete and understandable before review begins. In reality, that is rarely true.
A BOM can be technically created while still missing supplier information, sourcing alternatives, compliance data, manufacturing constraints, approved documentation, ERP attributes, revision consistency, cost assumptions, substitution rationale, and downstream operational context.
The traditional release process was designed primarily for governance and control. It was not designed for collaborative reasoning across fragmented information sources.
As a result, most BOM review work still happens outside the system, in spreadsheets, screenshots, Slack messages, supplier emails, engineering meetings, and disconnected review comments. The BOM lives in one system. The reasoning about the BOM lives somewhere else.
This gap becomes dramatically more important in the AI era.
Why AI Needs Context, Not Just BOM Records
One of the biggest misconceptions in enterprise software is the assumption that systems of record alone provide enough information for intelligent decision-making.
They do not.
A released BOM record might contain part numbers, quantities, revisions, and lifecycle states. But the reasoning behind product decisions is often distributed across many disconnected systems and conversations.
Why was a supplier substituted? Why was a component approved despite higher cost? Why did manufacturing reject a previous configuration? What unresolved risk exists in a subsystem? Which assumptions were temporary? Which drawing version was used during review?
Humans often reconstruct these answers socially. AI cannot reliably reconstruct them unless context is connected explicitly.
This is why the challenge is no longer simply managing BOM data. The challenge is assembling enough connected context for humans and AI agents to reason together effectively.
How AI Turns Incomplete BOM Context into Operational Risk
Consider a mechanical engineer who releases a SOLIDWORKS assembly BOM with solid structure but missing supplier alternates for two critical components. The BOM passes review. It looks complete. An AI sourcing agent immediately picks it up, identifies the primary supplier as the obvious choice, and propagates a purchase order without knowing that the primary supplier has an active end-of-life notice on exactly those parts. Procurement finds out three weeks later.
This is not an AI failure in the way most people imagine. The model worked correctly with the information it had. The failure was a context failure. The AI had access to a record. It did not have access to the reasoning environment that a knowledgeable engineer would have drawn on.
Historically, BOM mistakes created delays, rework, and operational friction that teams absorbed manually. AI changes this dynamic completely. An automated procurement workflow can propagate obsolete component selections at scale. A manufacturing assistant can generate incorrect planning assumptions from partially reviewed structures. An AI system analyzing product readiness can produce convincing conclusions while lacking critical context hidden in disconnected documents or tribal knowledge.
AI failures in engineering workflows are often not model failures. They are context failures.
The issue is not only whether the AI is powerful enough. The issue is whether the AI can access enough connected product information to reason correctly.
This is why BOM review is evolving from a procedural approval step into something much more important. It is becoming a collaborative context-building process.
What a BOM Sandbox Is and Why AI Makes It Necessary
This is where the idea of a BOM sandbox becomes important.
A BOM sandbox is not simply another draft BOM. It is not only a redline workflow or engineering change process. Traditional PLM systems already provide mechanisms for baselines, revisions, impact analysis, and controlled change management. Those capabilities remain essential. But they address a different problem.
Traditional change management assumes someone already knows what must change. Sandboxing is different. Sandboxing is exploratory. It is a reasoning environment where teams discover what still needs to be understood before release can happen safely.
How does your team currently manage the gap between BOM creation and release? Where does that work actually happen today?
For most organizations, the honest answer is: in spreadsheets, in meetings, and in individual engineers’ heads. The sandbox concept makes that work explicit, structured, and connected to the actual product data.
A BOM sandbox is a collaborative environment where teams can compare alternatives, test sourcing assumptions, evaluate substitutions, identify missing information, review manufacturing readiness, connect related documents, discuss unresolved questions, validate metadata completeness, track review tasks, and preserve engineering rationale without immediately committing operational changes into released structures.
Before AI and humans can make reliable product decisions together, they need a workspace where fragmented product information can be assembled, reviewed, enriched, questioned, and reasoned upon safely before release.
That workspace is the sandbox.
Why BOM Sandboxing Is Not the Same as PLM Change Management
It is worth being precise here, because this concept can be confused with existing PLM capabilities.
Traditional PLM sandboxing, including redlines, what-if analysis, impact analysis, and baselines, is change-control oriented. It is designed for managing the mechanics of what changes, when, and under whose authority.
AI-era BOM sandboxing is reasoning-context oriented. It is designed for assembling the connected information environment that humans and AI agents need to discover what must change before formal change and release begin.
This is not a replacement for change management. It is the upstream layer that improves the quality of what enters change management.
The sandbox acts as a temporary context layer combining BOM structures, metadata, linked documents, ERP attributes, supplier information, engineering discussions, review comments, historical decisions, and operational signals into one collaborative reasoning environment. This is fundamentally different from a static released BOM, a document vault, or a transactional PLM workflow.
Why AI-Native Engineering Requires a New Layer Above Systems of Record
For many years, PLM systems focused primarily on controlling records, revisions, and lifecycle states. These capabilities remain essential. But AI introduces a new architectural requirement above systems of record.
AI-native engineering workflows require environments where context can be assembled continuously across fragmented enterprise data.
This is why collaborative workspaces, Product Memory concepts, usage of context graphs in PLM, and collaborative review environment are becoming increasingly important in the next generation of engineering platforms.
The future BOM Review Agent will not behave as a simple checker validating rows in a table. It will continuously assemble context from multiple systems, identify gaps, detect inconsistencies, coordinate review tasks, surface unresolved questions, and help teams evaluate readiness before operational commitment occurs.
In this model, review becomes more than approval. Review becomes the control layer between automated reasoning and operational execution.
We Built the Collaborative Foundation — Now We Are Adding AI Reasoning
This is not a concept without roots.
OpenBOM has already built and deployed a multi-user collaborative workspace that allows engineering, procurement, manufacturing, and supply chain teams to bring product data from multiple systems into a single shared environment and work through complex change processes together. This capability is live, used by OpenBOM customers today, and represents something we have not seen replicated elsewhere in the market.
That workspace is the sandbox infrastructure this article describes. It exists. It works. Customers are using it to manage exactly the kind of cross-functional BOM reasoning that traditional PLM workflows push into spreadsheets and email.
What we are developing now is the next layer: making that collaborative workspace AI-assisted. The BOM Review Agent will operate within this environment, assembling context, detecting gaps, coordinating review tasks, and helping teams evaluate readiness before release, not as a standalone tool, but as an intelligence layer on top of a proven multi-user foundation.
The Real Question Is Whether Your Product Data Is Ready for AI
AI does not eliminate the need for BOM review. AI makes BOM review dramatically more important.
The question engineering organizations should be asking is not whether they will adopt AI in their workflows. That decision is already made in most industries. The real question is whether their product data will be ready for it.
A BOM that was good enough for human review may not be good enough for AI reasoning. The bar is higher because AI does not ask follow-up questions, call the supplier, or check with the manufacturing engineer down the hall. It reasons from what is connected and available.
Companies that invest in BOM review infrastructure now, with collaborative workspaces, structured context, and clear ownership of readiness, will find AI adoption dramatically smoother. Companies that skip this step will discover that AI amplifies exactly the fragmentation they were hoping it would solve.
BOM sandboxing is not a workaround. It is an architectural foundation.
Looking for Companies Ready to Experiment with AI-Assisted BOM Review
If you are experiencing the BOM review problem this article describes, we want to talk to you.
We are looking for a small number of companies willing to experiment with AI-assisted BOM review workflows, share honest feedback, and help shape what this becomes. No formal program, no sales process. The right conversation is with engineering or operations leaders who feel the cost of fragmented BOM context in their daily work and want to explore what structured AI-assisted review could look like in their environment.
There are two ways to get started.
If you want to explore the collaborative BOM workspace that already exists today, you can register for free at OpenBOM and connect it to your own product data environment. No installation, no commitment. You will see immediately how multi-user collaborative BOM management works in practice and whether it fits the problems your team is facing.
If you want to go deeper and discuss the BOM Review Agent direction specifically, reach out directly via LinkedIn or via email. I am genuinely interested in what you are seeing in your organization and where the biggest friction points are in your current BOM review process.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
