How OpenBOM Connects Collaboration and Change Control for Humans and AI

OpenBOM manages product information through three levels: live collaborative data, automatic change history, and immutable snapshots. This architecture allows engineering, procurement, and authorized AI agents to contribute to shared structured product information while preserving traceability and creating controlled revisions at meaningful milestones.

Product information changes throughout the day. An engineer replaces a component. Procurement updates a supplier and a price. Another team member corrects a description or adds a missing specification. Increasingly, an AI agent can participate by reviewing a BOM or helping complete product data.

These activities create a practical challenge: how can everyone work with current information while the company preserves the exact product states needed for review, manufacturing, and release?

At OpenBOM, we address this through an architecture that separates three responsibilities: maintaining live structured data, recording its changes, and capturing immutable states. This separation connects the everyday editing experience with the discipline of change control.

It also explains why our approach to data management matters for AI. Humans and authorized agents can contribute to the same product context, while history and controlled revisions provide continuity as that information evolves.

A familiar interface for connected product data

Spreadsheets offer an interaction model that engineers and manufacturing teams understand. You can find a row, edit a value, copy information, filter a list, and continue working. OpenBOM brings that familiar experience to structured engineering and manufacturing data.

Underneath the interface, the information has identity and relationships. Items represent parts, assemblies, and other product records. Catalogs organize Items and their properties. BOMs describe how Items are used together. Files, sourcing information, and other references add context to those records.

Consider a power supply. Its manufacturer part number describes the Item. The quantity required in a particular control cabinet describes its use in that assembly. Keeping these meanings connected helps teams maintain reusable component information alongside assembly requirements.

When a user edits a value, they are changing a specific part of that structured context. The workspace provides direct access to the working data. Its familiar appearance makes an underlying product data model accessible to the people responsible for maintaining it.

Three levels of OpenBOM data architecture

Level one is the live collaborative data object

The first level is the current, editable state of the data object. This is where work happens: properties are completed, components are added, quantities are adjusted, and sourcing information is updated.

OpenBOM supports simultaneous editing of structured product information. Engineering and procurement can contribute during the same working session, with access determined by their permissions. Each participant works with shared information, and the interface reflects changes as the work progresses.

This makes real-time collaboration an architectural capability. The system supports multiple participants contributing to the same evolving data, rather than making collaboration depend on exchanging and reconciling separate working copies.

An individual edit changes the current instance. Changing a quantity from four to five is one such operation. That operation does not, by itself, require the team to declare a new engineering revision. The working state can continue evolving as people resolve the details.

Level two is the history of changes

The second level records how that working state evolved. OpenBOM automatically tracks changes to Items and BOMs, including who changed what and when. Teams can inspect the history as they work.

History makes ordinary editing traceable. If a quantity changes several times during a design discussion, the current value answers what the team is working with now. The history helps explain the sequence of modifications leading to that value.

This distinction matters because the frequency of editing and the frequency of formal milestones are different. A team might make dozens of adjustments while preparing an assembly for review. Those adjustments deserve traceability even when the team needs only one new revision at the end of the process.

History therefore supports continuous work without requiring a new named baseline for each interaction. It also gives collaborators a way to understand what happened while other people were contributing.

An audit trail tells us which values changed. Understanding why a change was made may also require the review discussion, a specification, or an engineering decision. Connecting that explanation to the relevant product information makes the history more useful to the next person investigating a problem.

Level three is the immutable snapshot

At certain moments, a team needs to preserve a specific state. A design reaches a milestone, an assembly is ready for a prototype build, or a change completes its approval process. This is the role of the third level: the immutable snapshot.

OpenBOM revision control captures a baseline of Item data, including its BOM where applicable. That saved state remains available while work continues in the editable data. The team can refer back to the captured revision without allowing subsequent edits to rewrite it.

Versions and revisions apply this preservation principle in their respective contexts. OpenBOM uses version management for design files and revision management for Items and BOMs. The surrounding workflow determines the business significance of the captured state.

Where formal control is required, OpenBOM change requests and change orders introduce review and approval. A revision candidate goes through the configured process before becoming a revision. Capturing a state and approving it are distinct responsibilities within that process.

Engineering and procurement working together

Imagine a team preparing an industrial inspection machine for its first production build. Its BOM includes a mechanical frame, cameras, electronics, wiring, and a control cabinet.

An engineer replaces the cabinet’s power supply to accommodate an updated electrical requirement. During the same working period, a buyer updates sourcing properties for the replacement and checks its price and lead time. Another engineer completes the component description and adjusts the mounting hardware quantity.

