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

A manufacturing BOM (mBOM) is the planned parts list for an assembly. It’s the structure engineering hands off to manufacturing: every part that should go in, how many, in what positions, and which alternates are acceptable. When a run starts against a part, ION uses the part’s mBOM to instantiate the run’s build requirements. That’s how the planned structure becomes execution intent.

​
mBOM line items

Each line on an mBOM is a build requirement — one parts-to-install requirement at a specific position in the assembly. Each line carries:
FieldNotes
PartThe required part. Optionally pinned to a specific revision
QuantityHow many of the part go in. Multiplied by the parent’s run quantity at execution time
Reference designatorsPositional identifiers (R12, U7, Q1) — see Reference Designators
SubstitutesApproved alternate parts — see Alternates and Substitutes
Made on Assembly (MOA)Whether this part is built directly onto the parent — see Made on Assembly
NotesFree-form instructions for the operator (orientation, torque spec, inspection points)

​
Creating an mBOM

  1. Open the parent part in the Parts catalog.
  2. Click mBOM in the part’s nav.
  3. For each child part:
    • Click Add line.
    • Pick the child part (and revision if needed).
    • Set quantity.
    • Optionally add reference designators, substitutes, MOA flag, notes.
  4. Save.
Parts can have multiple mBOM versions over their lifetime. ION captures version state explicitly — see BOM Versions and Change Management.

​
How runs consume the mBOM

When you start a run against a part inventory, ION:
  1. Reads the parent part’s released mBOM.
  2. Instantiates a build requirement on the run’s aBOM for each mBOM line.
  3. Locks the run to that mBOM revision — even if the mBOM is later edited, the in-flight run continues with the version it was started against.
Operators install against the run’s aBOM during execution. The aBOM is the per-unit, per-run record of what actually went in; the mBOM stays as the template.

​
Editing an mBOM

mBOM edits propagate forward but not backward:
  • New runs started after the edit pick up the new mBOM.
  • In-flight runs started before the edit continue with the old mBOM.
  • Completed runs’ aBOMs are unchanged — they’re a historical record of what was actually built.
If a mid-flight change is needed, that’s a redline on the specific run, not an mBOM edit.

​
mBOM vs eBOM (engineering BOM)

If your engineering team maintains an eBOM in a PLM system, the mBOM is the manufacturing-flavored version of it: same parts, organized for the floor instead of for design. ION’s mBOM lives in ION; if your eBOM lives elsewhere (Solidworks PDM, Arena, Teamcenter), keeping the two in sync is a separate workflow — typically a periodic export/import, or a custom integration that watches the eBOM.

​
Tips

  • Version mBOMs deliberately. A new revision is the right move when the design intent changes; in-place edits are for typos and clarifications.
  • Configure alternates at mBOM time. Having approved substitutes already on the line means operators can handle supply variation without filing a deviation per build.
  • Reference designators pay off in audits. Positionless build requirements make “wrong part in wrong slot” debuggable only by physical inspection.