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

# Made on assembly (MOA)

> Sub-assemblies that get built directly onto the parent rather than as separate runs, including when to use MOA, how it changes the workflow, and how it preserves traceability.

**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](/build-hardware/bills-of-materials) for how the flag sits on the line. This page covers how MOA changes the workflow, how to configure it, and how it behaves at run time.

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

<Note>
  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](/build-hardware/bills-of-materials/editing-build-requirements).
</Note>

## 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](/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.

<Tip>
  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.
</Tip>

<Tip>
  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.
</Tip>

<Note>
  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.
</Note>

## Related

* [Bills of materials overview](/build-hardware/bills-of-materials)
* [Manufacturing BOM (mBOM)](/build-hardware/bills-of-materials/manufacturing-bom)
* [As-built BOM (aBOM)](/build-hardware/bills-of-materials/as-built-bom)
* [Edit build requirements](/build-hardware/bills-of-materials/editing-build-requirements)
* [Run and run step states](/build-hardware/runs-and-execution/overview#states)