These contributions update the connected product information. Engineering can see the sourcing details as the design develops, and procurement can work with the component selection being considered by engineering.

The changes become part of the history. At the production milestone, the team follows its revision and approval process to establish the required baseline. Later design work continues from the editable state, while the captured revision provides a stable reference for that milestone.

This combination reduces the administrative effort of keeping separate copies aligned and makes the transition from collaborative work to controlled product information explicit.

Bringing AI agents into the same workspace

Now extend that example with AI. OpenBOM BOM Review already provides checks for missing properties, part number patterns, quantity consistency with reference designators, and structural loops. Review findings can be discussed and assigned for resolution in the collaborative workspace.

For the inspection machine, a review might identify missing supplier information or incomplete descriptions. The team can investigate these findings in relation to the actual components and assemblies involved.

A data completion workflow illustrates the next architectural opportunity. An authorized agent could examine an attached specification, propose a description or classification, and apply an accepted update through the platform’s supported interfaces. Engineering and procurement could continue contributing to the same working context during that period.

Humans and AI agents share the working context

This example describes how an agent can participate; the precise actions depend on the tools and permissions provided to that agent. A review finding, a proposed correction, and an applied edit remain different things.

The shared data model gives those actions a specific target. The agent can associate a proposed value with an Item or BOM relationship, while the team retains responsibility for determining whether the change is appropriate. That connection makes the result easier to evaluate in context.

For an agent, this context changes the task. A missing value belongs to a component with a particular identity, used in specific assemblies and connected to supporting information. The agent can use those relationships to determine which evidence is relevant and where its proposed update belongs. The same context helps a human reviewer assess the suggestion.

This is particularly useful when several participants contribute during a review: everyone needs to understand which working data is being examined and which captured state will ultimately serve as the stable reference.

As agent activity grows, the three levels retain their roles. The live object provides the working context. Change history supports traceability. Immutable snapshots preserve the states selected for controlled use. Access to editing does not automatically grant authority to approve or release a revision.

The architecture behind the everyday experience

OpenBOM’s editing experience reflects a deliberate approach to product information: make structured data easy to maintain, support collaboration as work happens, and preserve the states that engineering and business processes depend on.

That approach serves an engineer correcting a quantity, a buyer completing sourcing information, and an authorized agent helping improve data quality. Each contribution becomes part of an evolving product context.

For our customers, the value is practical. Teams can move work forward together, understand how information changed, and establish reliable references for the next stage of product development. As AI becomes a more active participant, these architectural foundations provide a consistent way to connect its contributions with everyday engineering and manufacturing work.

What are the three levels of OpenBOM data management?

The three levels are the live editable data object, the history of changes, and immutable snapshots. Together, they support continuous collaboration, traceability, and preservation of specific product states.

What is the difference between change history and a BOM revision?

Change history records modifications as product information evolves. A BOM revision preserves a specific state as a stable reference. Teams can make multiple edits and retain their history before creating a new revision.

How can humans and AI agents collaborate on product data?

Humans and authorized AI agents can access the same structured product context through their respective interfaces and tools. Agents can review information, propose corrections, or apply permitted updates, while approval processes govern controlled revisions.

Conclusion: Connecting architecture with user values 

OpenBOM’s data architecture connects the flexibility of everyday collaboration with the discipline of engineering change control. Teams work on live structured data, changes remain traceable, and immutable snapshots preserve the states that matter for product development and manufacturing.

These same foundations support collaboration between people and AI agents. An engineer can update a product structure, procurement can complete sourcing information, and an authorized agent can help review or improve the data. Their contributions belong to the same product context, with permissions and approval processes governing how working information becomes a controlled revision.

To see how this architecture translates into everyday work, watch these two demonstrations from the OpenBOM Product Tour:

• BOM review, comments, and tasks shows how teams review product information, discuss issues, and coordinate the work needed to resolve them. It brings collaboration directly to the BOM and the Items requiring attention.
• Change management, change requests, and ECO shows how teams organize changes, route them through approvals, and establish controlled revisions.

Together, these workflows demonstrate the value of OpenBOM’s architectural approach: product information can evolve continuously while teams maintain clear responsibility, traceability, and reliable baselines. As humans and AI agents contribute more actively to product development, this foundation becomes increasingly valuable.

REGISTER FOR FREE to check how OpenBOM works. 

Best, Oleg