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 bill of materials (BOM) is the parts-list for a build. ION distinguishes two flavors:
  • Manufacturing BOM (mBOM) — the planned structure. Engineering’s intent for what should go into the assembly: parts, quantities, alternates, reference designators.
  • As-built BOM (aBOM) — the actual structure. The serial-and-lot-level record of what physically went in during run execution. Built up over time from build requirement installations.
The aBOM is the post-execution truth. The mBOM is the pre-execution plan. Reconciling the two — and capturing the deviations between them — is the core of ION’s traceability story. 
   Engineering         Manufacturing             Floor execution
   ─────────────       ────────────────          ──────────────────
   Design intent  ──▶  mBOM (planned)   ──run──▶  aBOM (actual)
                       Parts + quantities         Per-unit installations
                       + alternates               + serials/lots
                       + reference desigs         + redlines/deviations

​
What’s in this section

PageWhat it covers
Manufacturing BOM (mBOM)mBOM structure, line items, who maintains it
As-built BOM (aBOM)aBOM hierarchy, how it’s generated from runs, traceability queries
Editing Build RequirementsThe aBOM Part Manager modal — adding / removing parts mid-run
Alternates and SubstitutesConfigured alternates, scan-time substitution behavior
Reference DesignatorsPositional callouts (R12, U7) on a build requirement
Made on Assembly (MOA)Sub-assemblies built directly onto the parent, not as their own runs
BOM Versions and Change ManagementmBOM versioning, lifecycle states, change comparison

​
The mental model

Three concepts to keep straight:
  • Build requirement — a line item that says “to complete this assembly, install N of part X.” Build requirements live on an assembly’s BOM; operators install against them during a run.
  • Installation — a record linking a PartInventory (the unit installed) to the build requirement it satisfied. One install per unit.
  • Substitute — an interchangeable alternate part that can satisfy a build requirement. Substitutes are configured on the build requirement; operators can scan any approved substitute during install.
The mBOM defines build requirements at the part level. The aBOM holds installations at the part inventory level — the specific serial or lot that physically went into a parent assembly.

​
When to use mBOM vs aBOM concepts

You want to…Use
Plan what goes into a build before any units existmBOM
See what actually got installed in serial #ASM-00012aBOM
Add an alternate that any future build can usemBOM (configured substitute)
Swap a substitute for the primary on this specific buildaBOM (handled at install time)
Audit traceability for a delivered unitaBOM
Compare what was built vs what was speccedmBOM and aBOM, side by side

​
Tips

  • Don’t try to keep the mBOM and aBOM in lockstep. They diverge by design — that’s the deviation record. The mBOM is intent; the aBOM is reality.
  • Configure alternates upfront. Adding alternates to the mBOM before runs start lets operators handle supply substitution without filing a deviation. Adding alternates after the fact is a redline (per Redlines and Deviations).
  • Reference designators matter for quality. A position-coded build requirement makes “the wrong part went in slot R7” detectable; an unpositioned one makes it forensic-only.