Bigger AI Context Windows Will Not Fix Your BOM

Everyone Is Asking for the API. Almost Nobody Is Asking the Right Question.

Over the last few months we noticed something in our inbound conversations at OpenBOM. Requests for API access went up. It is different from a typical “integration to ERP” or “export” projects. I’d say a different kind of caller, asking a different kind of question.

So we started asking what they were building. The answer was almost always some version of the same sentence.

“We want to upload our BOM to AI.”

I understand the idea completely. Everyone wants AI magic. Those people are using AI and want their “data” to go to AI too. But it is hard. They have used the AI models, they have seen what happens when a good model gets a good question, and now they want to wire their own product data into it. The API request is the last step in reasoning that already happened somewhere else.

Unfortunately this mental model will not survive contact with a real product.

Start with uploading. What to upload? Excel? CAD files? PDFs? Upload is a one time transfer. It assumes the BOM is a thing you hand over and are done with. Real BOMs change on Tuesday, change again on Thursday, and the version that mattered for the release decision is not the version sitting in the system this morning. Whatever you uploaded last week is now describing a product that no longer exists. How to upload changes? 

Then our BOM, as though there is one. Which one? Mechanical, Electrical? System? The assembly structure coming out of CAD? The released revision with approved vendors? The one procurement is working from, with supplier data and lead times attached? The engineering team asking the question and the manufacturing team receiving the answer are frequently not talking about the same object at all.

And then to AI, which puts the model at the destination. The model is not the destination. The model is the last four seconds of a process that is almost entirely about everything that happens before the question gets asked.

AI BOM Validation Is Not a Search Problem

Watch what people do with AI once they get access to their own data. Within a day or two, almost everyone converges on the same question, phrased a dozen different ways. 

Tell me if what I do is correct? Find mistakes? Can I release it? 

Those are reasonable questions. It is also the hardest question in the building, and it is worth being precise about why. Answering it requires knowing whether every item carries a part number that resolves to a single physical thing. Whether the quantities in the BOM match the instance counts in the assembly. Whether anything changed structurally since the last released revision, and whether those changes were intentional. Whether purchased items have manufacturer part numbers attached, and machined items have material specified. Whether the people who need to sign off have seen the current state rather than a state from three weeks ago.

None of that is a retrieval problem. Every one of those is a computation and reasoning over structure.

This is the part that gets missed when the conversation stays at the level of pointing AI at data. Retrieval finds documents that mention your BOM. It ranks them by similarity to your question. It hands the model a pile of passages that are topically related to what you asked. That works beautifully when the answer exists as a statement somewhere in a document and the job is to locate it.

Release readiness is not written down anywhere. It has to be derived, from structured data, across sources, against rules. There is no passage to retrieve.

What AI BOM validation needs instead is engineering context. Engineering context is product data organized around a specific decision: scoped to that decision, resolved so every field carries one value and a traceable source, anchored to a version, structurally intact rather than flattened into text, and reviewable by the people accountable for the outcome. Data is passive and sits in systems. Context is assembled, and assembling it is work that no connector performs on your behalf.

More Data in the Window Is Not More Engineering Context

The obvious objection in 2026 is that this is a solved problem. Context windows are enormous now. Connectors reach into every system. Point the model at the PDM vault and the ERP and the shared drive, and let it figure things out. Almost all PLM vendors enabled “some sort of AI” in their products and most probably MCP support.

I want to take that objection seriously, because it is where most vendors are leading now. It is just wrong in a specific and interesting way.

Context window size is a question of capacity, not resolution. You can paste forty thousand rows into a prompt. What the model receives is forty thousand rows of text. The parent and child relationships that made it an assembly are now implied by indentation. The quantity column is now a number next to another number. The model can read it, and it will often be roughly right, and roughly right is a catastrophic standard for a release decision. Nobody wants to explain to manufacturing that the quantity was probably fine. 

Connectors have the opposite problem. They give you reach without assembly. Now the model can see the CAD metadata and the spreadsheet and the ERP record, which means it can now see three different values for the same attribute with no rule for which one wins. A human engineer resolves this instantly, because they know the ERP is authoritative for cost and the CAD is authoritative for structure and the spreadsheet is what someone kept because the system did not have a field for it. That knowledge is not in any of the three systems. It is the thing that has to be supplied.

There is also a timing problem that gets very little attention. Retrieval is present tense. It fetches what is there now. Engineering questions are almost always comparative across time. What changed since the last release, what did we approve, what did we decide and why. If your context is a snapshot, the entire class of questions engineers care about most is unanswerable in principle.

And then the one that strikes immediately. Even with perfect data in the window, you cannot validate four thousand line items by asking a model to look them over. Not because models are unreliable, but because validation needs to be repeatable and inspectable. When a check fails, someone has to see which rule failed, on which item, against which source, and be able to run it again after the fix. That is a computation with an audit trail, not a judgment call rendered in prose.

The difference comes down to four properties, and retrieval loses on all of them.

Engineering Context Is Data Organized Around a Decision

I defined engineering context briefly above. It is worth unpacking the five properties, because each one names a specific piece of work that somebody has to do.

Scoping, first. A decision defines its own boundary. Releasing a subassembly pulls in a specific set of items, their drawings, their suppliers, and the previous released revision. It does not need the rest of the product line, and including the rest actively degrades the answer.

Resolution, second. Where sources disagree, context carries one value and a record of where it came from. Provenance is not decoration. When a downstream reviewer questions a number, the answer has to be traceable to a source, not to a model’s summary of several sources.

Versioning, third. Context is anchored to a moment and comparable to other moments. This is what makes change questions answerable at all.

