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

Step execution is the heart of run-time work. An operator opens a run step, fills in the required fields, records measurements, attaches evidence, and signs off. ION captures the result, propagates it to any relevant data downstream (analytics, traceability, batched siblings), and unlocks the next step. This page covers the step-execution surface from the operator’s perspective, including the failure paths.

Anatomy of a run step

A run step has four sections:
  • Header — step number, title, status badge, current operator (if checked in).
  • Fields — typed inputs (text, number, date, single-select, multi-select, boolean, file).
  • Build requirements — parts to be installed onto the parent assembly during this step (if applicable).
  • Sign-off — the action that transitions the step to complete.
The order is consistent across runs — steps render in the order they appear on the procedure.

Step status

Run step status uses the same four-state model as the run itself:
StatusMeaning
todoStep hasn’t been started
in_progressAn operator has checked in or is actively working on the step
failedThe step’s outcome was failure — captured but not signed off as a successful pass
completeThe step has been signed off; outcomes are locked unless the run is reopened
A step can move todo → in_progress → complete, or todo → in_progress → failed → complete (a failed-but-acknowledged step), or todo → failed directly if the operator catches a failure before any work happens.

Filling in fields

Each 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 (e.g. inspection date).
  • Single-select / Multi-select — pick one or many from a controlled list.
  • File — attach an image, drawing, or document. See File Upload for the API surface.
  • Boolean — yes/no.
Fields can be marked required. ION blocks step sign-off if any required field is empty.

Measurements and validation

When a numeric field has a validation (target / min / max), ION evaluates the operator’s input as soon as they save the field:
  • In range → field shows green, step can be signed off.
  • Out of range → field shows red, sign-off is blocked unless the step’s policy allows out-of-range with an Issue attached.
Out-of-range measurements that the team accepts (with rationale) become deviations — see Redlines and deviations.

Build requirements (parts to install)

If the step has build requirements — parts that need to be installed onto the parent assembly during this 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 / complete).
Operators install by scanning a part inventory’s serial or lot, or by selecting from a picker. ION:
  • Validates that the scanned unit matches the required part (or an approved substitute).
  • Confirms the part inventory is in an installable state (available, not consumed elsewhere).
  • Records the install — links the part inventory to the parent’s aBOM.
  • Counts down the requirement’s remaining quantity.
When all build requirements on a step are satisfied (or explicitly excepted), the step is ready for sign-off.

Approval gates

Steps can have approval gates configured on the procedure — an extra check before the step can move from in_progress to complete. Common patterns:
  • Quality Engineer sign-off on critical inspection steps.
  • Witness sign-off on irreversible operations (fastener torque, sealing, lid close).
  • Customer sign-off for customer-witnessed builds.
When a gate is required, the sign-off button shows the gate state (<approved>/<required>). The step won’t move to complete until the gate is satisfied.

Signing off a step

When fields are filled, build requirements installed, and any gates approved:
  1. Click Sign off.
  2. Confirm in the dialog.
  3. ION records completedAt, completedBy, and updates the step status to complete.
  4. The next step (if any) becomes the active step for the run.
Sign-off is logged in the run’s transaction history with the user and timestamp.

Failing a step

If the operator hits an outcome that can’t be passed:
  1. Click Fail step.
  2. Provide a reason (free text + optional Issue link).
  3. Step transitions to failed.
A failed step doesn’t fail the run automatically — the run stays in In Progress. Common follow-ups:
  • Rework — fix the failure and re-execute the step. Depending on procedure config, the step can be reopened or a duplicate inserted.
  • Disposition via Issue — open an Issue against the step, capture the disposition (Use As Is, Rework, Scrap), and let the issue lifecycle drive the next action. See Issue States.
  • Fail the run — if the failure can’t be resolved at all, transition the run to Failed.

Step-level redlines

Mid-run, the procedure can be redlined — adding a step, modifying a step’s fields, or correcting an instruction. This is core to how shop-floor reality diverges from the as-designed procedure. See Redlines and deviations for the full surface.

Tips

  • Fill the easy fields first. Operators sometimes hit a measurement that’s blocking and forget the easier fields — coming back to a step with a confusing partial state. Fill in the deterministic fields first, leave the measurement for last.
  • Don’t skip the sign-off dialog. It’s there to make sign-offs deliberate. Operators who reflexively click through lose the audit value.
  • Use the comments on a step for handoffs. When a step needs to pause mid-execution (waiting on a part, waiting on QE), drop a comment so the next operator picks up where you left off.