Your BOM Is an Ontology. Why Graph-Native Architecture Matters.

Every few weeks I review the onboarding calls where the same thing happens. A team brings in their Bill of Materials, data, spreadsheets and discuss how to improve the way they organize them. We start tracing relationships, this part into that assembly, this assembly into a larger structure, this revision back to the change that drove it, and somewhere in the trace a gap opens up. A component that was replaced months ago is still listed. A revision lives in someone’s email but never made it into the BOM. The document and the product have quietly drifted apart, and nobody noticed until we looked at it together.

That gap has a name the data world has been arguing about all year. They call it ontology decay. Engineers just call it a BOM that’s out of date or not in sync with other siloes of information.

The enterprise data world has spent 2026 rediscovering ontologies. Knowledge graphs, semantic layers, the whole vocabulary that used to empty a room is suddenly at the center of the AI-readiness conversation. Gartner now treats semantic structure as a precondition for trustworthy AI rather than a nice-to-have. And the timing isn’t accidental. MIT’s NANDA research found that 95% of enterprise GenAI pilots deliver no measurable bottom-line impact, and one of the most cited causes is that the AI has nothing solid to reason against, no structured, contextual model of the business underneath it.

Manufacturing engineers have been maintaining exactly that kind of model for decades. We just call it a BOM. And like every other ontology, most of them are decaying, quietly, while everyone assumes they’re current.

A BOM Is Not a List

Start with what an ontology actually is. Strip away the jargon and it’s a structured model of entities and the relationships between them. Not a catalog of things. A map of how those things connect, depend on each other, and propagate change.

By that definition, a Bill of Materials is an ontology, and a rich one. A digital BOM is not a flat list of parts. It’s a network: Parts inside Assemblies, Assemblies nested into larger structures, CAD files bound to geometry, specifications governing tolerances, suppliers tied to sourcing, change requests rewriting revisions, revisions carrying their own approval history.

The relationships are the data. The moment you flatten a BOM into a spreadsheet, you keep the names and numbers and throw away the part that carried the meaning. What’s left looks like information and behaves like a list.

So if your BOM is an ontology, the real question isn’t whether you have one. You do. The question is whether it’s a healthy one, and whether the architecture underneath it was built to keep it that way.

Four Ways Product Ontologies Decay

In a recent piece on Modern Data 101, Soumadip De lays out six ways enterprise ontologies fail. His core observation is the one worth sitting with: an ontology is most accurate the day it ships, and it decays every day after that unless someone deliberately maintains it. Four of his six failure modes map almost uncomfortably onto how engineering teams manage product data.

The product moves and the BOM stands still. Products change constantly through engineering iterations, supplier swaps, and late design revisions. A BOM that captured the product accurately at program kickoff slowly becomes a map of a product that no longer exists. The drift stays invisible right up until the moment it costs you something.

Cross-domain fragmentation hides the full product. De notes that most enterprise ontologies are built one domain at a time, and the seams show the moment you try to reconcile them. In our world that’s the EBOM, MBOM, and SBOM problem. Each is built by a different team, in a different tool, under different conventions, and nobody owns the reconciliation. What you get is an internal Tower of Babel that no reviewer, human or AI, can navigate with confidence.

Table-based design throws away the knowledge layer. Rows and columns can hold attributes. They cannot natively hold relationships. A part in a spreadsheet knows its own properties but not what it connects to, what depends on it, or what breaks downstream if it changes. De calls this data-centric design, optimized for storage rather than reasoning, and he’s blunt about the cost: you pay later to reconstruct the relationships you should have stored in the first place.

No owner means no maintenance. The quietest form of decay is the absence of accountability. Change requests that never close. Specifications that drift from the shipping product. Approval history that lives in email instead of the data model. When nobody owns a domain of the ontology, it stops being maintained, and an unmaintained ontology stops being trustworthy.

Why Graph-Native Architecture Changes the Equation

Tables store data. Graphs store knowledge. That’s not a tagline. It’s an architectural decision with consequences for what you, and any AI agent working on your behalf, can actually do with your product data.

In a graph-native model, relationships are first-class. A part doesn’t just carry attributes. It holds typed, traversable connections to the assemblies it belongs to, the geometry that defines it, the supplier that sources it, the revisions that changed it, and the specifications it has to satisfy. Those connections aren’t foreign keys buried in a lookup table. They’re the structure itself.

That buys you two things.

First, accuracy. A graph can represent the real shape of a product, its hierarchy, its dependencies, the connective tissue between EBOM and MBOM, without flattening any of it to fit a grid. The ontology stays intact instead of being approximated.

