> ## 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

> How ION models a build's parts list: the mBOM plan, the aBOM record, and the build requirements that bridge them at run time.

ION splits a bill of materials into a plan and a record. The **manufacturing BOM (mBOM)** hangs off a [part](/build-hardware/parts) and holds engineering's planned structure. The **as-built BOM (aBOM)** hangs off a [part inventory](/manage-supply-chain/inventory) and holds the serial-and-lot record of what actually went into one unit. A **build requirement** is the shared line item: on the mBOM it states what should be installed, and on the aBOM it accumulates the installations that satisfy it.

When a run starts against a part inventory, ION snapshots the parent part's released mBOM into that run's aBOM, one build requirement per line, and locks the run to that mBOM version. Operators install against the aBOM during execution. The aBOM can diverge from the mBOM through substitutes, quantity deviations, redlines, and made-on-assembly installs, and that divergence is the traceability signal ION preserves. For the steps to edit requirements mid-run, see [Edit build requirements](/build-hardware/bills-of-materials/editing-build-requirements).

## Manufacturing BOM

The mBOM is the parent part's planned parts list. Each line is a build requirement carrying a child part and revision, a per-assembly quantity, approved substitutes, reference designators, and a made-on-assembly flag. ION multiplies the line quantity by the parent run quantity to compute demand. You maintain the mBOM on the **mBOM** card on the part page while its version is in **Draft**, and edits save inline. For the build and consumption flow, see [Manufacturing BOM (mBOM)](/build-hardware/bills-of-materials/manufacturing-bom).

If your engineering team keeps an eBOM in a PLM system such as Solidworks PDM, Arena, or Teamcenter, the ION mBOM is the manufacturing counterpart of it. Keeping the two in sync is a separate export/import or integration workflow.

## As-built BOM

The aBOM is a parent/child tree of part inventories that compose one finished unit. Sub-assemblies are part inventories with their own aBOMs, so traversal recurses through each `installedPartInventory`. Each install writes an `Installation` record linking the consumed inventory to the build requirement it satisfied. The tree answers traceability queries in both directions: what went into a delivered unit (top-down) and every parent a given lot reached (reverse traversal on `parentPartInventory`). For UI navigation and query patterns, see [As-built BOM (aBOM)](/build-hardware/bills-of-materials/as-built-bom). For batch traversal, see [Get an aBOM with full hierarchy](/api-reference/common-queries/abom-hierarchy).

The aBOM is a work-in-progress until the run completes, at which point every required build requirement has an installation or an explicit issue-based exception, and the tree locks. Reopening the run is the only way to edit it afterward.

## Build requirement fields

| Field                     | Notes                                                                                                                                                        |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Part Number / Rev**     | The required child part, shown with its revision.                                                                                                            |
| **Quantity**              | Count per one parent assembly. Multiplied by parent run quantity at execution.                                                                               |
| **Substitutes**           | Approved interchangeable parts for the line. See [Alternates and substitutes](/build-hardware/bills-of-materials/substitutes).                               |
| **Reference Designators** | Positional identifiers such as `R12` and `U7`. See [Reference designators](/build-hardware/bills-of-materials/reference-designators).                        |
| **Made on Assembly**      | Whether ION builds the child inside the parent's run instead of as its own run. See [Made on assembly](/build-hardware/bills-of-materials/made-on-assembly). |

Substitutes and reference designators are line metadata: you can edit substitutes without revising the whole mBOM, while adding or changing designators is a structural change. A reference designator is unique within its build requirement, and an approved substitute applies to every designator on the line.

## Divergence and versioning

The mBOM and aBOM carry independent version histories. A structural mBOM change (add or remove a line, change a part, change a designator, toggle MOA, or a significant quantity change) needs a new mBOM version; metadata changes such as notes and substitute edits are in-place. Releasing a new version archives the prior one, and only one version is **Released** at a time. In-flight runs keep the version they started against: to apply a structural change to a running build, use a [redline](/build-hardware/runs-and-execution/redlines-and-deviations) rather than a new version. For version states and the release flow, see [Manage BOM versions](/build-hardware/bills-of-materials/versions).

An mBOM version is distinct from a part revision. The revision tracks what the part is; the mBOM version tracks how to build a given revision. A new part revision usually implies a new mBOM, but an mBOM can also change on its own for routing or substitute updates.