Why The Most Valuable Output Of A BOM Review Is Not The Corrected BOM

Every company that validates a bill of materials produces two things.

The first is the corrected BOM. Missing quantities filled in, part numbers fixed, structure repaired, missed vendors and description, cost, and other properties filled in. That is what everyone is trying to get, and it is what every process is designed to deliver.

The second is a body of knowledge about what was wrong, who found it, what was discussed, and what was done about it. That one is more valuable, and almost every company throws it away.

I have been describing this second output as one of the examples of building Product Memory for the last year, usually in the context of Bill of Materials, procurement, supply chain, maintenance. Why this material was chosen, why this tolerance, why this tradeoff. What I have come to understand more recently is that the bill of materials produces its own memory, continuously, and that nobody is collecting it. That realization is what shaped how we built BOM Review, and it is the thread running through this article.

The Corrected Value Remains And The Reasoning Does Not

Look at how BOM validation actually happens in most companies.

Someone exports the BOM to Excel. The file goes to five people by email. Comments come back in five different files with five different conventions, and someone merges them by hand. Half the follow up happens in chat. A decision gets made on a call that nobody minutes. The corrected values are typed back into the system of record.

Now ask what remains a month later. The corrected values remain. Everything else is gone. There is no record that the value was ever wrong, no record of who caught it, no record of why it was wrong, no record of the disagreement about how to fix it, and no record of how long it took.

This is not a problem with your discipline. The problem is structural. The review happened outside the data, on a copy, in tools that were never designed to retain anything. The spreadsheet was deleted, the email thread scrolled away, the chat channel archived. The system of record faithfully stored the outcome and had no specific place to put the reasoning and to store alternative decisions that were deferred or rejected.

The practical consequence is that the same class of error appears in another BOM six months later and the organization starts from zero, with none of the context it paid to generate the first time.

Product Memory Is The Layer That Keeps The Reasoning

Product Memory is the layer that retains why the record is what it is, not only what it currently says.

PLM, PDM and ERP are good at the current state of a part. They are weak at everything that produced that state. The decisions, the corrections, the arguments, the things that were wrong before and are not wrong now. That knowledge exists in every organization, and it lives in people rather than systems, which means it leaves when they do.

The question I care about is where that memory would actually come from. It cannot come from asking people to document their reasoning, because they will not, and they should not have to. Remember the old “knowledge management” discipline where engineers and other users requested to “document” their knowledge? It didn’t work. It has to be a byproduct of work they are already doing. 

BOM validation turns out to be an unusually good source, because it is a moment where someone examines data, finds something wrong, involves other people, and resolves it. That entire sequence is reasoning, generated naturally, and today it evaporates.

So the design goal for BOM Review was not only to find errors. It was to make the finding, the conversation and the resolution into durable objects attached to the part itself. The rest of this article is how that works.

Validation Requires A Complete Bill Of Materials Before It Requires A Correct One

Nothing useful can be validated until the data is assembled in one place.

This is the capture step. Mechanical design data comes from CAD. Electronic data comes from its own tools with its own conventions. Supplier and cost information arrives in spreadsheets. Production data lives somewhere else again. Validation against a partial BOM produces findings that are wrong as often as they are right, and a tool that cries wolf gets switched off.

Capture brings those sources into a single structure that includes parts, properties, relationships, attached files, links out to suppliers, and more. A digital bill of materials in OpenBOM is not only a list of parts. It is the assembled representation of a product data, and it gives every subsequent check the context of the whole rather than a fragment.

Review Runs Inside The Collaborative Workspace, Not On An Exported Copy

The second structural decision is that review happens where the team already works.

OpenBOM is collaborative in the way people expect from a shared spreadsheet. Multiple people open the same BOM at once and can simultaneously edit it. Sharing can be automatic within a team or granted specifically to an individual, a supplier or a contractor. Changes are visible to everyone as they happen.

Review is a panel inside that environment. You open a BOM, run the review, and results appear against the live data everyone else is looking at. No export, no round trip, no merge.

