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

mBOMs change over their lifetime — engineering revs the design, manufacturing optimizes the routing, supply chain adds substitutes. ION tracks these changes through explicit mBOM versions so you can:
  • See what an mBOM looked like at any point in time.
  • Compare two versions side-by-side to understand a change.
  • Be sure that an in-flight run executes against the version it was started with — not whatever’s current.

​
When a new version is needed

ChangeAction
Add a new build requirementNew version
Remove a build requirementNew version
Change a part on an existing lineNew version
Change a quantityNew version (significant); in-place edit (clarification)
Add or remove a substituteIn-place edit
Add or change reference designatorsNew version
Toggle MOA on a lineNew version
Edit a note or instructionIn-place edit
In general: structural changes (what gets installed, where, how many) want a new version. Metadata changes (notes, alternates, clarifications) can be in-place edits.

​
Version states

mBOM versions move through:
StateMeaning
DraftEditable; not used by any new run
ReleasedLocked structure; new runs against the parent part instantiate from this version
ArchivedNo longer current; preserved for historical reference and in-flight runs that started against it
Only one version of an mBOM is Released at a time. Releasing a new version automatically archives the previously-released version.

​
Releasing a new version

  1. Open the mBOM in Draft state.
  2. Make the structural changes.
  3. Click Release.
  4. Confirm — ION presents the diff vs the previously-released version one more time.
  5. The new version becomes Released; the previous version moves to Archived.
Releases are recorded in the mBOM’s transaction history with the user, timestamp, and a release note.

​
In-flight runs

When you release a new mBOM version, in-flight runs are unaffected:
  • Each run captures the mBOM version it was started against at create time.
  • Mid-flight runs continue executing the old version even after the new one is released.
  • New runs started after the release pick up the new version.
  • The transition is handled per-run — there’s no “upgrade an existing run to the new mBOM” pattern. (If you genuinely need to apply a structural change to an in-flight run, that’s a redline.)

​
Comparing versions

To see what changed between two mBOM versions:
  1. Open the mBOM.
  2. Click Versions.
  3. Pick two versions to compare.
  4. ION renders a diff:
    • Lines added (in the newer version).
    • Lines removed.
    • Lines modified, with field-level deltas.
Use the diff during change-control reviews — it’s the same view you’d want when an engineer asks “what changed in revision 4?”

​
Programmatic comparison

For integrations or scripts, the Compare Two aBOM Versions query template can be adapted to compare mBOM versions instead. You fetch the line items for both versions and diff client-side.

​
Change-control patterns

Common patterns we’ve seen work well:
  • One ECN, one release. Group related changes from an Engineering Change Notice into one release rather than multiple incremental ones. Fewer versions, cleaner history.
  • Note the why in release notes. A 6-month-old release note that says “Updated R3 to 10kΩ per ECN-2026-0042” is far more useful than “minor updates.”
  • Hold draft changes until ready. Drafts that linger for weeks accumulate context drift. Release them or revert them.
  • Treat archived versions as immutable. Don’t edit archived versions, even for typo fixes. The historical record is part of the audit trail.

​
mBOM version vs part revision

These are related but distinct:
ConceptTracks
Part revisionThe design intent of the part itself (what it is)
mBOM versionThe plan for how to manufacture a specific part revision (how to build it)
A new part revision typically does mean a new mBOM (the new part is what’s being built), but mBOMs can also be revised independently — manufacturing improvements, substitute additions, routing changes — without revising the part.

​
Tips

  • Release deliberately. Each release affects every new run that starts against the parent part. A premature release can disrupt the floor.
  • Keep release notes short and specific. “Added FAST-M4 substitute, removed LBL-001 (now MOA in PCB sub)” is the right level of detail.
  • Archive aggressively. Old draft versions that won’t be released should be deleted, not left around. Archived versions are for released history, not abandoned work.