Overview

A run is one execution of a procedure against a specific part inventory. It binds three things that travel through the rest of the build: the procedure that defines the work, the part inventory the run produces or builds against, and the assignment of who does the work. The output is the as-built BOM (aBOM), the auditable record of what was built and what went into it. For a guided tour, see the interactive walkthrough. A run holds an ordered set of run steps, each instantiated from a procedure step with the same fields and validations. Operators work steps at a work center, capture readings, install parts, and sign off. The run does not carry its own start action: it moves to In Progress when the first step starts, and rolls its status up from its steps.

​

Run steps

A run step is the unit of floor work. Each has a header, typed fields, build requirements (parts to install onto the parent assembly), and action buttons. Steps render in procedure order, and dependencies between them gate which are available to work. To create a run and instantiate its steps, see Start a run. To work a step through fields, measurements, sign-offs, and failure paths, see Run a step. Operators can also process a queue of open steps for one location; see Run steps at a work center.

​

States

Each run step carries a state. The run has no state of its own. Its status is derived from its steps. Available to work is a separate calculation: a step is available when it is in Todo or In Progress, all upstream dependencies are Complete, and its parent step, if any, is In Progress. Canceling a step removes it from the dependency graph, which rewires so downstream steps are not blocked by skipped work. Batched runs rewire each run’s graph the same way. A run never moves backward through completed states on its own. Reopening a Complete run requires admin permission and is recorded in the run’s transaction history with the user, timestamp, and reason.

​

Batches

A run batch groups runs that share steps so a sign-off, redline, or state change on one step propagates to every sibling step across the batch. Only sibling steps propagate; a step unique to one run is unaffected. Part installs do not cascade automatically. Batch at creation to avoid divergence between batched and unbatched siblings, or manage membership later. See Manage run batches.

​

Scheduling

A run carries a scheduled start, scheduled end, and due date, and each step carries its own schedule and lead time. When step schedules are set but the run’s are not, the run takes the earliest start and latest end of its steps. The Timeline view on the Runs page plots every scheduled run. See Schedule a run.

​

Splitting inventory

When a subset of units on a run develops a problem, you split those units off onto an issue and into a separate location while the rest of the run continues. ION divides inventory by how far each unit has progressed: uninstalled parts allocate to each group independently, while already-installed parts link to both groups as shared until traceability resolves them. See Split inventory on a run.

​

Outside processing

A procedure step flagged as an outside process links to a purchase order so you can send the part and operation to a supplier and receive it back into the run. Outside-process steps are not batched. See Send a step to outside processing.

​

Time tracking

ION captures operator labor as check-in / check-out sessions on each step. Starting a step checks the operator in; completing, holding, redlining, or failing it checks them out. Operators cannot check into a step that is not available to work. Session data feeds cost and cycle-time analytics and can be edited. See Time tracking.

​

Redlines and deviations

A redline is an in-flight modification to the procedure made on one run: add a step, edit a field, correct an instruction, or build a procedure as you fly. It lives on the run, not the procedure template, so it keeps the audit trail intact and can be reviewed, approved, and merged back into the procedure or other runs. A deviation is an accepted out-of-range measurement recorded with a rationale. See Redline a run.

​

Completion and review

Completing a run reconciles its accumulated state into the records downstream consumers rely on. ION blocks completion until every required step is signed off, every required field has a value, every build requirement is installed or excepted, and every required approval gate is satisfied. On completion, ION locks all step records, updates the produced inventory’s state, and feeds the aBOM, traceability, and analytics. See Complete and review a run. To pull a run’s record out for analytics, see Export run data.