This is the decision that makes memory possible at all. A finding can only persist if it points at something that persists. A comment on row 412 of a spreadsheet that no longer exists is not a record of anything.

Check Cards Turn A Wall Of Errors Into Categories You Can Reason About

Results are organized into check cards, each dedicated to one category of validation. Four run today, and all four are deterministic. They apply defined rules and either find a violation or do not.

Part number and identity checks that parts are identified correctly and consistently. If identity is wrong, every downstream check inherits the error.

Property checks the values in the fields. Missing values where a value is required, values outside expected form, values that contradict the rules for that property.

Quantity checks quantities and what must agree with them. The example I use in demonstrations is a reference designator list that does not match the stated quantity. The BOM says quantity two and lists one designator. On a short BOM you might catch that by reading. On three thousand lines nobody does, and it surfaces later as a shortage on the line.

Structure checks the shape of the BOM itself, the relationships between assemblies and components, and whether the hierarchy holds together.

AI BOM Health looks for potential problems in this BOM analyzing it using LLM (the option to plug-in different LLMs is coming) 

Categories matter for the memory question too. A record that says something was wrong is weak. A record that says an identity rule was violated on this part, at this moment, is something you can count and compare across programs.

A Finding That Cannot Take You To The Problem Is Only Half Useful

Every finding is bound to a specific cell in a specific bill of materials. Click it and you land there, highlighted, in context.

This sounds minor and is not. Most validation tools tell you if an error exists, describe what you ought to do, and leave you to find the place where you can do it. On fifty lines that is a nuisance. On several thousand it is why the report sits unopened.

When I started writing software, you submitted a program, waited, and got back a list of mistakes you then hunted through the source to locate. Interactive environments ended that, and the relief was enormous. A validation report you have to hunt through is the same experience reinvented, and it deserves the same fate.

The binding also does quiet work for memory. Because the finding lives at a cell rather than in a report, the history attaches to the part, and it is still there the next time anyone opens that BOM.

Most Findings Are Not Yours To Fix, So Every Finding Can Become A Task

Navigation solves the problem for one person working alone. Real BOM validation is not that.

The person running a review rarely owns all the data in it. They can see a vendor field is empty, but the answer belongs to procurement. They can see a quantity looks wrong, but confirming it belongs to the engineer who owns that subassembly. A review that only supports individual correction stops at the boundary of what one person knows.

So finding a problem becomes a task. From the finding itself, you create a task carrying the context with it, quantity is empty on this part in this BOM, assign it to a person, and set a deadline. The assignee sees it in their own view, clicks, and lands directly on the cell. No spreadsheet, no hunting for the row, no reconstructing what was being asked.

This is the step where a technical finding becomes an organizational fact. Somebody was asked. There is now a named person, a scope, a deadline and a place for the conversation, and all of it is attached to the part rather than to an inbox.

Tasks Also Protect People From The Alert Stream

Every validation system has the same failure mode, which is becoming a firehose. Another field is wrong. Another field is wrong. Engineers learn to ignore it, and the tool becomes noise.

Tasks are the answer. The system holds all findings. People are exposed only to what someone deliberately assigned to them.

This matters because a large share of findings are not errors at a given moment. A field can be legitimately empty because the answer does not exist yet. A vendor can be undefined because sourcing has not happened. A weight can be an estimate awaiting measurement. Those are normal states in development, not defects, and a system that treats them as defects will be turned off.

Human judgment sits between the finding and the assignment, deliberately. It is also worth noting that the judgment itself is informative. The decision that a given finding did not warrant a task is a small piece of knowledge about how this organization works.

Closing A Task Requires Re-Running The Review, Not Asserting A Fix

The loop closes by verification rather than by claim.

Someone enters the missing quantity. The finding does not clear on its own, because the review reflects the state at the time it ran. You run the review again. The check re-evaluates against current data, the finding clears, and only then is the task marked complete.

