> ## 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 > How ION models a run: its steps, states and rollups, batches, and the as-built record it produces. 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](/build-hardware/procedures) 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](https://firstresonance.storylane.io/share/yjkyllpxnor6). 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-hardware/runs-and-execution/step-execution), 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](/build-hardware/runs-and-execution/starting-a-run). To work a step through fields, measurements, sign-offs, and failure paths, see [Run a step](/build-hardware/runs-and-execution/step-execution). Operators can also process a queue of open steps for one location; see [Run steps at a work center](/build-hardware/runs-and-execution/workcenter-execution). ## States Each run step carries a state. The run has no state of its own. Its status is derived from its steps. | State | What it means for a step | When the run shows it | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Todo** | No work done yet. Initial state on creation. | All steps `Todo`. | | **In Progress** | Started by a user, which records the run's start time on the first transition. A step can start only once its upstream dependencies are `Complete`. Leaving this state checks out anyone checked in. | Any step `In Progress`. | | **Hold** | Administrative pause that blocks work, shown in yellow. | Any step `Hold`. | | **Redline** | Editable and cannot be run, shown in light red. Takes precedence over `Hold`. See [Redline a run](/build-hardware/runs-and-execution/redlines-and-deviations). | Any step `Redline`. | | **Completed** | All required fields filled and all work done. | All steps `Completed`; the run reads `Complete` once the last required step signs off. | | **Failed** | A part or process found non-conforming, or a failed inspection, shown in dark red. Set it with **Fail Step** after the step starts, and move it back to `Todo` or `Redline` to rework. Creates an issue automatically if your org enables it. | Any step `Failed`. | | **Canceled** | Skipped work, shown in dark gray. Can move back to `Todo`. | All steps `Canceled`; a mix of `Complete` and `Canceled` rolls up as `Partial Complete`. | **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](/build-hardware/runs-and-execution/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](/build-hardware/runs-and-execution/scheduling). ## 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](/build-hardware/runs-and-execution/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](/build-hardware/runs-and-execution/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](/build-hardware/runs-and-execution/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](/build-hardware/runs-and-execution/redlines-and-deviations). ## 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](/build-hardware/runs-and-execution/completion-and-review). To pull a run's record out for analytics, see [Export run data](/build-hardware/runs-and-execution/export-runs-data). Your org can add **custom attributes** to runs for data the built-in fields don't cover. See [Manage run attributes](/build-hardware/runs-and-execution/attributes).