> ## 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.

# Run a step

> Run a step through fields, measurements, pass/fail, approval gates, sign-off, and the failure paths.

To run a step, open the run step, fill in the required fields, record measurements, attach evidence, and complete it. ION captures the result, propagates it to the relevant data downstream, such as analytics, traceability, and batched siblings, and unlocks the next run step. For the full set of step states and their transitions, see [Run and run step states](/build-hardware/runs-and-execution/overview#states).

## Check into a run step

On a **Todo** run step, click **Start / Check In** to move it to **In Progress** and begin capturing your labor time. While it's in progress, **Check In** and **Check Out** let you start and stop your own session. Completing, holding, failing, or redlining it checks you out. For how check-in and check-out sessions are recorded and edited, see [Time tracking](/build-hardware/runs-and-execution/time-tracking).

## Fill in fields

Each run step can have any number of fields defined on the procedure. Common field types:

* **Number**: a measurement, often paired with a validation (`min`, `max`, `target ± tolerance`).
* **Pass/Fail**: a single-select with two options, the simplest quality gate.
* **Text**: free-form notes or values that don't have a structured type.
* **Date**: when something happened, such as an inspection date.
* **Single-select / Multi-select**: pick one or many from a controlled list.
* **File**: attach an image, drawing, or document. For more information, see [File upload](/api-reference/file-upload).
* **Boolean**: yes or no.

Fields can be marked **required**. ION blocks run step completion if any required field is empty.

## Measurements and validation

When a numeric field has a validation (target, min, or max), ION evaluates your input as soon as you save the field:

* **In range**: the field shows green, and you can complete the run step.
* **Out of range**: the field shows red, and completion is blocked unless the run step's policy allows out-of-range values with an [issue](/track-quality/issues) attached.

Out-of-range measurements that the team accepts with a rationale become **deviations**. For more information, see [Redlines and deviations](/build-hardware/runs-and-execution/redlines-and-deviations).

## Build requirements (parts to install)

If the run step has build requirements, the parts to install onto the parent assembly during this run step, they render as a checklist below the fields. Each requirement shows:

* The part to install.
* The required quantity.
* Substitutes, if configured.
* The current install state, incomplete or complete.

You install a part by scanning its part inventory serial or lot, or by selecting from a picker. Your organization can require a barcode scan for installs. For more information, see [Require barcode scanning for installations](/administration/production-settings/require-barcode-scanning-for-installations). ION does the following:

* Validates that the scanned unit matches the required part or an approved substitute.
* Confirms the part inventory is in an installable state: **Available** and not consumed elsewhere.
* Records the install and links the part inventory to the parent's aBOM.
* Counts down the requirement's remaining quantity.

When all build requirements on a run step are satisfied or explicitly excepted, the run step is ready to complete.

## Sign-off fields

Approval gates are configured on the procedure as **sign-off fields**, an extra check before the run step can be completed. Common patterns:

* **Quality Engineer sign-off** on critical inspection steps.
* **Witness sign-off** on irreversible operations, such as fastener torque, sealing, and lid close.
* **Customer sign-off** for customer-witnessed builds.

Each sign-off field is tied to a role and shows **Expecting approval by:** that role. Only a member of that role can act on it, using **Approve** or **Reject**. A required sign-off field blocks completion until it's approved, the same as any other required field.

## Complete a run step

When fields are filled, build requirements installed, and any sign-off fields approved:

1. Check in to the run step, then click **Complete**.
2. ION records who completed the run step and when, checks you out, and updates the run step status to **Complete**.
3. The next run step, if any, becomes the active run step for the run.

If the **Complete** button is disabled, ION lists what's still outstanding (empty required fields, unapproved sign-offs, or uninstalled build requirements) so you can resolve it first. Completion is logged in the run's transaction history with the user and timestamp.

## Fail a run step

When you hit an outcome that can't be passed, open the run step's more-actions menu and:

1. Click **Fail Step**.
2. Provide a reason as free text, with an optional issue link.
3. The run step transitions to **Failed**.

A failed run step doesn't fail the run automatically. The run stays **In Progress**. Common follow-ups:

* **Rework**: fix the failure and re-run the run step. Depending on the procedure config, the run step can be reopened or a duplicate inserted.
* **Disposition via issue**: open an issue against the run step, capture the disposition (Use As Is, Rework, or Scrap), and let the issue lifecycle drive the next action. See [Issue states](/track-quality/issues/overview).
* **Fail the run**: if the failure can't be resolved at all, transition the run to **Failed**.

## Run step redlines

Mid-run, you can redline the procedure: add a run step, modify a run step's fields, or correct an instruction. This is core to how shop-floor reality diverges from the as-designed procedure. For more information, see [Redlines and deviations](/build-hardware/runs-and-execution/redlines-and-deviations).

<Tip>
  When a step needs to pause mid-execution (waiting on a part or on QE), drop a comment on the step so the next operator picks up where you left off.
</Tip>

## Related

* [Run and run step states](/build-hardware/runs-and-execution/overview#states)
* [Start a run](/build-hardware/runs-and-execution/starting-a-run)
* [Redline a run](/build-hardware/runs-and-execution/redlines-and-deviations)
* [Editing Build Requirements](/build-hardware/bills-of-materials/editing-build-requirements)
* [Issue States, Dispositions, and Resolutions](/track-quality/issues/overview)
* [Common Queries → Submit a Run Step Result](/api-reference/common-queries/submit-step-result)
