> ## 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. ## The Runs page The **Runs** page lists your runs and is the entry point to everything below. A toggle in the header switches between two views: **Table**, the default sortable and filterable list, and **Timeline**, which plots every scheduled run (see [Schedule a run](/build-hardware/runs-and-execution/scheduling)). Shortcut cards above the table filter it to **My Runs** or **Overdue Runs**, jump you to a **Workcenter** queue, or open **Create Run**. The timer button in the header carries a count of your open check-ins and opens **My Active Check-ins**, so you can review or close them from one place (see [Time tracking](/build-hardware/runs-and-execution/time-tracking)). The table's search box, with the placeholder `Search run #, title, batch, part #, procedure...`, matches a substring against the run's number, title, and description, its batch's number and title, the part's number, description, and revision, the procedure's number and title, and the run's labels. A run matching in any one of those is returned. The **Due Date** column counts down instead of showing a calendar date, in the two largest units that apply: **Due in 3 days 5 hours** while the run is in flight, **Overdue by 2 days** once the date has passed, and **Due now** or **Overdue** when less than a minute separates the two. A run near its date or past it is colored to flag urgency, an on-track run stays muted, and a run that has settled shows the plain date. The control in the column header switches the whole column between the countdown and the exact date, and the urgency color carries over either way. Hovering a cell shows the other form: the exact date and time in your org's date format when the column shows the countdown, and the countdown when it shows the date. Selecting runs in the table reveals a toolbar of bulk actions: * **Batch** and **Unbatch** group or ungroup the selected runs. See [Manage run batches](/build-hardware/runs-and-execution/run-batches). * **Export** downloads the selected runs as a CSV. See [Export run data](/build-hardware/runs-and-execution/export-runs-data). * **Print Barcodes** opens a menu offering **Run labels** for every selected run and **Part inventory labels (N)** for the selected runs that have a part inventory. See [Print labels](/build-hardware/labels-and-scanning/printing). * **Archive** removes the selected runs from the main list. * **Cancel** cancels the selected runs and their steps. Runs that are already complete or canceled are skipped. ## 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 [Create 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). A run opens into three tabs: **Overview**, **Steps**, and **Dependencies**. The **Dependencies** tab shows the run's step dependency graph, the same view the [dependency manager](/build-hardware/procedures/procedure-dependency-manager) uses on a procedure. On a run, changing dependencies is a redline: both steps must be in `Redline` to draw a link between them. See [Redline a run](/build-hardware/runs-and-execution/redlines-and-deviations). ## 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`. | | **Complete** | All required fields filled and all work done. | All steps `Complete`; 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). ## Labels Labels are shared tags you apply across ION to group related records. For creating and deleting labels in the shared library, see [Labels](/administration/labels). To label a run, click **Labels** in the run header, then type in the **Search or create labels...** box and select a label. To create a new label, type its name and select the create option. ## 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).