Modeling the Bill of Materials as an Object Network
Every production vehicle eventually becomes brutally concrete.
Ideas become specifications.
Specifications become components.
Components become assemblies.
Assemblies become a vehicle.
At this point, automotive manufacturing depends on one of its most fundamental structures:
the Bill of Materials — BOM.
A conventional BOM answers an essential question:
What is required to build this vehicle?
It may contain thousands of parts arranged into assemblies and subassemblies:
Vehicle│├── Body├── Chassis├── Interior├── Electrical System├── Propulsion System├── Energy System└── Thermal System
This hierarchy is indispensable for manufacturing.
But from a ZenOps perspective, it represents only one view of something much larger.
A component does not merely belong to an assembly.
It interacts with other components.
It satisfies requirements.
It implements patterns.
It is manufactured through processes.
It comes from suppliers.
It participates in tests.
It may fail in the field.
It may be replaced during service.
And ultimately, it exists because some human need justified its presence.
The Bill of Materials can therefore be understood not merely as a tree of parts, but as an object network.
The Traditional BOM
Consider a simplified electric vehicle BOM:
Vehicle│├── Body Assembly│ ├── Front Structure│ ├── Passenger Cell│ ├── Doors│ └── Exterior Panels│├── Chassis│ ├── Front Suspension│ ├── Rear Suspension│ ├── Steering│ └── Brakes│├── Energy System│ ├── Battery Pack│ │ ├── Battery Modules│ │ │ └── Battery Cells│ │ ├── Housing│ │ ├── Contactors│ │ └── Sensors│ └── Charging System│└── Propulsion ├── Inverter ├── Motor └── Gear Reduction
This structure answers:
What contains what?
That is an important relation.
But it is only one relation.
The physical vehicle contains many more.
From BOM Tree to Object Network
Consider the battery pack.
A traditional BOM might tell us:
Vehicle containsBattery PackBattery Pack containsBattery ModuleBattery Module containsBattery Cell
Now apply the ORIGIN perspective.
The same battery pack might participate in relations such as:
Battery Pack supplies energy toInverterBattery Pack receives energy fromCharging SystemThermal System regulates temperature ofBattery PackBattery Management System monitorsBattery PackBody Structure protectsBattery PackVehicle Controller receives state fromBattery Management System
The BOM hierarchy still exists.
But it now sits inside a network.
This network tells us considerably more about how the vehicle actually works.
“Contains” Is Only One Relation
Traditional product structures are dominated by:
Parent contains Child
ZenOps expands the vocabulary.
A component may:
contain
connect to
supply
receive
support
protect
control
monitor
cool
heat
communicate with
transfer force to
transfer energy to
restrain
seal
mount to
verify
depend upon
and many other relations.
Consider a wheel assembly:
Suspension positionsWheelWheel Bearing supportsWheelDrive Shaft transfers torque toWheelBrake applies braking torque toWheelTire mounts toWheelTire interacts withRoadWheel-Speed Sensor observes rotation ofWheel
Now the object has functional context.
We no longer know merely where the wheel belongs.
We know something about why it matters.
A BOM Object Should Have Identity
To build a persistent object network, every important object needs identity.
Suppose we define:
COMP-000417Electric Drive MotorCOMP-000418Traction InverterCOMP-000419Motor Temperature Sensor
These identities can persist independently of where the objects happen to appear in a document or user interface.
Relations can then reference them:
COMP-000418 supplies controlled electrical power toCOMP-000417COMP-000419 measures temperature ofCOMP-000417
This becomes particularly powerful when identities persist across engineering, manufacturing, testing and service.
Definition and Instance Are Different Objects
A crucial distinction appears when the design enters manufacturing.
Engineering defines a component:
Motor Type M17
Manufacturing produces physical instances:
Motor M17│├── Serial #000001├── Serial #000002├── Serial #000003└── ...
The component definition and the physical component are not the same object.
The definition says what the motor should be.
The instance represents a motor that actually exists.
The relationship might be:
Physical Motor #M17-004728 instance ofMotor Definition M17
This distinction connects engineering to reality.
The Vehicle Is Also an Instance
The same principle applies to the complete automobile.
Engineering defines:
Vehicle Model X
Manufacturing creates:
Vehicle #000001Vehicle #000002Vehicle #000003
Each vehicle can contain specific physical component instances:
Vehicle #000142│├── Battery #B77124├── Front Motor #M18291├── Rear Motor #M19341├── Brake Controller #BC7712└── Steering Controller #SC9918
The physical BOM is therefore no longer just:
Which type of component belongs here?
It can answer:
Which exact component was installed in this exact vehicle?
That is a major transition.
The BOM Becomes a Configuration Network
Modern vehicles are rarely manufactured in one identical configuration.
There may be different:
- Batteries
- Motors
- Seats
- Wheels
- Brakes
- Infotainment systems
- Sensors
- Regional equipment
- Software configurations
The object network can model these variants explicitly.
For example:
Vehicle Model permits configurationLong-Range BatteryVehicle #000142 configured withLong-Range Battery #B77124
The distinction between allowed configuration and actual configuration becomes visible.
This gives us a much more precise representation of the physical fleet.
Software Belongs in the Product Structure
The traditional idea of a BOM is strongly physical.
But a modern vehicle cannot be understood without software.
Suppose:
Brake Controller #BC7712
exists physically.
Its behavior may depend upon:
Brake Software v4.17.3
The object network can represent:
Brake Controller #BC7712 executesBrake Software v4.17.3
Now consider a software update:
Brake Controller #BC7712 executesBrake Software v4.18.0
The physical controller has not changed.
The behavior of the vehicle may have.
A complete automotive product model therefore needs both:
physical configuration
and:
software configuration.
Connect BOM Objects to Requirements
Now we can move upward in the ZenOps model.
Suppose the NDD contains:
Protect occupants during frontal collision.
That need generates engineering requirements.
Those requirements may be allocated to objects such as:
Front StructurePassenger CellSeatSeat BeltAirbagCrash SensorRestraint ControllerRestraint Software
The relation might be:
Requirement REQ-1047 satisfied byFront StructureRequirement REQ-1047 satisfied bySeat Belt SystemRequirement REQ-1047 satisfied byAirbag System
The BOM has now connected back to human purpose.
Connect BOM Objects to Tests
The network can also connect downward toward evidence.
For example:
Requirement REQ-1047 verified byCrash Test TEST-220Crash Test TEST-220 usesVehicle Prototype #P017Vehicle Prototype #P017 containsAirbag Controller #AC118Crash Test TEST-220 producesTest Result RESULT-220
Now we can navigate:
Need → Requirement → Component → Vehicle → Test → Evidence
The Bill of Materials has become part of the evidence structure.
Connect Components to Suppliers
Each component may also have a supply relationship.
Supplier A manufacturesBrake ControllerSupplier B manufacturesWheel-Speed SensorSupplier C manufacturesBearing
But we can go further:
Supplier A manufacturesProduction Batch 2026-091Production Batch 2026-091 containsBrake Controller #BC7712Brake Controller #BC7712 installed inVehicle #000142
Now supplier traceability reaches the individual vehicle.
Connect Components to Manufacturing Operations
The same component can participate in manufacturing relations:
Workstation WS-042 performsInstallation Operation OP-118Operation OP-118 installsBrake Controller #BC7712Operation OP-118 performed onVehicle #000142Tool T-991 used duringOperation OP-118Inspection INSP-881 verifiesOperation OP-118
The component is no longer merely a line in a BOM.
It has a production history.
Connect Components to Field Failures
Now imagine that Vehicle #000142 generates a diagnostic event five years later.
Vehicle #000142 generatesDiagnostic Event D-88172Diagnostic Event D-88172 identifiesBrake Controller #BC7712
We can navigate backward:
Brake Controller #BC7712 ↑installed byOperation OP-118 ↑performed atWorkstation WS-042 ↑component belongs toProduction Batch 2026-091 ↑manufactured bySupplier A
And upward through engineering:
Brake Controller #BC7712 ↑instance ofBrake Controller Definition ↑implementsBrake System Architecture ↑satisfiesEngineering Requirement ↑derived fromNDD Need
One field event can potentially connect the entire lifecycle.
The Network Makes Patterns Visible
When thousands of vehicles produce evidence, something even more interesting becomes possible.
Suppose failures cluster around:
Supplier A
plus:
Production Batch 2026-091
plus:
Software v4.17
plus:
low-temperature operation.
A traditional BOM can tell us where the component belongs.
The object network can expose the larger pattern.
The problem may not belong to one object alone.
It may exist in the relationship between:
component + software + manufacturing batch + environment.
This is one reason network thinking matters.
Failures often exist in relations.
The BOM Can Become Recursive
The same modeling principle works at every scale.
A vehicle contains a battery.
A battery contains modules.
A module contains cells.
A cell contains materials.
Each level can have its own object network.
Vehicle containsBattery PackBattery Pack containsModuleModule containsCellCell containsMaterial
But cross-relations can span levels:
Cooling System affectsModuleSoftware estimates state ofCellCrash Structure protectsBattery PackSupplier providesCellManufacturing Process joinsModule Components
The model is hierarchical where hierarchy is useful and networked where relationships cross the hierarchy.
From Bill of Materials to Bill of Relationships
This suggests an interesting extension.
The conventional BOM is effectively a:
Bill of Objects
It tells us which physical things are required.
The ZenOps model adds something like a:
Bill of Relationships
Because knowing that two components exist is not enough.
We also need to understand how they are expected to interact.
For example:
Battery → supplies → InverterInverter → controls → MotorMotor → transfers torque → DrivetrainDrivetrain → drives → WheelWheel → carries → TireTire → interacts with → Road
The functional vehicle exists through these relationships.
A complete product definition therefore needs both:
what exists
and:
how what exists is connected.
The Object Network Does Not Replace the BOM
The traditional BOM remains extremely useful.
Manufacturing still needs quantities.
Procurement still needs part numbers.
Logistics still needs material structures.
Assembly planning still needs product decomposition.
ZenOps does not need to destroy this structure.
Instead, the BOM becomes one view of the underlying domain model.
A procurement view might show:
Supplier → Part → Quantity → Cost
An engineering view might show:
Requirement → System → Component → Interface
A manufacturing view might show:
Vehicle → Assembly → Operation → Workstation
A service view might show:
Vehicle → Installed Component → Diagnostic Event → Repair
Different views can be generated from the same object network.
From Static Document to Living Product Model
A conventional BOM can easily become a snapshot:
This is what we intend to build.
An object network can remain active throughout the lifecycle:
Need ↓Requirement ↓Component Definition ↓Supplier ↓Physical Component ↓Manufacturing Operation ↓Vehicle Instance ↓Software Configuration ↓Test ↓Operation ↓Diagnostic Event ↓Service ↓Evidence
The product structure becomes a living model.
The Physical Vehicle Becomes Navigable Knowledge
Imagine a technician selecting a failed motor inside the digital representation of a vehicle.
From that one object, the system could potentially expose:
- Exact motor identity
- Engineering definition
- Supplier
- Production batch
- Installation operation
- Manufacturing date
- Related requirements
- Connected components
- Software controlling the motor
- Test history
- Previous diagnostic events
- Service history
- Similar failures in other vehicles
Now imagine an engineer selecting the requirement that originally justified that motor behavior and navigating in the opposite direction.
The knowledge system could show every relevant component, test and affected vehicle.
That is the power of identity plus relations.
From Human Need to Bolt
At its deepest level, the ZenOps object-network BOM creates a remarkable possibility.
We should be able to start with a human need:
Transport the family safely during winter.
and travel downward:
Human Need ↓NDD ↓Requirement ↓Architecture ↓System ↓Assembly ↓Component ↓Subcomponent ↓Physical Part
Then travel further:
Physical Part ↓Supplier ↓Manufacturing Batch ↓Installation Operation ↓Vehicle Instance ↓Test ↓Field Operation ↓Evidence
And we should be able to travel backward again.
In principle, even a bolt can have a reason for being there.
Not merely:
Because the drawing says so.
But:
Because it participates in a chain of objects and relations that ultimately satisfies a human need.
The BOM Becomes Part of the ZenOps Knowledge Network
We can now place the Bill of Materials inside the larger automotive ZenOps model:
x↓NDD↓Requirements↓ORIGIN↓Patterns↓Architecture↓Component Definitions↓BOM↓Object Network↓Manufacturing↓Physical Vehicle↓Operation↓Evidence
The traditional Bill of Materials remains present.
But it is no longer isolated.
It becomes connected upward to purpose and downward to reality.
This changes the question from:
What parts make up this car?
to:
What objects and relationships make this vehicle work, why does each exist, how was each realized, and what evidence tells us that the resulting system actually satisfies the original need?
That is the transition from a Bill of Materials to an automotive object network.
The BOM tells us what we built.
The object network tells us what we built, how it works, why it exists, and what happened to it in reality.
