Quality Control & Rework

Quality control is the optional sign-off step between building units and releasing them as finished stock. Every QC review records a per-unit dispositionDispositionA QC reviewer's verdict on a built unit: how many were approved, how many were failed, and an optional reason and category for the failure. One row per item per QC review, written when the operator finalises the review. Read more → — how many were approved, how many were failed — and Assemblified routes the consequences automatically.

On this page

• Running a QC review
• Failed units: rework or scrap
• Rework runs
• Output timing across the three build modes
• First-pass yield
• Quick Complete bypass

Running a QC review

After a build runBuild RunOne cycle of assembly inside a work order: pick the materials, build the units, then complete (or cancel, or reverse). A work order can have many build runs over its life — each one moves a defined quantity of inventory and writes a row to the audit ledger. Read more → reaches built, the Build runs card surfaces a Run QC review action on it. The dialog shows one row per item in the run with three inputs:

• Approved quantity — units that pass.
• Failed quantity — units that don’t.
• Failure reason + failure category — free-text and a category tag, both optional.

Approved + failed must total at most the run’s built quantity per item. You can save a review as draft and come back to it later, or save as completed and let the side-effects fire immediately. Once completed, a review is immutable — drafts are deletable, completed reviews are kept for audit.

Multiple reviews per run are allowed. Common pattern: do a first-pass review covering most of the run, save it completed, then do a second review later for any units that took longer to inspect.

Failed units: rework or scrap

A failed disposition creates a rework item in pending_rework. From there you have two paths:

• ReworkReworkRe-running failed units through a fresh build cycle to fix them. Rework runs don't consume new materials — the materials were already consumed in the original run. Once a rework run passes QC, the units land in finished stock. Read more → — start a rework build run that targets the failed units. Rework runs don’t consume new materials; the materials were already consumed in the original run. Once the rework run completes (and passes QC if you’re in Build & QC mode), the units land in finished stock.
• ScrapScrapMarking a failed unit as a terminal loss — it won't be reworked. Scrapping a unit from a non-deferred run also reverses the produced output, so the unit count in finished stock drops by one. Read more → — mark the rework item as scrapped. This is a terminal loss. If the original run was non-deferred (output had already been produced), scrapping also reverses one unit of produced output so finished stock stays consistent.

Both paths are operator-driven — Assemblified doesn’t auto-rework or auto-scrap. You decide based on whether the failure is fixable.

Rework runs

A rework run is a build run with runType='rework'. To start one:

1. Open the Rework items section on the build runs card.
2. Pick one or more pending_rework items.
3. Click Start rework run.
4. Pick a mode (any of the three execution modes — usually Build & QC, since you’re already running QC).

The rework run picks no fresh materials. It only goes through the build → complete (→ QC) cycle to produce the corrected units. If the rework run’s QC approves, the units land in finished stock. If it fails again, the cycle can repeat — Assemblified doesn’t limit retries.

Output timing across the three build modes

When does a finished unit actually land in pre-assembled inventoryPre-Assembled InventoryStock of finished sub-assemblies and BOM items that have already been built and are sitting on the shelf. When a work order needs a sub-assembly, it draws from pre-assembled inventory first and only builds fresh ones if the shelf comes up short. Read more → ? It depends on the mode the build run was started in.

Mode	When output lands
Pick (split)	When complete is called. Output lands immediately. QC, if run later, can scrap units (which reverses produced output).
Pick & complete	At the end of the one-shot action. Same scrap-reverses-produced logic if QC is run later.
Pick, complete & QC (Build & QC)	Deferred. Output is held until a QC review approves it. Approved units produce at QC-approval time; failed units never produce.

The deferred path is what makes Build & QC suitable for high-stakes builds — you get a QC sign-off before stock becomes available to other parts of the app.

Note

“Output deferred” is a flag on the build run set when it was started in Build & QC mode. Once set, it can’t be changed mid-run. If you started a run in the wrong mode, cancel or reverse it and start a new one.

First-pass yield

The Build runs card shows a first-pass yield figure per build run: how many units were approved on first try, divided by total built. It’s derived from the disposition data, not stored.

A 100% first-pass yield means no failures in the QC review. Anything below 100% had at least one failed unit; the breakdown shows how many ended up in rework vs. scrap.

Quick Complete bypass

Quick Complete (Pick & complete mode, no QC review ever run) is the path that bypasses QC entirely. It’s intentional and supported — not every build needs a QC step.

The mark-complete guards activate only when at least one QC review exists for the work order. So:

• Pick & complete with no QC reviews → mark-complete is allowed without QC sign-off.
• Pick & complete with at least one QC review → mark-complete enforces every QC guard (every built unit must have a disposition, no items in rework, every built run reviewed).

If you intend to use Quick Complete, don’t open a QC review on the work order. Once you do, you’ve opted in.

Related

• Build Runs — the cycle that produces the units QC reviews.
• End-to-end flows guide — the three modes walked through with QC included.
• Lifecycle — the QC guards on mark_complete.
• Glossary.