One BOM, Many Reviewers, One Context

Over the last three days I have looked at BOM Review from three angles. I explained that a BOM review is not a single meeting but something that happens at every handoff, whenever one team accepts responsibility for product data created by another team. I described our development and shared more information about the anatomy of a BOM Review Agent: the structured product context, the collaborative workspace, the check cards, the findings, comments, and tasks, and the feedback loop created by running the checks again. And I provided more details and explained the connection between BOM quality and review process. 

Today I want to connect those three arguments, and the thing that connects them is a failure mode I see in almost every manufacturing company I talk to.

Call it BOM context collapse. During a review, everyone understands the situation. The engineering manager knows why an exception was accepted. The buyer remembers which supplier promised accelerated delivery. Manufacturing understands why a temporary substitution is acceptable for the prototype build. Three months later the information is barely exists. In fact, it exists in multiple places (system of records), but then problem starts – BOM in PLM (or Excel) exists, revisions exist in PLM, but then multiple pieces of information are distributed in MRP/ERP, finance, product planning, MES and other systems. Why a specific change or decision was made is lost. An email contains the explanation, but nobody knows which email. A task says “resolved,” and the resolution sits in a system that has no connection to the revision where the decision was actually made. A new engineer inherits the final data and none of the reasoning that produced it.

The data survives. The explanation disappears.

Context collapse is not caused by careless people. It is caused by a review process that moves work between people by moving copies of the product between systems. Everything that is not a copied value gets left behind. This is the problem a collaborative BOM Review Agent is built to solve, and it is why the answer is not one intelligent system reviewing a spreadsheet. It is many reviewers, human and software, working against one shared product context.

Serial Review Guarantees That Context Will Be Lost

Most companies already have plenty of people participating in BOM review. Engineering checks the design structure. Procurement checks suppliers, cost, and availability. Manufacturing looks at assembly and production requirements. Quality examines compliance and traceability. Service eventually checks what has to be supported in the field.

The problem is not an absence of collaboration. The problem is the shape of it. An engineer exports a spreadsheet and sends it to purchasing. Purchasing adds columns and forwards it to manufacturing. Manufacturing saves another copy with comments. Someone attaches drawings to an email. Someone else opens a list of issues in a project management tool. Every participant is doing reasonable work, and the process is still serial: each person waits, creates another representation of the product, and passes it along.

The files multiply and the product fragments. A question about a component becomes separated from the component. A decision is recorded in a message thread while the change is made in a spreadsheet. By the time the review is finished, the team holds several answers attached to several versions of the same BOM. That is coordination. It is not a shared review, and it is the mechanism by which context collapses.

Collaboration Is More Than Sharing a Document

PLM calls “collaboration” the ability of users to access the same data. Software vendors usually describe collaboration as the ability to share a file, leave a comment, or notify a colleague. Those capabilities are useful and they are not sufficient for product development.

Real BOM collaboration requires everyone to work against the same identities and the same relationships. When an engineer, a buyer, a manufacturing planner, and a quality manager discuss a component, they need to be discussing the same item, in the same assembly, at the same revision, with the same drawings, supplier records, quantities, and change history behind it. The conversation has to stay attached to the product structure or it becomes another artifact to reconcile later.

This is what the OpenBOM collaborative workspace provides, and it is the environment BOM Review runs inside rather than a report it produces on the way out. Multiple users work in the same BOM at the same time. 

They see color coded findings against the actual rows. A comment is attached to real product data, not to a screenshot of a row. A task stays connected to the item, assembly, property, or relationship where the problem was found, instead of being retyped as a description of a problem in a separate tracker.

That distinction sounds small. It is the whole thing. It means the context survives while the work moves between people.

A Check Card Is a Reviewer With Exactly One Job

Human participants are one half of the review team. The other half is a growing set of software reviewers, and in OpenBOM each one is a check card.

Every card has a narrow responsibility. One checks part number rules and identity. One checks that required properties are present. One compares quantities against reference designators. One examines product structure, including circular references that quietly break downstream consumption. Each card asks a specific question, produces findings you can explain to a colleague, and can be improved or replaced without touching the others. That separation is deliberate. A single large validation engine gives you a verdict; a set of narrow cards gives you a review you can reason about.

