Reference–Instance Product Structure and xBOM: A Modern Data Architecture for Product Models

This article is the next chapter in my ongoing blog series about OpenBOM Data Management. In the first chapters, I introduced the basics of the OpenBOM core data model—how everything is represented as objects with properties, and how views give us different ways to navigate this information. Those fundamentals are essential, but they are just the starting point.

Today, we take the next step and explore how OpenBOM models product structures. We’ll look at the reference–instance principle, understand the building blocks of items and BOMs, and see how this expands into the powerful xBOM architecture. Along the way, we’ll balance a user perspective with a deeper technical dive into why OpenBOM’s graph-based data architecture is unique.

Connecting to the Basics of the OpenBOM Data Model

If you’ve been following the series, you’ll recall that OpenBOM’s foundation comes down to three elements: objects, properties, and views.

• Objects represent the things we manage: items, catalogs, BOMs, requirements, or files.
• Properties capture data about those objects—either system-defined (part number, revision, description) or custom-defined by you.
• Views are simply different ways of seeing the data—single-level BOMs, multi-level structures, or flattened lists.

In the last article, I emphasized how this foundation gives you flexibility compared to old PLM/PDM tools, where schemas are rigid and difficult to adapt. But the next logical question is: how do we represent the difference between what a part is and how it is used? That’s where the reference–instance model comes in, and it’s a cornerstone of OpenBOM.

If you missed my previous article, check it here – OpenBOM core data mode

Principles of the Reference–Instance Model

The principle is simple but powerful: separate the definition of an item (reference) from its usage in a BOM (instance).

• A reference is an item defined once in a catalog. It has properties that remain consistent across all uses—part number, description, cost, weight, and material.
• An instance is how that item is used in a particular product structure. Instances carry contextual information—quantity, position, configuration, or even flags (like “this is a spare”).

If you’ve ever wrestled with BOMs in Excel, you know what happens when this separation isn’t enforced: properties get duplicated across rows and spreadsheets, leading to errors, inconsistency, and wasted time. OpenBOM’s approach eliminates duplication and ensures semantic clarity.

Think about a screw. Its material and weight never change—that’s reference data. But the torque applied, the finish used in one assembly, or the “spare” status in a service BOM—all of those belong at the instance level.

This is the principle that makes OpenBOM flexible and scalable while maintaining data integrity.

Core Building Blocks of Product Structure in OpenBOM

Once you grasp the principle, the core building blocks of product structure become clear: items (catalogs) and BOMs (instances).

• Items (Catalogs): Defined once, reusable everywhere, identified by a unique part number. This is where reference properties live—cost, vendor, weight, and so on.
• BOMs (Bills of Materials): Product structures made by connecting items into hierarchies. Here, items are turned into instances with contextual properties—quantity, position, configuration.

And just as we saw in earlier chapters, OpenBOM provides multiple views to help you navigate a BOM:

• Single-Level BOM: Good for focused edits on one level of an assembly.
• Multi-Level BOM: Expands the full tree of sub-assemblies.
• Flattened BOM: Consolidates everything into a rolled-up list.

These are not different BOMs—they’re different ways to view the same underlying structure. And because the system distinguishes reference from instance, it keeps everything consistent.

Expansion into Multi-View BOM Architecture: xBOM

But as every engineer knows, one BOM is never enough. Design teams work with EBOMs, manufacturing teams need MBOMs, service teams rely on SBOMs, and procurement may have its own structure. Historically, each group created its own version—usually in Excel—and those versions drifted apart almost instantly.

OpenBOM introduces xBOM, which expands a single BOM into a multi-view architecture. Instead of duplicating or re-creating BOMs, xBOM lets you generate and navigate multiple views from the same underlying dataset.

• EBOM (Engineering BOM): Driven by CAD and engineering design intent.
• MBOM (Manufacturing BOM): Tailored for production, includes process-specific properties, alternates, substitutes.
• SBOM (Service BOM): Configured for spares, maintenance, and repair.
• Other Types: Requirement BOMs, functional BOMs, or custom-defined structures created by admins.

Admins define these BOM types and set up templates for consistency. Users can then switch seamlessly between them via the UI.

Think of a bicycle:

• The EBOM reflects the CAD model—frame, wheels, gears.
• The MBOM adapts it for production—adding fasteners, adjusting finishes.
• The SBOM marks which items are available as spares for service.

All three remain connected to the same catalog data, so changes cascade consistently.

Technical Deep Dive: Graph Architecture and Database Management

In previous chapters, I highlighted how OpenBOM is not built on old SQL schemas. Here, I want to go deeper into why the graph architecture is so critical for reference instance and xBOM.

Product structures are not flat tables—they’re graphs of relationships. OpenBOM uses a hybrid stack to represent them naturally:

• Neo4j Graph Database: Models items and instances as nodes and edges, supporting fast traversal and flexible relationships.
• MongoDB: Stores object data (catalogs, BOMs, properties) with schema flexibility.
• ElasticSearch: Provides indexing, search, and analytics.

This combination enables capabilities that legacy systems struggle with:

• Where-Used Analysis: Instantly trace where a part is used across BOMs and xBOM views.
• Impact Analysis: Understand ripple effects of design changes across engineering and manufacturing.
• Revision Management: Link revisions across EBOMs, MBOMs, and SBOMs with lifecycle traceability.
• BOM Comparison: Highlight differences between two BOMs or BOM types.

This architecture isn’t just about efficiency—it lays the foundation for the Digital Thread and even for AI-driven workflows. The reference–instance graph becomes the context that intelligent agents can reason about.

User Guide Perspective: Applying Reference–Instance, BOM, and xBOM

Theory is important, but how does this play out for an everyday OpenBOM user? Let’s walk through it.

1. Define Items in a Catalog: Add your parts to a catalog, complete with global properties like cost, weight, or vendor.
2. Build a BOM: Assemble a product by adding items. Each item becomes an instance where you define contextual properties—quantity, position, role.
3. Add Instance Properties: Apply specifics like torque settings, spare part flags, or alternate suppliers.
4. Switch to xBOM Views: Toggle between EBOM, MBOM, SBOM as needed, without re-entering data.
5. Use Advanced Tools: Run Where-Used, manage revisions, and compare BOMs to track differences.

One of the most valuable lessons is deciding carefully what belongs in the catalog versus in the BOM. Cost? Usually a catalog. Spare flag? Instance. Description? Catalog. Torque setting? Instance. This discipline ensures that catalogs stay clean, while BOMs remain context-aware.

In the previous chapter, I emphasized how views provide flexibility. Here, we see that flexibility is extended across the entire lifecycle with xBOM. And in upcoming chapters, I’ll connect this to workflows like procurement planning and requirements management.

Conclusion: A Unique Architecture for Modern Product Data

The combination of the reference–instance model and xBOM defines OpenBOM’s product structure. Together, they transform BOMs from static documents into a dynamic product knowledge graph.

• For users, it means less duplication, less confusion, and more control.
• For organizations, it provides a single source of truth across design, manufacturing, and service.
• For the future, it creates the foundation for digital threads and AI agents that can reason about products.

This chapter builds on the foundation we laid earlier in the series—objects, properties, and views—and shows how they grow into a flexible product structure model. In the next chapter, I’ll continue this journey by exploring how these principles extend into connected processes like procurement, change management, and beyond.

OpenBOM’s message is simple: this is a unique data architecture built around flexible data modeling principles, designed for the complexity of modern products and the agility that companies demand.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg