Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.firstresonance.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

An as-built BOM (aBOM) is the parent/child tree of part inventories that compose a finished assembly. Where the mBOM says “this part needs this and this and this,” the aBOM says “we built this specific unit using these specific serials and lots.” The aBOM is the post-execution truth — the record customers, auditors, service teams, and recall investigators need.

​
How the aBOM is generated

A run instantiates an aBOM from the parent part’s mBOM:
  1. 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 and you see its build genealogy.

​
aBOM hierarchy

The aBOM is a tree, not a flat list. Sub-assemblies are part inventories that themselves have aBOMs: 
ASM-00012 (BRKT-ASSY-001)        ← top-level assembly
├── SN-00001 (BRKT-001)
├── LOT-2026-0123 (FAST-M3, qty 4)
└── ASM-00099 (PCB-001)          ← sub-assembly with its own aBOM
    ├── SN-00500 (PCB-BLANK)
    ├── LOT-2026-0050 (CAP-100uF, qty 8)
    └── ...
To traverse the full tree, recurse through each installedPartInventory. ION exposes that traversal directly via the API — see Common Queries → 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. The breadcrumb at the top of the modal lets you walk back up.
The aBOM Part Manager (which you launch from a part inventory or run) is the interactive surface for this — see Editing Build Requirements for the editing flow.

​
Traceability — what the aBOM is for

Three common traceability queries the aBOM answers 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?”

Reverse traversal — given a LOT-2026-0123 of FAST-M3, find every parent assembly it was installed into. ION supports this via the parentPartInventory relationship on the consumed inventory; the API surfaces it cleanly.

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

Same reverse traversal applied to a problematic supplier lot. Run it against open inventory + work-in-progress + delivered units to scope the recall.

​
aBOM vs mBOM divergence

The whole point of the aBOM is that it can — and does — diverge from the mBOM. Reasons:
  • Substitutes used — operator scanned an approved substitute instead of the primary. The aBOM line records what was actually installed, which is the substitute.
  • Quantities adjusted — measurement showed the assembly needed 3 fasteners instead of the planned 4. Documented as a deviation.
  • Redlines applied — a run-level redline added or modified a build requirement; the aBOM reflects that change.
  • MOA installs — a sub-assembly built onto the parent (vs. as its own run) consolidates into the parent’s aBOM.
The mBOM is the plan; the aBOM is the truth. Neither is “more correct” — together they tell you what was intended and what happened.

​
When the aBOM is “complete”

The aBOM is complete when the run completes. Up until then it’s a work-in-progress — some build requirements may be unsatisfied, some installations may be pending, and operators are still acting against it. Once the run transitions to Complete (per Run Completion and Review):
  • All required build requirements have installations (or explicit exceptions via issues).
  • The aBOM is locked — no more edits without explicitly reopening the run.
  • Downstream systems (traceability reports, inventory state updates, customer documentation) consume the locked aBOM.

​
Tips

  • Treat the aBOM as canonical. When in doubt about what was built, the aBOM is the answer — not the mBOM, not memory, not the spec.
  • Use API traversal, not the UI, for batch queries. “Find every assembly that contains lot X” is fast via the API; painful in the UI when you have hundreds of parents.
  • Don’t try to “clean up” aBOMs. A surprising aBOM (substitutes used, qty deviation, redline applied) is signal, not noise. Editing it after the fact destroys traceability.