Skip to main content
The aBOM is the per-unit record of what physically went into an assembly. See Bills of materials overview for how it relates to the mBOM and build requirements. This page covers how ION generates it, reads it, and traverses it.

​
How the aBOM is generated

A run instantiates an aBOM from the parent part’s mBOM:
  1. The run starts against a PartInventory, the unit being built.
  2. ION snapshots the parent part’s released mBOM into a per-run aBOM.
  3. As operators install components during the run (scan a serial, scan a lot, confirm a count), each install creates an Installation record linking the consumed PartInventory to the build requirement it satisfied.
  4. When the run completes, the aBOM is the full, attested tree of what went in.
The aBOM lives on the parent part inventory. Open the unit’s record to see its build genealogy.

​
aBOM hierarchy

Sub-assemblies are part inventories that themselves have aBOMs. For example, a top-level assembly such as ASM-00012 (BRKT-ASSY-001) contains:
  • SN-00001 (BRKT-001).
  • LOT-2026-0123 (FAST-M3, qty 4).
  • ASM-00099 (PCB-001), a sub-assembly with its own aBOM, containing its own installed inventory.
To traverse the full tree, recurse through each installedPartInventory. ION exposes that traversal directly via the API. For more information, see Get an aBOM with full hierarchy.

​
Reading an aBOM in the UI

From a part inventory page:
  1. Click the aBOM tab.
  2. The tree renders top-down: the parent assembly at the top, build requirements as branches, installed inventory as leaves.
  3. Click any installed unit to drill in. If it’s a sub-assembly, you see its aBOM too.
  4. Use the breadcrumb at the top of the dialog to walk back up.
The aBOM Part Manager, which you launch from a part inventory or run, is the interactive surface for this. For the editing flow, see Edit build requirements.

​
What the aBOM is for

The aBOM answers three common traceability queries directly.

​
What went into this delivered unit?

Open the unit’s aBOM. The full tree, down to every serial and lot consumed during its build, is the record.

​
Where did this lot end up?

Use reverse traversal. Given a LOT-2026-0123 of FAST-M3, find every parent assembly it was installed into. ION supports this through the parentPartInventory relationship on the consumed inventory, and the API surfaces it cleanly.

​
Are we shipping any units that contain this recalled supplier lot?

Apply the same reverse traversal to a problematic supplier lot. Run it against open inventory, work-in-progress, and delivered units to scope the recall.

​
When the aBOM completes

When the run transitions to Complete (see Run completion and review), the aBOM locks and downstream traceability reports, inventory state updates, and customer documentation consume the locked tree. Editing requires reopening the run.
Treat the aBOM as canonical. When in doubt about what was built, the aBOM is the answer, not the mBOM, memory, or the spec.
Use API traversal rather than the UI for batch queries. Finding every assembly that contains a given lot is fast through the API but slow in the UI when you have hundreds of parents.
Don’t try to clean up aBOMs. A surprising aBOM (substitutes used, quantity deviation, redline applied) is signal, not noise. Editing it after the fact destroys traceability.