In a document based process, a task closes because someone says they fixed it. Here it closes because the same rule that caught the problem no longer catches it. The evidence and the assertion are the same object, which is what makes the resulting record worth trusting later.

Follow The Loop Once And Look At What It Left Behind

Now trace the whole sequence and notice what has accumulated by the end.

A review ran against a specific bill of materials at a specific time. A named rule caught a specific problem in a specific cell. A person was asked to resolve it, with a scope and a deadline. A conversation happened in place. A correction was made. The review ran again and confirmed it. The task closed against evidence.

Nobody wrote documentation. Nobody was asked to capture a lesson learned. Every piece of that record was produced because somebody did the work, and all of it is attached to the part rather than to a thread in someone’s mail client.

That is what I mean when I say BOM Review produces Product Memory. Not as a separate feature, and not as a repository somebody has to maintain, but as the residue of validation done in the right place.

Repetition Is What Turns Records Into Memory

One review produces records. A process that repeats produces memory.

This is why we describe the platform as a flywheel. Capture assembles data from where it actually lives. Review reasons across it to find what is wrong. Flow distributes the improved data back out to ERP, PLM, CAD or wherever the organization needs it, because we are not trying to be the authoritative source for everything. Then it turns again.

Quality was never a state you arrive at. In my engineering days I used to say that anything you stop measuring will drift, because that is simply the tendency. Bills of materials behave exactly that way, which is why review has to be continuous rather than ceremonial.

Each turn deposits another layer. After enough turns, questions become answerable that no system can answer today. Which classes of error recur in our bills of materials. At which stage they appear. Which parts, teams or suppliers generate which problems. How long each class takes to resolve. Whether the thing that cost us a schedule slip last year is present again right now.

Those are not hard questions. They are unanswerable only because the raw material was discarded every single time. Once it is retained, the value is no longer that you found an error. It is that your organization stops paying full price to learn the same thing twice.

Video Interview with Rob Ferrone 

Heads up – tomorrow I am publishing my conversation with Rob Ferrone about his experience of working with Bill of Materials. Rob Ferrone has spent 25+ years helping the world’s manufacturers solve complex product data challenges. He heard this argument and immediately extended it further than I had. That conversation is the next piece in this series.

After founding, scaling and selling a leading product data consultancy, Rob is now tackling the biggest cause of transformation failure: the human side. His new venture is ReachR. ReachR uses AI to understand every individual at scale, connecting strategy with the people who must deliver it, leading to better solution design, faster adoption and more successful transformations.

We Are Looking For Design Partners

I want to be exact about the state of the product. The out of the box check cards are live if you can test them right now together with review, task and collaboration mechanism. Register for free and try OpenBOM for 14 days.

The full sequence described here, running a review, navigating to findings, creating and assigning tasks, re-running, and closing against verification, works today.

AI driven BOM health check cards are coming at the end of this week. The intent is to reason across full product context and surface problems no fixed rule anticipates. In an early run against a test BOM it told me the bicycle appeared too heavy for a normal bicycle, which is a genuinely useful class of finding. It is also probabilistic output, which means it proposes and a person decides. It is not a rule and should not be treated as one.

Configurable custom check cards, where a company encodes its own validation rules, are in development. Every company checks something specific in a way that cannot be captured generically, and we do not yet have a way for them to express it. It is not available. BOM Review is early, and its direction should be set by organizations that live with this problem rather than by us alone.

We are looking for a small number of design partners to work with continuously. In practice that means helping you capture and organize your bills of materials, working through what validation actually needs to catch in your environment, and learning together what your custom rules would have to express.

Companies keep asking me how to bring AI into product development. The answer I keep arriving at is that AI without context produces nothing useful, and that a captured, structured, validated bill of materials is that context. The accumulated review history is a second layer of it, and it is the layer nobody else can supply, because it is specific to how your company actually works.

Contact us to become a design partner and to work together on BOM Review. 

Best, Oleg