Next week we are adding the AI BOM Health card, which performs a broader analysis across the complete hierarchical BOM rather than testing one dimension of it. It is worth being precise about what that means. The rule based cards are deterministic: the same BOM produces the same findings. The AI card is not. It reasons over the structure and surfaces conditions that are harder to express as a fixed rule, and like any model based analysis it can be wrong, miss something, or flag something that turns out to be fine in context. It is a reviewer with broad reach and imperfect judgment, which is exactly why it belongs alongside people rather than in front of them.

Beyond what ships today, the direction we are exploring is more specialists rather than a bigger engine: sourcing readiness, component lifecycle, compliance, cost, inventory position, manufacturing requirements. None of those are available yet. What matters architecturally is that when they arrive, they will not exchange spreadsheets with each other. They will operate against the same connected BOM context that people are working in.

One Product Structure Can Answer Everyone’s Question at the Same Time

Take an ordinary product with several hundred components and a few levels of subassembly. The mechanical engineer wants to know whether every manufactured part has a material and a drawing. The electrical engineer wants reference designators reconciled against quantities. The buyer wants purchased components with no supplier information. Manufacturing wants subassemblies missing production instructions. Quality wants to confirm required certificates are attached. The engineering manager only wants to know which issues block release.

Traditionally each of those people extracts what they need and builds a private view of the problem, which is six new places for context to leak out. In a collaborative review, all six questions are applied to the same structured product model. Different users work through different findings simultaneously. Different check cards examine different dimensions of the same structure. Every result points back to the product data that produced it.

The speed is nice. The durability is the point. Nobody has to reconstruct the context each time responsibility moves.

Agents Find Problems, People Decide What They Mean

The word “agent” tends to raise an expectation that software will review the product independently, fix everything, and approve the release. That is not what we are building.

A check card can tell you a required property is empty. It cannot know whether that is entirely expected during concept development or whether it will stop a purchase order tomorrow morning. The AI card might notice that two units are on hand against a planned build of four. It can surface the discrepancy. A person still has to determine whether another PO is open, whether the build quantity changed last week, or whether the shortage is simply acceptable.

The agent contributes reach, speed, and consistency. It will examine thousands of relationships without getting tired or skipping a row at four in the afternoon. People contribute judgment, priority, accountability, and knowledge of the business situation. The review is what happens between them. A finding can be reviewed and dismissed because it is expected at this maturity level. It can become a comment when more information is needed. It can become an assigned task when data has to be corrected. After the correction, the card runs again and confirms whether the condition still exists. The agent does not replace the review team. It gives the team a repeatable way to apply its judgment, and it records the application.

Context Is Not the Same Thing as a Context Window

People often use “context” to mean how much text fits into a model. For BOM Review it means something much more specific: the identity of every item, the hierarchical structure, quantities and reference designators, properties and classifications, revisions and lifecycle states, attached drawings and documents, supplier and inventory records, and the comments, findings, and tasks accumulated against all of it. Context is the relationships connecting those objects, not the objects themselves.

Dropping a folder of spreadsheets and PDFs into a general purpose AI tool does not produce that. The model has to infer which rows refer to the same component, which file belongs to which revision, and how the assemblies connect. Sometimes it infers correctly. You will not reliably know when it did not. OpenBOM represents parts, assemblies, properties, quantities, files, and supplier records as connected product data, so the relationships are explicit rather than reconstructed. Shared context is what lets people and agents refer to the same thing and reach one decision instead of six opinions.

Continuous Review Is What Makes “Ready With Exceptions” Real

Once review runs against live product data rather than an exported copy, it no longer has to wait for a release meeting. Checks run as the BOM develops. People address findings when those findings become relevant to their work. Procurement can start reviewing purchased components before engineering declares the structure finished.

That does not mean every issue gets resolved immediately. A concept BOM will be incomplete by definition. A prototype BOM will carry temporary parts. A production BOM answers to a different standard. The purpose of continuous review is not to demand production completeness on day one. It is to make the current condition visible so the team can decide what matters now.

