> For the complete documentation index, see [llms.txt](https://manual.firstresonance.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://manual.firstresonance.io/features/parts-and-trace/trace-aboms.md).

# As-built Bill of Materials (aBOM)

{% embed url="<https://www.loom.com/share/57c6458d50444bceb42c1a69b5b5c3c4?sid=3ab5c0c2-3cc9-4cc7-9078-9c28847a0a2d>" %}

### Overview

IONs aBOM is a powerful tool that allows you to keep track of which parts, down the serial or lot number, were used in higher-level assemblies, across multiple levels of assemblies. The aBOM is a living and real-time document, meaning that changes are reflected instantaneously as parts are installed or uninstalled.

An aBOM is a tree-like scaffolding that connects parent and children inventory. Each node is an inventory item (see: [Inventory](/features/parts-and-trace/inventory.md)), whether serial-tracked, lot-tracked, or untracked.

The aBOM can be accessed from either runs associated to the assembly, or from the inventory screen as seen below.

<figure><img src="/files/g9W6emqr2UmfLQfy2KrO" alt=""><figcaption></figcaption></figure>

### Why is it valuable

The aBOM is a massively valuable dataset within the factory. The traceability allows for:

* Finding all places that a component is installed if something goes wrong (i.e. containment for recalls)
* Understanding all data that was part of a build: runs, inventory, purchases, etc. This enables aggregations such as understanding the cost of the build or how long it took.

### Getting into the details

The aBOM follows the requirement and fulfillment model like other parts of ION (for instance, kits). Parent inventories have build requirements that define:

* which part is required (including potential substitutes)
* the minimum quantity required
* reference designators (optional)

Inventories get installed into build requirements via aBOM installations. The aBOM installation tracks:

* the inventory installed
* the quantity installed. The exception to this is when the build requirement quantity is set to 0. This allows the operator to install without setting the quantity and just select the trace information such as lot number.
* if it was installed into a specific reference designator

When an inventory is uninstalled, all of its children travel with it. This means that the data for the entire assembly moves with the inventory to match the physical reality.

<figure><img src="/files/4Exm9UKx8dxxIQOLKPu1" alt="" width="476"><figcaption><p>If the Build Requirement quantity is set to 0, a tool tip is displayed informing the operator that the quantity is optional</p></figcaption></figure>

### aBOM construction

You can install into the aBOM as seen in from the run execution screen. From here, you can start adding parts to your aBOM, and even use the "Install from Kit" button to install all the same lot numbers and serial numbers from the kit associated with the run. You can also add parts to the aBOM at the time of execution if needed.

<figure><img src="/files/93AtFOf3YJuaHUD0sEZx" alt=""><figcaption></figcaption></figure>

After installing your parts, the build aBOM changes to Build aBOM (100%) to show that you have installed all of the parts for the run. Build requirements that do not have a quantity greater than 0 do not count towards the final aBOM build percentage.

### Substitutes

On the aBOM, substitutes will appear with the "double arrow" icon shown below.

Here is how they will display within the aBOM interface:

1. The icon indicates that a substitute can be used to fulfill the requirement
2. Expanding the requirement will display the part numbers for the acceptable substitutes
3. When a substitute is installed, the icon will appear next to the installed part

<figure><img src="/files/EcoOFNSjaZWcfJ0ZsPBH" alt=""><figcaption></figcaption></figure>

### Visualizing aBOMs

Even while an aBOM is being constructed, you can visualize the parts that make up the part you are interested in by going to **Parts > Trace.** From here, you can search for a part, which will then load the in-progress or complete aBOM for that specific part. We support a tree view and an indented table view of the aBOM.

![The aBOM maintains a multi-level relationship across BOM items, including serial and lot numbers](/files/ytZUjanY0uXUtkA5OPrz)

<figure><img src="/files/xNYLQa0A8jlbyXigBeEX" alt=""><figcaption><p>The indented aBOM table shows inventory in white rows and build requirements in slate colored rows.</p></figcaption></figure>

### Modifying an aBOM

Simply create a new run for the *top-level assembly that you are affecting*. For example, if you are changing the engine controller on the following BOM:

* Vehicle
  * Engine
    * Engine controller

Create a run with the part number and serial number for the *engine*. Include a procedure with the instructions for changing the engine controller. This will allow the operator to remove the old engine controller and install a new one, by serial (or lot) number. The resulting aBOM will be updated for all levels up the vehicle's aBOM.

#### Permissions

Modifying the requirements of an aBOM has different permissions than installing/uninstalling.

Here is the mapping of permissions to those actions:

* Install a part -> `CreateABomInstallation` permission
* Uninstall/remove a part -> `DeleteABomInstallation` permission
* Update the aBOM requirements (build requirements) -> `Create/Update/DeleteBuildRequirement` permission

<figure><img src="/files/cC3uEoWJGJqv7ataNWgl" alt=""><figcaption></figcaption></figure>

### Uninstalling a part that is shared across lots

The behavior above — where children travel with an inventory on uninstall to match physical reality — describes a part that belongs to a single assembly. There is one case that behaves differently: a part that has become **shared** across multiple lots.

When a lot is split on a run (see [Split Inventory on a Run](/features/runs/split-inventory-on-a-run.md)), parts that were already installed before the split cannot be confidently assigned to one resulting lot or the other. ION keeps a single aBOM installation record and links it to every resulting lot, so the part shows as installed on all of the lots that share it. This preserves the original traceability without inventing quantities that were never there.

Because that one installation is shared, **uninstalling it removes it from every lot that shares it — not only the lot you are viewing.** The historical genealogy is not lost; rather, the change propagates to the sibling lots. ION flags this before you confirm:

* A **Shared with N lots** indicator appears on the build requirement.
* Before uninstalling, ION lists the lots that would be affected, grouped as **Direct siblings** (lots produced from the same split) and **Other related lots**.
* When you uninstall, the removal is held for about 10 seconds — a countdown lets you **Cancel** before it applies. If you don't cancel within that window, the part is removed from every lot that shares it.

{% hint style="info" %}
Installing into, or editing the quantity of, a shared build requirement is also reflected on every lot that shares it. Only **uninstall** asks you to confirm first, because it is the change most likely to affect a sibling lot you did not mean to touch.
{% endhint %}

Full per-lot divergence of a shared installation is a separate enhancement that is in progress. Until then, sharing is how ION keeps every lot's traceability accurate after a split.

### Sharing Installations Amongst Parent Assemblies

See [Split Inventory on a Run](/features/runs/split-inventory-on-a-run.md) for more details.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://manual.firstresonance.io/features/parts-and-trace/trace-aboms.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
