The Anatomy of a BOM Review Agent

A few months ago I spent time experimenting with an open source agent environment OpenClaw – a free and open-source autonomous artificial intelligence agent that can execute tasks via large language models (LLMs), using messaging platforms as its main user interface? That had no intelligence in it whatsoever. No model, no reasoning, no built-in cleverness. What it had was a workspace, a set of tools, access to data, and a socket where you could plug in a large language model of your choice. The interesting part was not the model. The interesting part was everything around it. I wrote about it in several blogs on Beyond PLM about PLM Harness – AI Harness for PLM and Manufacturing: Files, Workflows, or Product Memory? and What is Product Memory?  That experience helped me to think about what we are building in OpenBOM and our Product Memory Vision. 

When people hear “BOM Review Agent,” they usually imagine a chatbot that reads a spreadsheet and tells you what is wrong with it. That is not what we built. What we built is closer to the environment I just described: a harness where product data lives in a structured form, where a set of tools can be run against that data, where the results stay connected to the place they came from, and where a large language model is one tool among several rather than the whole system.

This distinction matters more than it sounds. It determines what the system can validate, what it can explain, what it can prove, and what happens when the model changes.

So let me take BOM Review apart and show you the pieces.

Better Reasoning Begins With Better Context, Not With a Better Model

Every conversation about AI in engineering eventually arrives at the same question: which model are you using? It is the wrong first question. The first question is what the model is looking at.

Drop five spreadsheets, a CAD export, and a supplier PDF into any frontier model and you will get an answer. You will not get a reliable one. The model has to infer which row represents which component, which quantity applies at which level, whether two differently spelled descriptions are the same part, and how any of it connects. It is reconstructing a product structure from fragments, and it is guessing.

OpenBOM does not ask it to guess.

The BOM Review Agent runs on top of the OpenBOM collaborative workspace and its flexible graph based semantic data model. Parts, assemblies, properties, quantities, reference designators, files, suppliers, inventory records, and the relationships between all of them are represented explicitly. A multi level structure is a graph, not a flattened export. A part number is an identity, not a string in a cell. Data arriving from SOLIDWORKS, from Excel imports, and from an ERP system lands in the same model rather than in three disconnected piles.

This is the substrate the harness is built on. Documents give a model text. A semantic product model gives it entities, hierarchy, identity, and traceability. Everything else in this article depends on that difference.

Review Is a Team Sport, So the Workspace Comes Before the Checks

A BOM review is rarely one person’s job. Engineering owns the structure. Procurement owns supplier data and availability. Manufacturing owns producibility. Quality owns compliance. In most companies this review happens across email threads, screenshots, and a spreadsheet that someone renamed with their initials.

OpenBOM is a collaborative environment first. Multiple people work in the same BOM at the same time, make changes, attach comments to specific cells, and see each other’s work in real time. BOM Review runs inside that environment rather than beside it, which is what makes the next part possible.

Here is the question I get asked most often about automated validation, and it is a fair one. If a BOM has three hundred incomplete rows because it is still early in design, does the system generate three hundred tasks?

No, because an alert is not a task.

The review surfaces findings. A person looks at them, and decides which ones deserve a comment, which ones deserve a question, which ones deserve an assigned task with an owner, and which ones are simply expected at this stage of the work. Nothing is promoted to a task without a human doing the promoting. And when the underlying data is corrected and the check is run again, the finding is gone. It does not need to be closed, dismissed, or administratively cleaned up. It disappears because the condition that produced it no longer exists.

That is the shipped answer to the overload problem. The human stays in the loop by default, and re-running is cheap.

Check Cards Turn Company Knowledge Into Something You Can Run

The tools in the harness are check cards.

A check card performs one specific analysis against the BOM and reports what it finds. This is a deliberate architectural choice. We could have built one large validation engine with a configuration screen. Instead we built a socket, so that checks can be added, replaced, configured, and eventually written by customers without touching the rest of the system.

Check cards fall into three levels.

Predefined cards handle problems that look the same in almost every company. Missing values, malformed part numbers, broken structures, quantity mismatches.

Configurable cards use your settings. Part number rules come from your part number configuration in OpenBOM. Required properties come from your definition of what matters, which means an empty note field does not generate an alert while an empty material field does.

Custom company cards are where this gets interesting, and I will come back to them at the end.

Four Card Types and They Are Deliberately Unglamorous

The first release (available for everyone now in July 2026 release) includes four deterministic check cards. None of them use AI. All of them are available to every OpenBOM user including trials, and they will stay that way.

