Complete and review a run - ION Manual

The completion review

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

Justify uninstalled aBOM parts

When your organization requires it, completing a run (or a run step) whose aBOM has parts that aren’t fully installed prompts you to justify finishing anyway. ION opens the Complete with Uninstalled aBOM Parts dialog, which lists each under-installed part with its installed-versus-required quantity.

1. Read the list of parts that aren’t fully installed.
2. In the Justification field, explain why it’s acceptable to complete the run with those parts uninstalled. The field is required.
3. Click Complete Anyway to record the justification and continue, or Go Back to return without completing.

ION records the justification, along with who entered it and when, on 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. 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.

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.
• 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. For how run timestamps are set, see Run and run step states.

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.