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

# Complete and review a run

> Move a run to complete, run the data-review checklist, close open redlines and issues, and produce the records downstream consumers will need.

The completion review reconciles the run's accumulated state, such as step results, measurements, attachments, build requirements installed, redlines applied, and issues filed, into the records that downstream consumers such as auditors, customers, and planners rely on. For how completion fits the run lifecycle, see the [Overview](/build-hardware/runs-and-execution/overview). This page covers the completion checklist, the review surfaces, and what happens to the run's data after completion.

## Prerequisites for completion

ION enforces these structural prerequisites:

* Every required step is signed off.
* Every required field on every required step has a value.
* Every build requirement is installed, or excepted through an issue.
* Every required approval gate is satisfied.

If any of those isn't met, the **Complete run** button is disabled and ION shows what's blocking it.

There are also organizational prerequisites that ION can warn on but doesn't always block:

* Open issues filed against the run. Disposition these before completion in most workflows.
* Open redlines. Accept or reject these before the run's record is locked.
* Out-of-range measurements without an issue. These usually require either an issue and disposition or a deliberate deviation acknowledgement.

## The completion review

When prerequisites are met:

1. Open the run.
2. Click **Complete run**.
3. Review the checklist in the **completion review** dialog:
   * **Steps**: count of steps completed, and any steps that failed and were then resolved.
   * **Build requirements**: every required part installed, and any exceptions.
   * **Redlines**: count of open versus closed redlines, with a warning if any are still open.
   * **Issues**: open, dispositioned, and resolved counts.
   * **Approvals**: every required gate satisfied.
4. Optional: add a free-text completion note.
5. Confirm.

ION then:

* Records who completed the run and when.
* Transitions the run to **Complete**.
* Updates the target inventory's state to reflect the build outcome, typically **available** for the produced unit.
* Closes any run-level approval gates.
* Locks all step records. No further edits are possible without reopening the run.

## Review run data after completion

A completed run is the canonical record of what was built. The review surfaces are described below.

### Run summary

The top of the run page shows headline stats:

* Steps completed.
* Cycle time, from start to completion.
* Operators involved.
* Issues opened during the run, with dispositions.
* Redlines applied.
* Build requirements installed, with counts and parts.

### Step-by-step view

Scroll the steps in their execution order. Each step shows:

* The operator who signed off, with a timestamp.
* Field values and measurement evidence, in-range or out-of-range.
* Files attached.
* Build requirement installs, including which units went where, with serials and lots.
* Comments.

### Transaction history

The transaction history is the audit trail. It surfaces every change to the run: status transitions, sign-offs, redline applications, issue links, and approvals.

### Part Installs (aBOM)

The completed aBOM is the parent and child tree of inventory records that compose the finished assembly. Open it from the run with the **Part Installs (aBOM)** tool. For the structure, see [Edit build requirements](/build-hardware/bills-of-materials/editing-build-requirements). The aBOM is the input to traceability reports and downstream service and repair workflows.

## Reopen a run

You can reopen a run after completion to fix data, add a missed sign-off, or adjust an installed build requirement that was incorrect. Reopening requires admin permission and is recorded in the transaction history. For the reopening rules, see [Run and run step states](/build-hardware/runs-and-execution/overview#states).

## What downstream systems get

After a run completes, several downstream surfaces consume its data:

* **Inventory**: the produced unit's state updates, and consumed inputs are marked accordingly.
* **Traceability reports**: the aBOM is part of the genealogy of the produced unit.
* **Analytics**: cycle time, step times, issue rates, and scrap rates aggregate into dashboards.
* **External integrations**: webhooks fire on run completion for ETL pipelines, ERP sync, and customer notification systems. See [Webhooks](/api-reference/webhooks).
* **Customer documentation**: for customer-witnessed builds, the run record is the source for end-of-line reports.

## Cycle time analytics

Run cycle time, from start to completion, and per-step times propagate to dashboards under [Analytics and dashboards](/automate-with-ion/analytics-and-dashboards). For how run timestamps are set, see [Run and run step states](/build-hardware/runs-and-execution/overview#states).

<Tip>
  If you have an ETL or ERP that depends on a run's data, set up a webhook on run completion rather than polling. See [Webhooks](/api-reference/webhooks).
</Tip>

## Related

* [Run and run step states](/build-hardware/runs-and-execution/overview#states)
* [Execute a run step](/build-hardware/runs-and-execution/step-execution)
* [Redline a run](/build-hardware/runs-and-execution/redlines-and-deviations)
* [Edit build requirements](/build-hardware/bills-of-materials/editing-build-requirements)
* [Webhooks](/api-reference/webhooks)
* [Analytics and dashboards](/automate-with-ion/analytics-and-dashboards)