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

Made on Assembly (MOA) is a flag on a build requirement that says “this child part is constructed directly onto the parent during the parent’s run, not as its own separate run.” The flag is structural: a part can be built as a standalone run and installed into a parent (the normal flow), or it can be built only inside the parent’s run (MOA flow). MOA changes how the work is sequenced and where the data lives, without losing the per-unit traceability the aBOM provides.

​
When to use MOA

Use MOA when:
  • The sub-assembly only ever exists in the context of its parent. There’s no scenario where you’d build it standalone and stock it.
  • The work is integrated into the parent’s procedure — operators don’t switch between two run UIs to build the parent and the sub-assembly.
  • The sub-assembly has a short build sequence (a few steps) that fits naturally within the parent’s procedure.
Don’t use MOA when:
  • The sub-assembly is batched separately ahead of the parent build.
  • The sub-assembly is stocked as inventory before being installed.
  • The sub-assembly’s build is complex enough to warrant its own run with its own sign-off and quality gates.

​
How MOA changes the workflow

AspectNormal sub-assemblyMOA sub-assembly
Run for the subSeparate run, completes independentlyNo separate run — sub is built within the parent’s run
Inventory pre-buildSub exists as a standalone PartInventory row before installSub is created during the parent’s build
Operator handoffOne operator finishes the sub, another installs itSame operator builds and installs in one flow
aBOM recordParent’s aBOM references the sub’s existing aBOMSub’s aBOM is created and rolled up into the parent’s aBOM during the parent’s run
SchedulingSub appears on its own scheduleSub is invisible to scheduling — its work lives within the parent’s run

​
Configuring MOA on a build requirement

From the mBOM editor on the build requirement:
  1. Toggle Made on Assembly on.
  2. Save.
The build requirement now executes via the MOA flow at run time.

​
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 “scan an existing sub” the operator gets a build flow that walks through the sub’s own procedure (or sub-sequence inside the parent’s procedure).
  3. As the operator completes the MOA build steps, ION:
    • Creates a new PartInventory for the sub (with serial / 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 gets simultaneously created and installed.

​
MOA and traceability

MOA preserves full traceability — both directions:
  • Top-down: parent’s aBOM → MOA sub’s aBOM → leaf installations. Same recursive tree as a normal sub-assembly.
  • Bottom-up: a leaf part inventory (e.g. 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 where the work happened in time and operator-space, not what the data records.

​
MOA and run batches

When the parent is part of a run batch, 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.

​
Tips

  • Don’t over-MOA. If a sub-assembly might eventually be batched separately or stocked, build it standalone. Switching from MOA to standalone after the fact is awkward — you’ve effectively reorganized your routing.
  • MOA simplifies kitting. 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.
  • Watch the operator load. A parent run with several deep MOA sub-assemblies can become a huge run for one operator. If the work splits naturally between operators, separate runs may be cleaner even if the sub doesn’t get stocked.