Property validation checks whether the properties you have defined as required actually have values, and whether those values fall inside the allowed set. Missing descriptions, empty materials, absent suppliers, invalid units, classifications outside the approved list.

Part number validation checks every part number in the BOM against the numbering rules configured in your system. This catches malformed numbers, wrong prefixes, missing numbers, and the temporary placeholder that someone typed in three weeks ago and never came back to replace.

Structure validation detects circular references, where an assembly directly or indirectly contains itself. These break flattening, quantity rollups, and exports. They are rare, they are almost always accidental, and they are miserable to find by hand.

Quantity and reference designator validation compares the component quantity against the reference designator list. A part with designators R1, R2, R3 and a quantity of one is a mismatch. On a five line BOM you would spot it. On an electronics BOM with several hundred lines you would not, and neither would the person reviewing it after you.

I want to be clear about why these four are boring on purpose. They are deterministic. A part number either conforms to the rule or it does not. A loop either exists or it does not. The answer is the same every time you run it, and the system can tell you exactly why. That reliability is the foundation everything probabilistic gets to stand on.

One of our customers, Vartech, put a number on what this kind of catch is worth. They found a thousand dollar mistake in their first month using OpenBOM, and their assessment was that the product paid for itself that month on that one error alone. That was before any of this existed.

The AI Card Is a Different Kind of Tool

The next card type, we are shipping next week, is AI BOM Health.

It works differently. It takes the full hierarchical BOM from the assembly you are reviewing, serializes it into a structured context, and sends it to a frontier model. Remember the OpenClaw story? It can be a model of your choice. The model then analyzes the structure and reports what looks wrong.

The value here is that frontier models can perform validations nobody programmed. In testing, the card identified that quantity on hand was insufficient for a planned build. Four required, two available. Nobody wrote a rule for that. The model read the structure, read the inventory data, and connected them.

Other things in this category: a purchased component with no supplier information, similar components described inconsistently across the structure, a classification that contradicts its own properties, a subassembly that looks incomplete for its stated purpose, ordered parts that do not cover the prototype build.

There is also a loop worth naming. When the AI card repeatedly surfaces the same meaningful issue, that issue is a candidate to become a deterministic rule. The model discovers the pattern, your team confirms it matters, and it becomes a check card that runs the same way every time. Probabilistic discovery feeding deterministic enforcement.

Because AI BOM Health carries real model cost, it will require a subscription. The four deterministic cards remain available to everyone.

Custom Check Cards Are How a Company Writes Down What It Knows

Here is what I think the long term value of this architecture actually is.

Every experienced product data professional carries rules in their head. Approved materials for a given application. Which properties must be populated before a part can be sourced. How make versus buy classification interacts with supplier requirements. What a prototype BOM needs that a production BOM does not. Some of this is written in a standards document nobody reads. Most of it is not written anywhere.

I have watched people train new hires by walking them through a customer question and asking what the question is really trying to find out, how you would deconstruct it, and what you would check before answering. That deconstruction is expertise. It exists in a senior person’s head and it walks out the door when they leave.

A custom check card is that deconstruction, written down once and run forever.

This is why the card architecture is a socket rather than a fixed list. The goal is that companies define their own cards, and beyond that, that a company’s existing BOM specification document can be imported and turned into runnable checks rather than remaining a PDF on a shared drive.

Every card a company writes converts an unwritten practice into a repeatable mechanism. Every review that runs records what was found, what was decided, who decided it, and why. That is not error checking. That is Product Memory, accumulating in the place where the work actually happens.

An Alert Is Only Useful If It Takes You to the Cell

This is the part I care about most, and it comes from a mistake we made.

For years OpenBOM would tell users that their BOM contained a circular reference. Users would file support tickets saying OpenBOM had broken their data. It had not. They had combined several bills of materials across multiple levels and produced a loop, which is an easy thing to do accidentally. We would reply with the part number where the loop occurred, and they would come back and ask where.

They did not want to be told the part number. They wanted to be walked to it.

That is the design principle running through BOM Review. Every finding carries its context: severity, explanation, part number, parent assembly, BOM level, the specific property or cell, and which card produced it. Click the finding and OpenBOM navigates you to that location in the structure.

The system does not say the quantity is empty. It opens the quantity cell. It does not say a circular reference exists. It points at the relationship that closed the loop. It does not say the reference designators do not match. It opens the component where you can compare them.

The distance between finding a problem and being able to fix it is the whole game. Most validation tools produce a report and leave you to do the hunting, which on a thousand line BOM can take longer than the fix.

Findings Become Comments, Comments Become Tasks, and Re-Running Closes the Loop

A finding starts as an observation. From there it can go several ways.

You open it, land on the data, and see immediately that it is fine for where the design currently is. Nothing happens.

Or you open it and you are not sure. You leave a comment on the cell asking why the value is empty, and your colleague answers in the same place, against the same data, with no screenshot and no email.

Or you open it and it clearly needs work by someone specific. You convert it to a task, assign an owner, and it enters the normal OpenBOM task flow.

Then the data gets corrected and the card gets re-run. If the problem is resolved, it is no longer in the results.

That sequence is what separates a review process from an audit report. An audit report is a photograph of a moment. A review process is something you run again.

Governance Is the Next Layer, and It Is Work-in-Progress

Everything above is shipped or in active development. What follows is where this goes, and I want the line between the two to be visible.

The natural next step is that some findings stop being advisory. The model I have in mind is a compiler. A compiler emits warnings that you can read and move past, and errors that stop the build until you deal with them. BOM Review should eventually work the same way: informational findings that require nothing, warnings that require acknowledgement, and critical findings that block a revision or a release until they are resolved.

A production BOM with an unresolved circular reference should not be releasable. A procurement package missing supplier data on purchased items should not be issuable. Which conditions block, and in which context, has to be configurable, because a concept BOM and a manufacturing BOM are not held to the same standard.

That leads to the other piece on the roadmap: review profiles that understand maturity. A missing quantity during conceptual design is not the same event as a missing quantity before a production release. The same check card, run under a different profile, should reach a different conclusion. Concept review, engineering release review, procurement readiness review, manufacturing readiness review, change impact review.

The right question is not whether the BOM is complete. It is whether the BOM is ready for whatever the organization plans to do with it next.

Alongside that: exportable review reports for design reviews, supplier packages, and quality audits, and review history that accumulates across revisions so you can see which issues recur.

What Comes Next

The initial set of check cards and AI BOM Health are available now. We are working on custom check cards and ability to work on custom models and your ability to capture organizational BOM best practices and bring it to BOM Review including governance, review profiles, and reporting are the roadmap.

What I want next is the harder part, and it is not something we can build alone.

We are looking for design partners: companies willing to work with us on custom check cards that encode their own standards. That means larger organizations with proprietary engineering, quality, or supply chain rules they want enforced, and it means service organizations whose expertise is exactly this kind of product data judgment. There is a real business in codifying that expertise, and we would rather build it with the people who have it than guess at it.

If your company has rules that currently live in someone’s head, I would like to talk about turning them into cards.

Contact us and we would be happy to discuss. 

Meantime, REGISTER FOR FREE to check how OpenBOM can help you. 

Best, Oleg 

What is a BOM review agent? A BOM review agent is an environment that runs validation checks against a structured bill of materials, keeps each finding connected to the data that produced it, and lets a team discuss, assign, and resolve issues in place. OpenBOM BOM Review combines deterministic rule based checks with an AI analysis card, running on top of a graph based semantic product data model.

What checks does OpenBOM BOM Review include today? Four deterministic check cards are available: property validation against required properties and allowed values, part number validation against configured numbering rules, structure validation that detects circular references, and quantity validation against reference designator lists. All four are available to every OpenBOM user, including trials.

Is BOM Review free? The four deterministic check cards are free for all OpenBOM users including trial accounts. The AI BOM Health card, currently in development, will require a subscription because of the underlying model cost.

How is the AI BOM Health check different from the other checks? Deterministic checks return the same answer every time and can explain exactly which rule was violated. The AI BOM Health card sends the full hierarchical BOM to a frontier model as structured context and reports what looks wrong, including issues nobody explicitly programmed. Because it is probabilistic, repeated runs can differ. It is designed to analyze and suggest, while deterministic cards verify.

Does BOM Review create a task for every problem it finds? No. Findings are surfaced, not assigned. A person decides which findings become comments, which become tasks with owners, and which need no action. When the underlying data is corrected and the check is re-run, the finding no longer appears.

Can we define our own BOM validation rules? Custom check cards are the direction of the architecture. Configurable cards already use company settings such as part number rules and required property definitions. OpenBOM is recruiting design partners to co-develop custom cards that encode company specific engineering, quality, and supply chain standards.

Why does the data model matter for BOM validation? Uploading documents to a language model gives it text, and it has to infer product structure from fragments. OpenBOM’s graph based semantic model represents parts, assemblies, properties, quantities, relationships, files, and supplier records explicitly, so checks operate on known structure rather than inferred structure.