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 in 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. To explore a unit’s full genealogy interactively, including which parent assemblies contain a given serial or lot, see Trace as-built inventory.

​
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 through the parentPartInventory relationship on the consumed inventory in the API.

​
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.

​
Shared installs after a lot split

An install that was in place before a lot split is linked to every lot that resulted from the split, so the same install shows on each lot’s aBOM. Editing that install from any of the sharing lots affects all of them: adding an install, changing a quantity, or removing an install applies to the whole sharing set, not just the lot on screen. ION flags a shared install on the build requirement row and confirms before you remove one, because removing it clears the install from every sharing lot at once. After you confirm, the removal is held for about 10 seconds, and a countdown toast lets you cancel before it applies. For the affected-lot grouping and the confirm-and-cancel behavior, see Split inventory on a run.

​
When the aBOM completes

When the run transitions to Complete (see Run completion and review), the aBOM locks. Downstream traceability reports, inventory state updates, and customer documentation consume the locked tree. Editing a locked aBOM requires reopening the run.