Second, and this is where the OpenBOM graph foundation earns its keep, it lets you compute on relationships rather than just store them. This is Graph Data Science applied to product data. Ask which assemblies a proposed change touches and how far the ripple travels. Ask which parts across your portfolio are functionally equivalent and ready for consolidation. Ask which supplier relationships concentrate risk across multiple product lines. Ask for the smallest set of edits that resolves an inconsistency. A table answers these with expensive, brittle joins, if it answers them at all. A graph answers them as a matter of course.

The difference between a BOM that decays and one you can actually reason against comes down to a single decision made long before the first part number is issued: graph foundation, or table foundation.

Product Memory Is Ontology Operations

Soumadip De makes one more point that lands hard for anyone running product data. Organizations pour resources into ontology creation and almost nothing into ontology operations, the ongoing work of keeping the semantic layer synchronized with reality. He even lists what depends on that quality, and the last item on his list is long and short-term memory management for agentic workflows. Read that again with an engineering hat on. He’s describing Product Memory.

This is the gap Product Memory fills. PLM remembers what was approved. Product Memory remembers how the product got there: the decisions, the trade-offs, the context behind each revision, the reasoning the approval record alone never captures. That “how” is the operational layer. It’s what keeps the product ontology current instead of letting it harden into a historical artifact.

It’s also where OpenBOM’s agents fit, and it’s worth being precise about what’s live and what’s coming. The CAD File Agent, available today in early access, reads design files as they enter the system and keeps the graph connected to the geometry it represents. The BOM Review Agent, on our roadmap, is designed to surface inconsistencies in the product graph, missing relationships, unresolved changes, metadata gaps, and feed those signals back into the knowledge layer. Together they do what De prescribes for enterprise ontologies generally: instrument the system to catch semantic drift before it compounds into a confident, expensive mistake.

The result is an ontology that doesn’t just sit there. It operates. It moves with the product, stays honest about engineering reality, and holds up as the foundation for the AI-assisted work everyone is racing to deploy.

What This Means for Engineering Teams

Most teams treat the BOM as a deliverable: produced, approved, filed. The shift worth making is to treat it as infrastructure, something maintained and governed and kept in step with a product that never stops moving. That shift has practical edges.

Ownership has to be real. Every domain of the product ontology, mechanical structure, electrical, software configuration, supplier relationships, needs a named steward. Not a committee. A person.

Feedback has to flow. When an agent returns a wrong answer, or a review flags an inconsistency, that isn’t noise to dismiss. It’s a signal pointing at exactly where the ontology has drifted, and it belongs back in the maintenance loop.

Reconciliation has to be continuous. The EBOM and MBOM can’t be separate documents that teams hand-reconcile once a quarter. They need to be connected views of one underlying graph, kept in sync as a property of the system rather than as a periodic project.

How OpenBOM implements each of these, across the workspace model, the agent layer, and the graph foundation, is a longer conversation and a better one to have live. The principle is what matters here: a graph-native platform isn’t a nicer way to store BOM data. It’s the only architecture that can carry a product ontology that doesn’t decay.

Conclusion: How to reason against a connected BOM? 

Every agent you deploy reasons against your product data. Point it at a flat, fragmented, ungoverned BOM and it will hand you answers that are wrong with total confidence, the kind of wrong that’s hard to catch and costly to unwind. Point it at a living product graph and it finally has something solid to stand on.

Graph-native architecture isn’t an upgrade from a spreadsheet or a tidier PDM. It’s a different category of infrastructure: built to hold knowledge rather than store rows, to keep relationships rather than approximate them, and to support the continuous ontology operations that serious AI actually requires.

Your product ontology is almost certainly decaying right now. The only real question is whether the platform underneath it was built to notice, and to stop it.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg 

Frequently Asked Questions

What is a product ontology? A product ontology is a structured model of the entities that define a product, parts, assemblies, specifications, suppliers, CAD files, and revisions, together with the relationships between them. A BOM is a product ontology. How well that ontology reflects engineering reality determines how trustworthy your product data is and how reliably an AI agent can reason against it.

Why does graph-native architecture matter for BOM management? Graph-native architecture stores relationships as first-class data instead of as lookup tables or foreign keys, so the full shape of a product, its hierarchy, dependencies, and cross-domain links, survives in the data model rather than being flattened away. It also enables Graph Data Science: computing on relationships for impact analysis, part similarity, risk propagation, and change dependency mapping.

What is Product Memory in the context of engineering data? Product Memory is the operational layer that keeps a product ontology synchronized with engineering reality over time. It captures not only what was approved but how the product became what it is, the decisions, changes, and context behind each revision. In OpenBOM, this is reinforced by agents that connect design files to the product graph and, on the roadmap, surface inconsistencies back into it.

How does product ontology decay happen in manufacturing organizations? It happens four main ways: the product evolves faster than the documentation; engineering domains such as mechanical, electrical, software, and procurement maintain separate disconnected models; table-based tools strip out the relationship layer; and governance gaps leave domains without a clear owner or maintenance discipline.