NS work order lifecycle

The factory floor in nine beats

The NS work order lifecycle is what happens every time GFS produces an assembly — a Right Start Foods burrito kit, a Melt Mates meal kit, a USDA brown-box pancake run. It starts with a work order opening (either manually or because quantityavailable tripped a reorder point) and ends with finished goods showing up as allocatable inventory.

It exists because manufacturing is the one place where NS is genuinely the system of record — we don't second-guess the build transaction, we mirror it. But the cost rollup, the variance audit, and the BOM-update HITL gate live on our side. So nine phases: NS does six of them, we do three (component reservation mirror, variance audit, FG availability mirror).

The diagram lives at ns-work-order-lifecycle.html. Two phases are still STUB — labor capture autoflow and NS-native component reservation. Those gaps are honest; the recovery path is in Failure modes below.

Trigger conditions

• An assembly's quantityavailable drops below its reorder point — auto-WO opens.
• A sales order requires assembled stock that isn't on the shelf — production lead opens WO manually.
• USDA entitlement drawdown commits a build run — e.g. barrel cheddar processing.
• Operations forecasts a bid award and pre-builds inventory ahead of the QBL.
• R&D wants to validate a new BOM by running it once at small qty — pilot run.

WO #4821 — build 500 Right Start breakfast burritos

The nine phases

1. 01

   WO intake — manual or auto

   Either a production lead opens the work order in NS, or the reorder-point watcher fires when inventory_balance.quantityavailable drops below the assembly's reorder_point. The auto path emits a workorder.created event for downstream listeners.

   Writes workorder (NS), transactions (D1 mirror)

   Trigger manual or reorder-point
2. 02

   Component pull — BOM resolution + reservation

   The runner reads assembly_bom for the assembly, walks each line, and checks inventory_balance at the production location. Required qty is logged. STUB: NS-native component reservation is not wired — we read availability but don't lock the rows, so a parallel SO could theoretically grab the components first. In practice this rarely bites because production starts within minutes.

   Reads assembly_bom, inventory_balance

   STUB NS component reservation
3. 03

   Production start — status flips to 'In Progress'

   The floor lead releases the WO. NS transitions workorder.status='In Progress' and stamps start_timestamp. The D1 transactions row mirrors on the next 2-min hot sync.

   Writes workorder.status, start_ts

   Time mirrored ~2 min
4. 04

   Labor capture — hours × rate against the WO

   Time entries are booked against the work order. Hours roll up into actual_labor_cost at close. STUB: there is no scanner/kiosk autoflow — floor leads (Susan, Marcus) enter time manually through the NS UI on a laptop in the office. This is the single largest data-quality risk in the lifecycle; it works because we have one shift and two leads, but it won't scale.

   Writes NS time entries

   STUB labor capture autoflow
5. 05

   Component issue — debit inventory

   NS posts a workorderissue transaction. inventory_balance decrements per BOM line for the build qty. D1 mirrors with negative-qty rows in transaction_lines on the next hot sync.

   Writes workorderissue, inventory_balance--

   Mirror 2-min hot tier
6. 06

   Build complete — credit finished goods

   Production posts the build. NS records a build transaction; inventory_balance increments at the production location for the assembly item. The credit and the matching debits from step 5 are linked by the NS build transaction id.

   Writes NS build txn, inventory_balance++
7. 07

   WO close — status='Built', actual cost rollup

   NS flips workorder.status='Built' and rolls the actual cost: components from step 5, labor from step 4, allocated overhead. The rollup writes to the workorder header.

   Writes workorder.status='Built', actual_cost
8. 08

   Variance audit — HITL if >5% drift

   The platform compares actual_cost vs estimated_cost from the BOM. If abs(diff) / estimated > 0.05, a row is inserted into proposed_actions with action_type='bom_variance_review', risk_level 3. Mike sees the diff at /proposed-actions.html and decides: update the BOM (most common) or flag a production exception (e.g. a one-off scrap).

   HITL risk_level 3

   Writes proposed_actions
9. 09

   Finished goods — allocatable inventory

   inventory_balance.quantityavailable reflects the new build. Sales orders can now allocate against the SKU. The cost surface tile on the admin dashboard re-anchors with the new actual-cost data point. If Mike approved a BOM update in step 8, the new estimated cost is in effect for the next WO.

   Reads downstream: SO allocation, cost surface

   Mirror 2-min hot

What's different after the WO closes

• NS and D1 agree on FG quantity, component balances, and actual cost.
• If variance > 5%, a HITL card is in Mike's queue.
• If Mike updated the BOM, downstream cost rollups use the new value immediately.
• The build transaction is permanent — reversals require an assemblyunbuild.

What can go wrong

Adjacent flows + diagrams

Code paths + invariants