When experienced configuration management practitioners repeatedly say “CAD is not a part,” it is usually a signal that the industry is still struggling with something fundamental. In his recent article – CAD is not Part: “How to evolve CAD models without constantly having to change your part?”, Martijn Dullaart articulated this problem clearly and concisely, explaining why forcing a one-to-one relationship between CAD models and part numbers inevitably leads to frustration, duplication, and inefficiency. His argument resonates with many people not because it is new, but because it describes a mistake that continues to appear in PLM implementations across industries.
At OpenBOM, this was never just a philosophical discussion. It directly influenced how we designed the system. The decision to separate Design Projects (PDM function), Items Lifecycle, and BOMs (including xBOM) is not an arbitrary modeling choice or a user experience convenience. It is a response to the reality that CAD files, items, and product structures evolve at very different speeds, serve different audiences, and carry very different types of responsibility.
This article explains why OpenBOM is built this way, what problem it is trying to solve, and why collapsing everything into a single CAD-centric object eventually works against you as products, organizations, and supply chains grow more complex.
The persistent confusion between CAD and parts
The idea that a CAD file and a part should share the same identity is deeply ingrained in many engineering organizations. In early PDM and PLM systems, this coupling felt natural. You created a CAD model, saved it with a name or number, and that identifier became the part number that flowed into downstream systems. For small teams and simple products, this often worked well enough to avoid questioning it.
The problem is that this approach quietly assumes that design work and product development commitment are the same thing. In practice, they are not. CAD models exist to explore geometry, resolve constraints, test ideas, and define how an object is designed. Parts exist to represent something that can be manufactured, purchased, stocked, replaced, and serviced over time. Treating them as a single object forces one lifecycle to compromise for the other.
Martijn’s article highlights exactly this tension. Designers need freedom to evolve CAD geometry, electronic design and, these days, software design, without triggering unnecessary part re-identification, while manufacturing and supply chain teams need stability and traceability. When both are forced into a single CAD-equals-part construct, nobody is fully satisfied, and the system becomes brittle under change.
OpenBOM Design Projects
One of the first architectural questions we faced when building OpenBOM was deceptively simple: where should CAD files live, and what should they represent in the system? Thinking about that was important to differentiate the lifecycle (and not only “file” attachments). You can attach multiple files to an items in OpenBOM both on the item and instance level, but those file objects represents a finished design or derivatives (eg. STEPs, PDFs)
However, for the design lifecycle, we introduced Design Projects as a first-class concept. A Design Project represents design activity. It is a container for CAD files, drawings, and other related documents, along with their versions. It reflects how design work actually happens: incrementally, imperfectly, and often with many parallel ideas before a decision is finalized.
This distinction matters because design work is exploratory by nature. Designers routinely create variations, try alternatives, and discard options that never become real products. If every one of these iterations is forced to become an item object with a formal identity, revision history, and approval workflow, design speed slows down and administrative noise increases.
Design Projects exist precisely to allow a freedom of design iteration with controlled versions. They give designers a place where files can evolve naturally, without immediately committing the organization to treating every change as an item and BOM event with its lifecycle.
Files have versions, items have identity and revisions
One of the most important conceptual distinctions in OpenBOM is that files have versions, while items have identity and revisions. This may sound subtle, but it has far-reaching consequences.
A file version answers the question, “What changed in the design?” An item answers a different question: “What is the thing we build, buy, or support?” These are not the same question, and they should not be governed by the same rules.
In OpenBOM, CAD files can be revised many times within a Design Project as geometry evolves. Those revisions do not automatically imply that the underlying item has changed in a way that affects form, fit, function, or interface. Only when a design decision crosses that threshold does it make sense to update the item definition and then later release a new revision for downstream use.
This approach aligns closely with configuration management thinking, even if many PLM systems historically blurred the line. Identity should follow interchangeability, not creativity. A designer refining a fillet, adjusting a hole location within tolerance, or reorganizing features should not automatically force procurement, manufacturing, and service teams to react.
Items exist to stabilize decisions
If Design Projects are about exploration, Items in OpenBOM are about product configurations and consolidated engineering views. An item represents a product decision that something exists as a defined product element. It carries meaning for purchasing, manufacturing, inventory, service, and lifecycle management. In modern products, it can be a mechanical item, electronic component, software component, documentation, packaging, maintenance items, and many items. Those items can be identified by multiple CAD systems and even ALM tools for software.
Items change far less frequently than files, and when they do change, it is because something important has shifted. Perhaps interchangeability is affected, perhaps a supplier change is required, or perhaps regulatory or service implications demand a new revision. These are business decisions, not design side effects.
By separating items from files, OpenBOM allows items to mature at their own pace. They can remain stable while design work continues upstream, and they can be reused across multiple design contexts without being tied to a single CAD representation. This is especially important for flexible components, standard parts, and anything that can appear in multiple configurations with different geometries.
BOMs are contextual, not structural mirrors
The third pillar of this architecture is the separation of BOMs from both files and items. In many systems, the BOM is little more than a reflection of the CAD assembly structure. While this may be convenient initially, it quickly becomes limiting.
A BOM is not just a list of components. It is a representation of decisions made in a specific context. Engineering BOMs, manufacturing BOMs, service BOMs, and procurement views all answer different questions and often require different structures. Forcing them to follow the same hierarchy as a CAD assembly ignores those differences. Therefore OpenBOM has xBOM structures allowing it to build multiple BOM types – EBOM, MBOM, SBOM, etc. You can define as many as organization needs and name them differently.
In OpenBOM, BOMs are compositions of items organized for a particular purpose. They are not bound to folder structures or CAD trees. This allows non-geometric elements such as paint, adhesives, packaging, and consumables to be modeled naturally, even though they never appear in CAD. It also makes it possible to represent multi-domain products where mechanical, electrical, and software elements must coexist without one domain dominating the structure.
What breaks when CAD structure becomes Item/BOM truth
The consequences of collapsing files, items, and BOMs into a single CAD-driven model tend to appear gradually, which is why they are often underestimated. Flexible components such as hoses, cables, and gaskets start to multiply because each geometric variation demands a new part number. Minor design tweaks trigger unnecessary re-identification and approval cycles. Supply chain records churn even when interchangeability has not changed. Electrical and software teams are forced to align with mechanical file management conventions that do not reflect their reality.
None of these problems are caused by user error or lack of discipline. They are symptoms of architectural coupling. When a system assumes that one structure can serve all purposes, it eventually becomes a bottleneck as complexity increases.
This is why the same warnings keep resurfacing in the PLM community. The theory is well understood, but many data models still make the wrong behavior easy and the right behavior difficult.
Separation alone is not enough
It is important to say that separation by itself is not a silver bullet. Treating files, items, and BOMs as completely disconnected silos would simply replace rigidity with chaos. Manual synchronization, spreadsheets, and ad-hoc processes would quickly erode traceability and confidence.
The missing piece is automation and relationship management. In OpenBOM, files can be linked to items, items can participate in multiple BOMs, and BOMs can remain stable even as design files evolve. These relationships are managed by the system, not by people trying to remember what changed where.
This is where modern PLM architecture diverges from older approaches. Instead of forcing everything into a single object with one lifecycle, OpenBOM allows different objects to evolve independently while remaining connected through explicit, traceable relationships.
Complexity grows faster than structure
As products become more complex, multi-domain, and globally sourced, the cost of architectural shortcuts increases. The challenge is no longer just managing data volume, but managing change velocity. Design evolves quickly, supply chains demand stability, and customers expect traceability across long product lifecycles.
Forcing these competing needs into a single CAD-centric structure does not reduce complexity. It amplifies it. Separating Design Projects, Items, and BOMs acknowledges that complexity exists and provides a way to absorb it rather than fight it.
Conclusion: A design choice, not a feature checklist
The separation of Design Projects, Items, and BOMs in OpenBOM was not introduced to check a feature box or to differentiate for the sake of differentiation. It was a deliberate design choice grounded in how products are actually developed, manufactured, and supported.
Design Projects exist because CAD work is exploratory and iterative. Items exist because product development organizations, suppliers and contractors need stable identity and controlled change. BOMs exist because decisions are always made in context. Treating these concepts as distinct but connected is not adding unnecessary layers. It is recognizing that simplicity at the wrong level eventually becomes a liability.
Martijn is right to remind us that CAD is not a part. OpenBOM’s architecture simply accepts the consequences of that truth and builds a system around it.
Want to explore OpenBOM?
REGISTER FOR FREE and check how OpenBOM can help you.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
