## Made on Assembly (MOA)

**Made on Assembly (MOA)** is a flag on a build requirement that marks a child part as constructed directly onto the parent during the parent’s run, rather than as its own separate run. See [Bills of materials overview](https://docs.firstresonance.io/build-hardware/bills-of-materials) for how the flag sits on the line.

## How MOA changes the workflow

| Aspect | Normal sub-assembly | MOA sub-assembly |
| --- | --- | --- |
| **Run for the sub** | Separate run, completes independently | No separate run; the sub is built within the parent’s run |
| **Inventory pre-build** | Sub exists as a standalone `PartInventory` row before install | Sub is created during the parent’s build |
| **Operator handoff** | One operator finishes the sub, another installs it | Same operator builds and installs in one flow |
| **aBOM record** | Parent’s aBOM references the sub’s existing aBOM | Sub’s aBOM is created and rolled up into the parent’s aBOM during the parent’s run |
| **Scheduling** | Sub appears on its own schedule | Sub doesn’t appear in scheduling; its work lives within the parent’s run |

## Configuring MOA on a build requirement

From the **mBOM** card on the part page, with the version in **Draft**:

1. Find the build requirement’s row.
2. Select the **Made on Assembly** checkbox in that row. The change saves automatically.

The build requirement now executes via the MOA flow at run time.

You can also flag a part as MOA when adding it to an aBOM: turn on the **Add as MOA** switch before selecting the part in Edit Mode. See [Edit build requirements](https://docs.firstresonance.io/build-hardware/bills-of-materials/editing-build-requirements).

## How operators install MOA build requirements

During the parent’s run:

1. The MOA build requirement renders inline with the parent’s other build requirements.
2. Instead of scanning an existing sub, the operator gets a **build flow** that walks through the sub’s own procedure, or a sub-sequence inside the parent’s procedure.
3. As the operator completes the MOA build steps, ION does the following:
   - Creates a new `PartInventory` for the sub, with a serial or lot depending on the sub part’s tracking type.
   - Creates the sub’s aBOM as a child of the parent’s aBOM.
   - Records installations against the sub’s build requirements as the operator works.
4. When the MOA sequence is complete, the sub is installed into the parent in a single atomic act: the new sub-assembly is created and installed at the same time.

## MOA and traceability

MOA preserves full traceability in both directions:

- **Top-down**: the parent’s aBOM leads to the MOA sub’s aBOM, then to the leaf installations. This is the same recursive tree as a normal sub-assembly.
- **Bottom-up**: a leaf part inventory, such as a fastener, installed in an MOA sub still has a `parentPartInventory` chain that walks up through the MOA sub to the top-level parent.

The only difference is when the work happened and which operator did it, not what the data records.

## MOA and Autoplan

In Autoplan, MOA components surface as `Placeholder` items in the plan. Placeholders represent the hierarchy of the BOM but **can’t be converted into runs or purchases directly**. The parent’s run produces them as a side effect of the parent build. Treat them as informational rows in plan output, not as actionable demand.

## MOA and run batches

When the parent is part of a [run batch](https://docs.firstresonance.io/build-hardware/runs-and-execution/run-batches), MOA build requirements:

- Render once per batched run, one MOA build per parent unit.
- Don’t propagate as redlines across siblings the way step-level changes do. Each MOA build is its own piece of work even within a batch.
- Still inherit the batch’s procedure version and shared-step sign-off behavior for any non-MOA steps.

If a sub-assembly might eventually be batched separately or stocked, build it standalone. Switching from MOA to standalone after the fact reorganizes your routing.

When sub-assemblies are MOA, you don’t need to kit them separately ahead of the parent build. The components flow into the parent’s kit.

A parent run with several deep MOA sub-assemblies can become a large run for one operator. If the work splits naturally between operators, separate runs can be cleaner even if the sub doesn’t get stocked.

## Troubleshooting

A sub-assembly's installs are missing after the run

An MOA sub-assembly’s inventory, its aBOM, and its installations are created only as the operator completes the MOA build flow during the parent’s run. **Cause:** The MOA build flow wasn’t completed. The sub exists only once its build steps are done. **Fix:** Complete the remaining MOA build steps on the parent’s run. **Cause:** **Made on Assembly** was turned on after the run was created. A run builds against the mBOM version it was created from, so the line runs as a normal sub-assembly that expects an existing sub to install. **Fix:** Set **Made on Assembly** on the mBOM before you create the run. Changing it on an in-progress run doesn’t convert installs that already exist.

A made-on-assembly part has no manual install option

**Cause:** MOA sub-assemblies are created and installed by the parent’s build flow, not through a manual install, so no manual install control appears for them. **Fix:** Complete the MOA build flow on the parent’s run to create and install the sub.