In the article on BOM quality I described three practical states. Ready means downstream teams can proceed. Ready with exceptions means known risks have named owners and approved dispositions. Not ready means something blocking is missing. The collaborative process is what makes the middle state anything other than an informal promise. Without recorded ownership and rationale, “ready with exceptions” is a verbal agreement that evaporates on the same schedule as everything else. With the finding, the discussion, the owner, and the disposition attached to the BOM, it becomes a controlled decision that is still legible in six months. That accumulated history, the answer plus the reason plus the person plus the conditions under which it was acceptable, is what I mean by Product Memory.

Your Company’s Rules Should Not Live in One Person’s Head

The most valuable check cards will not be the ones we build at OpenBOM. They will be the ones built from company knowledge.

Every manufacturer has rules learned the expensive way. A particular category of purchased part requires two approved sources. A prototype assembly requires a specific test document. A component above a defined lead time threshold needs purchasing approval. A service BOM must include a replacement procedure. A customer configuration cannot combine two specific options. Today those rules live in the memory of experienced employees, in private spreadsheets, in procedures nobody reads, and in stories about a failure that cost a lot of money five years ago.

Turning those rules into check cards makes company knowledge an active participant in every review. The rule stops waiting for the one person who remembers it to be free on Thursday. It examines every applicable BOM, surfaces the condition, and pulls the right person in when judgment is actually required. The software carries the rule. The person carries the judgment. The workspace keeps both attached to the product.

Autonomous Approval Is the Wrong Goal Right Now

I do not think the objective should be an AI agent that approves a BOM without people. Product decisions carry too much business context, too much incomplete information, and too much deliberately accepted risk for that to be credible today.

The useful goal is a review environment where multiple people work the same BOM at once, multiple check cards examine different aspects of it, findings stay connected to the exact data that produced them, discussions stay connected to the findings, tasks have owners, corrections happen in product context, checks re-run as the BOM changes, and the resulting history becomes organizational knowledge rather than personal recollection.

That is not a chatbot reviewing a spreadsheet. It is a team of people and agents working through product decisions together, and it is the only version of BOM review I have seen that does not lose the reasoning within a quarter.

BOM Review starts with validation, but validation is the entry point rather than the destination. The larger opportunity is a shared surface where engineering, procurement, manufacturing, quality, and software agents can work through product readiness without breaking the product into disconnected files, messages, and reports. People bring different responsibilities. Check cards bring different analytical capabilities. The BOM provides the context that holds it together.

The future of BOM review is not one agent making one decision. It is many reviewers asking different questions of one product, and keeping the answers where the next person will find them.

We are looking for design partners. We are specifically interested in companies whose BOM review rules currently live in procedures, private spreadsheets, or the knowledge of experienced team members, because those are exactly the rules we want to turn into reusable OpenBOM check cards. If that describes your organization, contact us to talk about becoming a design partner. In the meantime, register for OpenBOM and run BOM Review against your own product structure.

Best, Oleg

Frequently Asked Questions

What makes BOM Review collaborative? 

BOM Review runs inside a shared product data workspace. Multiple users examine and update the same BOM at the same time, see color coded findings against actual rows, discuss those findings against specific product data, assign tasks, and verify corrections, without exporting the review into separate spreadsheets or reports.

Can several check cards review the same BOM? 

Yes. Each check card handles a focused validation area such as part number identity, required properties, quantities against reference designators, or product structure including circular references. Multiple cards analyze different dimensions of the same connected BOM context.

Do software agents replace human reviewers? 

No. Check cards identify conditions and surface findings. People determine importance, request more information, accept justified exceptions, assign corrective work, and decide whether the BOM is ready for its next handoff.

Why does structured product context matter for AI? 

A structured BOM explicitly represents items, assemblies, quantities, properties, files, revisions, and relationships. A general purpose AI tool receiving disconnected documents has to infer those relationships, and inference failures are hard to detect from the output.

What is context collapse in BOM review? 

Context collapse is the loss of reasoning behind product decisions. The changed data survives in the BOM while the finding, the discussion, the owner, and the accepted exception end up scattered across email, spreadsheets, and task trackers, so months later the team can see what was decided but not why.

How does collaborative BOM Review preserve company knowledge?

 Findings, discussions, decisions, owners, accepted exceptions, and subsequent corrections stay attached to the BOM. Company specific practices can also be encoded as custom check cards so organizational knowledge is applied repeatedly instead of depending on who is in the room.