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 disposition — how many were approved, how many were failed — and Assemblified routes the consequences automatically.

QC is decided per build run, not per work order. A run you deliberately built without QC never waits for a review and never holds the work order up — even on a work order where other runs went through QC. You can still add a review to any completed run afterwards; it is offered, never required.

Where QC lives on the page

The Build runs & QC tab has two parts. The Build runs card on top is every run and what it moved. Underneath it, a Quality control section holds:

The reviews table — one row per review, with Review · Run · Result · Approved · Failed · Reviewed by · Reviewed. Result is a badge: Passed, Partly passed, Failed, or Voided when the run the review covered was later reversed. Its row menu offers Open review, which shows the saved review read-only.
The rework table — only present when something is waiting: one row per rework item, with Item · Quantity · Notes, and a per-row menu offering Start rework run and Scrap.

The reviews table’s empty state says it plainly: “Complete a build run, then record a quality review.”

Running a QC review

Every completed run that nobody has reviewed carries its own button on the Build runs table: Review when the run was built for QC and is waiting for one, Add QC when it was not. Either opens the review for that run — you never have to work out which run a review belongs to. The same review is offered from an item’s row on the Overview tab while exactly one unreviewed run holds that item’s units.

The Quality review dialog shows one row per item in the run:

Column	What it is
Item	What was built.
Built	How many units that run produced.
Approved	The one number you type. It cannot go above what was built, or below zero — either is refused on the cell.
Failed	Computed for you: built minus approved.

Because failed is derived, every unit the run built is always accounted for: “I reviewed 3 of the 5” cannot be recorded by accident.

As soon as anything fails, the dialog asks “N failed. What went wrong?” and offers two catalogue fields for the review as a whole:

Failure category — one per review. Pick from the catalogue, or type a new one and press Add to catalogue. A typed value that is not in the catalogue is refused: “That value is not in the catalogue yet. Choose one from the list or add it.”
Defect reason — several per review, added one at a time. Same catalogue rule, same Add to catalogue button.

Both catalogues are maintained in Settings → Work orders → Quality control — see work-order settings.

Under that, Reviewed by and free-text Notes. Press Record review and the review is written and its side effects fire immediately.

Adding QC to a run you already built

A run built without QC shows Add QC on its row for as long as nobody has reviewed it. Press it and the review works exactly as above: the units are already in finished stock, so approving changes nothing and failing takes the failed units back out again (see failed units).

This is the escape hatch for “we built it, then decided it needed checking” — you do not have to reverse the run and rebuild it in the other mode.

Completing a work order without QC

If you never open a review, nothing about QC stands between you and Complete work order. Once every item has reached its planned quantity and no run is still picking, the primary button at the top of the page becomes Complete work order and you press it. Send to QC stays available in the page’s More actions menu for when you do want the extra stage.

If you have used QC on this work order, the completion checks apply — but only to the runs that were actually under QC: every unit built by a QC run has to be dispositioned, no items may still be in rework, and no QC run may be left unreviewed. A run you built without QC alongside them is not part of that, and does not block completion.

Failed units: rework or scrap

A failed disposition creates a rework item, which appears as a row in the Quality control section’s rework table. From there you have two paths, both on that row’s ⋯ menu:

Start rework run — fires a rework build run that targets those failed units. Rework runs don’t consume new materials; the materials were already consumed in the original run. Once the rework run completes and its QC review approves, the units land in finished stock.
Scrap — a terminal loss, and it asks first: “Scrap this item? … cannot be recovered.” If the original run was one whose 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.

The counts land in two places you can read: the reviews table’s Approved and Failed columns, and — per item — the Status cell on the Overview tab’s Items card, whose disclosure breaks out how many units are in rework and how many were scrapped.

Rework runs

A rework run is a build run marked Rework in the Build runs table’s Mode column. Starting one is a single press of Start rework run on the rework row: there is no dialog and no mode to pick. Every rework run is fired as Pick, complete and send to QC, because you are already running QC on those units.

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 inventory? It depends on the mode the build run was started in.

Mode	When output lands
Pick only	When the run is completed. Output lands immediately. QC, if run later, can scrap units, which reverses produced output.
Pick and complete	At the end of the one-shot action. Same scrap-reverses-produced logic if QC is run later.
Pick, complete and send to QC	Deferred. Output is held until a QC review approves it. Approved units produce at QC-approval time; failed units never produce. The work order is not moved into Quality control automatically — the run itself is what waits.

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

Mixing QC and non-QC runs

You can use QC for some runs and not others on the same work order, and the two do not interfere:

A run built without QC is never waiting for anybody and never blocks completion, whatever else happened on the work order.
A run built for QC has to be answered for before the work order can complete.
Either can be reviewed later; only the first was ever expecting it.

The mode is fixed when the run starts. If you started one in the wrong mode, cancel or reverse it and start a new one — or just add QC to it afterwards.

Build Runs — the cycle that produces the units QC reviews.
Work-order settings — the failure categories and defect reasons the review picks from.
Work-order flows guide — the three modes walked through with QC included.
Lifecycle — the QC guards on completion.
Glossary.