Tech Tip: Part Item vs. Instance—The Power of OpenBOM’s Data Model Semantics

Engineering data is not just about parts—it’s about relationships. What is this part? Where is it used? How is it used differently in different places?

At OpenBOM, we’ve built a flexible and semantically rich data model that captures both the identity of an item (the reference) and the way it’s used in a product structure (the instance). This model is the foundation of OpenBOM’s power, and today we’ll unpack what it means—and why it matters. 

Learn more about the OpenBOM data model in our documentation: 

OpenBOM Data Management 

Deep dive into OpenBOM Data Model and Instance Properties. 

In my article today, I will give you a few practical examples of the usage of both item and instance properties when creating semantics in your product data. 

What is OpenBOM’s Instance-Reference Model?

Traditional systems often treat all part data the same, blurring the line between what stays constant (e.g., part number, cost) and what changes depending on context (e.g., quantity, configuration settings). OpenBOM separates these into two clear and connected layers:

✅ Item Reference (Catalog Item)

This is the definition of a part or assembly. It includes properties that are always true, no matter where the item is used—things like part number, description, unit of measure, and default unit cost. You define it once in your Catalog, and all BOMs using that item automatically reference the same definition.

🔁 Item Instance (BOM Item)

This is how that part is used in a specific BOM. Here, you define properties that vary by usage—quantity, configuration, role (e.g., spare part), or assembly-specific parameters like torque. Even though the item is the same, its instance data can change from one BOM to another.

This dual-layer structure allows OpenBOM to maintain data integrity, consistency, and flexibility—something legacy PLM systems often struggle with.

Real-World Use Cases: Modeling Items and Instances in OpenBOM

Let’s go through a few examples to show how this model applies to real engineering and manufacturing situations.

Example 1: Unit Cost – A Reference Property

Imagine you’re using a standard aluminum bracket across 10 different assemblies. The bracket always costs $12.75 from your supplier.

With OpenBOM, you define the cost once in the Catalog (Item Reference). That cost is automatically inherited across all BOMs. You never need to duplicate or update it in each assembly—one source of truth for cost.

Why it matters:
This keeps financial data clean, avoids errors in cost rollups, and supports consistent procurement planning across the company.

Example 2: Description – A Reference Property

A good product catalog starts with clear, standardized descriptions. Say you have a fastener labeled: “M6x30 Stainless Steel Hex Bolt.”

This description is defined at the item level in your Catalog and is automatically shown in every BOM where the item is used. There’s no risk of engineers retyping the description differently or inconsistently.

Why it matters:
This helps with procurement, avoids confusion in manufacturing, and ensures everyone speaks the same language when referencing parts.

Example 3: Spare Part Flag – An Instance Property

Here’s where the instance model shines. You’re using the same motor controller in several products. In Product A, it’s a core component. But in Product B, it’s included only as a spare part.

In OpenBOM, you add a checkbox property called “Spare Part” at the BOM level. For Product B, you check it. For others, you leave it blank. The item is the same, but the role it plays is different in each BOM.

Why it matters:
This allows clear differentiation for documentation, servicing, and logistics. Spare part lists can be generated directly from BOM instance data without cluttering the Catalog or duplicating items.

Example 4: Torque Settings – An Instance Property

You’re assembling the same screw into two different products, but each product requires a different torque specification during final assembly. How do you model that?

With OpenBOM, you define a numeric property called “Torque (Nm)” at the BOM level. You assign the correct torque value to each instance of the screw depending on the BOM. The Catalog still defines what the screw is—but the BOM defines how it’s used.

Why it matters:
This supports quality control and manufacturing precision without creating artificial part duplicates. The same fastener can serve multiple products with different requirements—modeled cleanly in one place.

Conclusion: Smarter Structures with Semantics

OpenBOM’s instance-reference data model goes beyond basic part lists. It enables you to build a true digital product model—where parts are not just listed but understood in context.

By distinguishing between what’s universal (item definition) and what’s contextual (instance usage), you get:

• Clean, non-redundant catalogs
• Precise and flexible BOMs
• Better collaboration between engineering, manufacturing, and procurement
• A foundation for future automation and digital thread applications

If you’re still managing your BOMs in Excel or using tools that don’t distinguish between instances and references, you’re likely missing out on this critical level of clarity.

Need help to define and configure OpenBOM for your specific data models? At OpenBOM, we’re not giving you “OOTB” SaaS applications you cannot configure. OpenBOM is a flexible model that allows you to create data models in a granular and semantic manner. 

REGISTER FOR FREE to check how OpenBOM can help you today. 

Best, Oleg