Structure, fourth. Assemblies stay assemblies. Quantities stay computable. Identity stays resolvable across sources. Flattening structure into text throws away exactly the properties that made the question answerable.

And reviewable, last. Humans have to be able to look at the assembled context, correct it, and record decisions against it. Otherwise you have automated the retrieval of an unverified pile.

Above that, there are many specific characteristics of products that are presented in the BOM structure that can indicate a problem – unit of measures, weight, country of origin, regulation, component supply, etc. etc. 

And finally, what if two engineers and procurement managers have different opinions about specific data sets? How can they resolve the problem? 

What AI BOM Validation Looks Like When You Build It

Abstractions are cheap, so let me show you what this turned into when we built it.

The OpenBOM BOM Review Agent runs check cards. Each one is a computation over assembled context. Three ships today, covering part number and identity, property completeness, quantity, and structure.

Take the quantity check, because it is the most instructive. On the surface it is trivial. Compare the quantity in the BOM to the quantity in the assembly. In practice, the instance count in a CAD assembly is not a field anyone wrote down. It has to be computed by walking the structure and counting occurrences, respecting patterns and suppressed components. Then take an example of reference designators and quantities. What if the number doesn’t match the RefDes? 

Then look at what the structure check requires. Comparing an assembly against the last released revision means aligning two structures by identity. If the same part number appears under two different numbers from two different sources, every structural difference downstream of it is collapsing – circular reference is introduced. The structure question is not answerable until the identity and circular check is done. 

That dependency is a property of the problem, not of any particular implementation, and it is the thing you cannot hand to a prompt. Empty properties lead to incomplete data and it presents lack of validation. Some of them are ok (eg. note), but some of them are not (eg. vendor) 

The Property check is the least glamorous and the one that catches the most real problems. Completeness is defined by whoever consumes the data downstream. Purchased items need manufacturer part numbers or procurement stalls. Machined items need material or the shop calls you. Nothing about that is universal, which is why the interesting version of this is configurable per company rather than shipped as a fixed rule set.

Every card returns the same three things: what failed, on which item, and against which source. An engineer can act on that. It survives being forwarded to someone who was not in the conversation.

BOM Review Is Where Engineering Context Gets Assembled

I have described the OpenBOM platform for a while now as a flywheel: Capture, Review, Flow. Capture brings product data in from CAD, from Excel, from wherever it currently lives. Flow moves validated information downstream to procurement, manufacturing, and suppliers.

Review is the stage in the middle, and until recently I described it mostly as a collaboration step. Working through the AI question has changed how I think about it. Review is where scattered product data becomes engineering context. It is the moment where sources get reconciled, structure gets validated, gaps get found, and decisions get recorded against a specific version of a specific product.

Which means the review is not overhead standing between engineering and release. It is the operation that produces the only asset AI can actually use.

This is also where Product Memory accumulates, and why I keep insisting that Product Memory is different from a digital thread. A thread connects records. Review captures reasoning. When a check fails and an engineer overrides it because that particular deviation was approved for that particular customer, the override and the reason are the memory. Six months later, when someone asks why this item is different, that is the answer. No system of record holds it, because no system of record has a field for why.

Start With the Context, Not the Model

If you are working out where AI fits in your engineering organization, the first question is not which model to use. The models are good. They will keep getting better without any help from you, and betting your architecture on which one wins is a bet you do not need to place.

The question worth asking is what your AI will be looking at when someone asks it something that matters.

The OpenBOM BOM Review Agent is where we put our answer. It assembles product structure, CAD data, drawings, spreadsheets, documents, and engineering discussion into a workspace scoped to a single decision, runs computed checks against it, and records what the team decided and why.

Two things follow from there, and we are building both. BOM Healthcheck extends validation from a review event to a continuous read on the condition of your product data. And custom check cards are becoming skills that customers author themselves, because the checks that matter most to a company are usually the ones nobody else needs.

REGISTER FOR FREE and try a real BOM. Preferably one you are not certain about. That is where you find out what your AI would have been looking at.

Best, Oleg 

Frequently Asked Questions

Can I just upload my BOM to ChatGPT or Claude?

You can, and for exploratory questions it often works. It breaks down for validation. A BOM pasted as text loses the parent and child structure that makes quantities computable, carries no version anchor, and gives the model no rule for which source wins when values disagree. Exploration tolerates approximation. Release decisions do not.

Do larger context windows solve the engineering data problem?

No. Context window size is capacity, not resolution. A model can receive forty thousand rows and still be unable to compare an assembly instance count against a BOM quantity, because the instance count was never a field in the first place. It has to be computed by walking the structure.

What is engineering context?

Engineering context is product data organized around a specific decision. It is scoped to that decision, resolved so each field carries one value and a traceable source, anchored to a version, structurally intact, and reviewable by the people accountable for the outcome.

How is this different from connecting AI to PLM or PDM with MCP?

Connectors give reach. They do not perform assembly. Once a model can see CAD metadata, a spreadsheet, and an ERP record simultaneously, it can see three values for the same field with no rule for which is authoritative. That rule lives in the heads of the engineering team and has to be supplied deliberately.

What are check cards in the OpenBOM BOM Review Agent?

Check cards are computed validations that run against assembled context. Three ship today, covering part number and identity, property completeness, quantity, and structure. Each returns what failed, on which item, and against which source, so results are actionable and auditable rather than a prose summary. OpenBOM is also building BOM Healthcheck, and moving custom check cards toward skills that customers author themselves.

Why does BOM review matter for AI readiness?

Review is where scattered product data becomes trustworthy context. Sources get reconciled, structure gets validated, and decisions get recorded against a specific version. That output is the asset AI can use. Without it, AI is reading fragments.