NS work order — Path 2 · inventory build for stock

Inventory / production need identified → WO entered in NetSuite (no parent SO) → item / qty / location / components confirmed → component review → production → Assembly Build → FG added to inventory at correct location → components consumed → WO closes naturally → FG available for future SOs

Path 2 covers the case where the company builds product into inventory for future sales / sell-through. No parent SO. No customer side. No Finance handoff on the WO itself. Build reasons include reorder_point breach, sales forecast, bid pre-build (e.g. B5875 ahead of QBL), USDA drawdown commit (e.g. barrel cheddar processing), or R&D pilot run. WO is entered standalone (workorder.createdfrom = NULL), item / quantity / location / component requirements are confirmed, production runs, the Assembly Build record is entered in NetSuite (Mike approves at /assembly-build.html), FG is added to inventory at the correct location, components are consumed through the build process, and the WO closes naturally. The finished goods remain available for future Sales Orders — Finance enters then. Workflow: wo_lifecycle_inventory_build_path.

PATH 2 REAL no parent SO · no Finance handoff WO PO# field N/A (no customer PO# on inventory build; field still TBD globally)

Pipeline — Path 2 deep view (standalone WO · field-level)

idle
layers
WHAT THIS DOES: This is the path 2 inventory build · 20-node deep diagram — trigger detection → build reason classification (hitl) → need identified → classify origin → wo entered → confirm requirements → bom → component availability → capacity check → shortage escalation branch → production → assembly build (hitl) → variance audit → fg credited → components consumed → wo closes → fg aging tracker → reflexion + lane scoring → future so consumption preview → terminus step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: Path 2 inventory build · 20-node deep diagram &mdash; trigger detection → build reason classification (HITL) → need identified → classify origin → WO entered → confirm requirements → BOM → component availability → capacity check → shortage escalation branch → production → Assembly Build (HITL) → variance audit → FG credited → components consumed → WO closes → FG aging tracker → reflexion + lane scoring → future SO consumption preview → terminus 00 / Trigger detection · build reason classification (HITL) 01 / Inventory / production need identified · classify origin = inventory_build 02 / WO entered in NetSuite (createdfrom = NULL, standalone) 03 / Confirm requirements · BOM lookup · component availability 04 / Capacity check · shortage escalation branch · production 05 / Assembly Build in NetSuite (HITL) · variance audit (HITL if >5%) 06 / FG credited · components consumed · WO closes naturally 07 / FG aging tracker · reflexion + lane history scoring 08 / Future SO consumption preview · FG terminus WHAT THIS DOES: This is the trigger detection — what kicks off path 2. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: TRIGGER DETECTION — what kicks off Path 2. SOURCES reorder_point breach · inventory_balance.qty < items.reorder_point forecast dip · sales_forecast model · falling 30/60/90d coverage bid pre-build · bid_queue (e.g. B5875 QBL approaching) USDA drawdown · usda_drawdown_schedule · barrel cheddar processing R&D pilot · rd_pilots · new SKU pilot run WATCHERS reorder_watch cron (every 60 min · ns-coverage-flow) forecast_watch (daily) · bid_watch (hourly) · usda_watch (daily) · rd_watch (on-demand) OUTPUT candidate_build event with { item_code, target_qty, target_location, reason, urgency } STATUS: REAL · 4 of 5 watchers live (rd_watch STUB) trigger detection reorder_point · forecast · bid · USDA · R&D reorder_watch · forecast_watch · bid_watch usda_watch · rd_watch (STUB) emits candidate_build event EXTERNAL · 5 trigger sources i WHAT THIS DOES: This is the build reason classification — hitl operator confirms. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: BUILD REASON CLASSIFICATION — HITL operator confirms. ACTION Operator opens candidate_build event in queue. Confirms custbody_build_reason enum: 'reorder_point' · 'forecast' · 'bid_pre_build' · 'usda_drawdown' · 'rd_pilot' · 'other' HITL stage_proposed_action(action_type='wo_build_reason_classify', risk_level=2) Mike approves the classification before WO is entered in NS. WRITES (on approval) proposed_actions row → approved → custbody_build_reason set for downstream WO record SAMPLE reason = 'bid_pre_build' (B5875 QBL approaching) confirmed by operator STATUS: REAL · HITL gate ADR-031 build reason classification (HITL) operator confirms custbody_build_reason enum: reorder_point · forecast · bid_pre_build usda_drawdown · rd_pilot · other HITL: Mike approves at proposed_actions DECISION · HITL · ADR-031 i WHAT THIS DOES: This is the urgency + budget check. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: URGENCY + BUDGET CHECK. INPUTS reason enum, target_qty, target_location bid_queue (if reason = bid_pre_build): bid_quote_date, QBL date forecast_horizon (if reason = forecast): days_of_coverage COMPUTES urgency: critical | high | normal | low budget_approved: bool (from finance ceiling per build reason) WRITES candidate_build.urgency, candidate_build.budget_approved PURPOSE Drives scheduling priority + capacity check; blocks unapproved spend. STATUS: REAL urgency + budget check urgency: critical · high · normal · low budget_approved per build reason drives scheduling priority bid_pre_build → uses QBL date DATABASE · urgency assignment i WHAT THIS DOES: This is the inventory / production need identified. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: INVENTORY / PRODUCTION NEED IDENTIFIED. SAMPLE Right Start Foods burrito kit (RSF-BURR-KIT) on-hand = 0 reorder_point = 240 bid B5875 QBL approaches; pre-build qty 480 for stock at Heartland location REASONS reorder_point breach · forecast · bid pre-build · USDA drawdown · R&D pilot STATUS: REAL inventory / production need identified RSF-BURR-KIT on-hand = 0 · reorder = 240 build_reason = bid_pre_build (B5875 QBL upcoming) target build qty = 480 at location_id = 3 EXTERNAL · no parent SO i WHAT THIS DOES: This is the classify origin — operator identifies wo source. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: CLASSIFY ORIGIN — operator identifies WO source. LOGIC: origin = inventory_build (no parent SO) ACTION: dispatch wo_lifecycle_inventory_build_path STATUS: REAL (operator) · STUB (auto-classify) classify origin = inventory_build no parent SO (createdfrom NULL) dispatch wo_lifecycle_inventory_build_path build_reason = bid_pre_build SECURITY · classifier i WHAT THIS DOES: This is the work order entered in netsuite — standalone (no parent so). step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: WorkOrd TECHNICAL DETAILS: WORK ORDER ENTERED IN NETSUITE — standalone (no parent SO). NS RECORD: WorkOrd FIELDS WRITTEN bodyFields.tranid = "WO-4499" (NS-assigned) bodyFields.createdfrom = NULL (no parent SO — distinguishes Path 2 from Path 1) bodyFields.assemblyitem = "RSF-BURR-KIT" bodyFields.quantity = 480 bodyFields.location = 3 (Heartland) bodyFields.trandate = 2026-05-26 bodyFields.memo = "bid B5875 pre-build for QBL" (operator note, NOT customer PO# — no parent SO) bodyFields.custbody_build_reason = "bid_pre_build" (Path 2 only) THREADING NOTE No customer PO# threading on Path 2 — no parent SO means no SO.otherrefnum to inherit. Mike's TBD on WO.memo (Path 1 PO# threading) does not apply here; memo is freeform operator note. STATUS: REAL Work Order entered in NetSuite (standalone) tranid = "WO-4499" · createdfrom = NULL (no parent SO) assemblyitem = "RSF-BURR-KIT" · quantity = 480 · location = 3 memo = "bid B5875 pre-build for QBL" (operator note, not customer PO#) custbody_build_reason = "bid_pre_build" MESSAGEBUS · NS WorkOrd · STANDALONE i WHAT THIS DOES: This is the confirm requirements — mike's exact step. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: CONFIRM REQUIREMENTS — Mike's exact step. CHECKS item: RSF-BURR-KIT confirmed assembly_item quantity: 480 confirmed against build_reason capacity location: location_id = 3 (Heartland) confirmed component requirements: derived from assembly_bom STATUS: REAL confirm item / qty / location item = "RSF-BURR-KIT" · qty = 480 location = 3 · component reqs derived operator confirm step CLOUD · operator confirm i WHAT THIS DOES: This is the bom lookup. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: BOM LOOKUP. TABLES READ assembly_bom WHERE assembly_item = "RSF-BURR-KIT" SAMPLE COMPONENTS TORTILLA-LG qty 1 per kit; BEAN-1LB qty 1 per kit; SAUCE-PAC qty 1 total component consume for qty 480 = 1,440+ unit debits across components STATUS: REAL BOM lookup assembly_bom WHERE assembly_item = ? ~3-5 components per kit qty 480 → 1,440+ unit debits DATABASE · assembly_bom i WHAT THIS DOES: This is the component availability reviewed. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: COMPONENT AVAILABILITY REVIEWED. TABLES READ inventory_balance WHERE item_code IN (components) AND location_id = 3 DECISION if any component qty insufficient → stage purchase order request first (Path 2 can stage PO; no backorder customer pressure since no SO) STATUS: REAL component availability inventory_balance @ location_id = 3 TORTILLA-LG 600 · BEAN-1LB 510 SAUCE-PAC 720 · all OK for 480 DATABASE · component check i WHAT THIS DOES: This is the capacity check — production line + crew available? step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: CAPACITY CHECK — production line + crew available? INPUTS build_qty: 480 · build_reason · urgency production_schedule (capacity_calendar) crew_availability per shift per line CHECKS - target line (e.g. assembly_line_A) free during target window? - skilled crew available (kit_assembly cert)? - upstream material handling slot open? OUTCOME approved → proceed to production blocked → stage_proposed_action(action_type='build_schedule_slot') propose alt date or alt line · HITL approves SQL SELECT * FROM capacity_calendar WHERE line_id=? AND date BETWEEN ? AND ? STATUS: REAL · STUB (auto crew assignment) capacity check line · crew · schedule open? capacity_calendar lookup blocked → stage_proposed_action propose alt date or alt line DECISION · capacity gate i WHAT THIS DOES: This is the component shortage escalation — branch (only if bom unsatisfied). step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: COMPONENT SHORTAGE ESCALATION — branch (only if BOM unsatisfied). TRIGGER any component qty insufficient in component availability check (Stage 9) ACTION Stage emergency PO Path 2 (sequence with vendors) Hold build until receipt OR partial build if some components OK PAYLOAD shortage_components[] { item_code, shortfall_qty, target_location, urgency } HANDOFF → ns-purchase-order-path-2-inventory-replenish.html PO created with urgency flag vendor expedite + freight upgrade if urgency = high/critical NOTIFY procurement lead + Mike STATUS: REAL (handoff) · STUB (auto-expedite) shortage escalation (branch) IF any BOM component short → stage emergency PO Path 2 vendor expedite + freight upgrade hold build until receipt ISSUE BRANCH · shortage i WHAT THIS DOES: This is the production / assembly completed on floor. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: PRODUCTION / ASSEMBLY COMPLETED ON FLOOR. ACTION crew executes build for qty 480 components debited per BOM during build yield + waste captured (waste = 8 expected) NS RECORDS INTERIM: WkOrdIss per component D1 WRITES UPDATE inventory_balance SET quantityavailable -= bom.qty * 480 WHERE item_code IN (components) AND location_id = 3 SAMPLE DEBITS TORTILLA-LG -480 · BEAN-1LB -480 · SAUCE-PAC -480 STATUS: REAL production / assembly on floor crew executes build qty 480 · waste = 8 UPDATE inventory_balance -= bom.qty * 480 TORTILLA -480 · BEAN -480 · SAUCE -480 WkOrdIss posted per component MESSAGEBUS · floor i WHAT THIS DOES: This is the assembly build completed in netsuite — mike approves via hitl. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: AsmBuild TECHNICAL DETAILS: ASSEMBLY BUILD COMPLETED IN NETSUITE — Mike approves via HITL. NS RECORD: AsmBuild FIELDS WRITTEN bodyFields.tranid = "AB-1902" bodyFields.createdfrom = 4499 (WO id) bodyFields.assemblyitem = "RSF-BURR-KIT" bodyFields.quantity = 472 (480 target − 8 waste) bodyFields.custbody_waste = 8 bodyFields.location = 3 (Heartland) bodyFields.trandate = 2026-05-26 HITL: /assembly-build.html → proposed_actions → Mike approves STATUS: REAL Assembly Build entered in NetSuite (HITL) NS AsmBuild · tranid "AB-1902" · createdfrom = 4499 assemblyitem = "RSF-BURR-KIT" · quantity = 472 custbody_waste = 8 · location = 3 (Heartland) HITL: Mike approves at /assembly-build.html BACKEND · NS AsmBuild · HITL gate i WHAT THIS DOES: This is the variance audit — auto-trigger hitl when actual vs estimate exceeds threshold. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: VARIANCE AUDIT — auto-trigger HITL when actual vs estimate exceeds threshold. COMPUTE estimated_qty = WO.quantity (480) actual_qty = AsmBuild.quantity (472) variance_pct = |actual − estimated| / estimated = |472 - 480| / 480 = 1.67% THRESHOLD variance_pct > 5% → HITL variance review required variance_pct <= 5% → pass automatically EXAMPLE 1.67% (current sample) → auto-pass 9% (hypothetical bad day) → stage_proposed_action(action_type='build_variance_review') ALSO TRACKS cost_variance: estimated_cost vs actual cost (labor + components + overhead) WRITES build_history.variance_pct, build_history.variance_status STATUS: REAL · variance audit HITL gate variance audit |actual − estimated| / estimated 472 vs 480 = 1.67% (auto-pass) threshold > 5% → HITL variance review also tracks cost_variance DECISION · 5% threshold · HITL i WHAT THIS DOES: This is the fg added to inventory at correct location — mike's exact phrasing. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: FG ADDED TO INVENTORY AT CORRECT LOCATION — Mike's exact phrasing. SQL UPDATE inventory_balance SET quantityavailable = quantityavailable + 472 WHERE item_code = "RSF-BURR-KIT" AND location_id = 3 STATUS: REAL FG added to inventory UPDATE inventory_balance SET quantityavailable += 472 item = RSF-BURR-KIT @ loc 3 on-hand: 0 → 472 DATABASE · FG ++ i WHAT THIS DOES: This is the components consumed through build process — mike's exact phrasing. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: COMPONENTS CONSUMED THROUGH BUILD PROCESS — Mike's exact phrasing. ACTION formal component consumption posted (WkOrdIss) per component net inventory effect: -components, +FG TABLES write: transactions (WkOrdIss) · inventory_balance STATUS: REAL components consumed WkOrdIss per component net inventory: -components, +FG at location_id = 3 BACKEND · consume i WHAT THIS DOES: This is the wo closes naturally — mike's exact phrasing. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: WO CLOSES NATURALLY — Mike's exact phrasing. SQL UPDATE work_orders SET status = 'Built' WHERE id = 4499 EVENT: workorder.built NO customer side — no Item Fulfillment, no Finance handoff. STATUS: REAL WO closes naturally UPDATE work_orders SET status = 'Built' WHERE id = 4499 event: workorder.built no Item Fulfillment · no Finance handoff BACKEND · WO close natural i WHAT THIS DOES: This is the fg aging tracker — this build's fg enters aging tracker. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: FG AGING TRACKER — this build's FG enters aging tracker. WRITE INSERT INTO fg_aging (item_code, location_id, lot_id, build_date, qty_initial, qty_remaining) VALUES ('RSF-BURR-KIT', 3, ?, '2026-05-26', 472, 472) PURPOSE Tracks how long FG sits before allocation to a future SO. Drives FIFO allocation policy on SO Path 1 (oldest lot first). SURFACES /inventory/aging.html · item entity page aging widget ALERTS if qty_remaining > 0 AND build_date older than item.shelf_life_days * 0.75 → stage_proposed_action(action_type='fg_aging_warning') if older than shelf_life_days → blocked from new allocations STATUS: REAL (table + insert) · STUB (aging alerts UI) FG aging tracker INSERT INTO fg_aging (item, location, build_date, qty) drives FIFO allocation on SO Path 1 surfaces on item entity page aging widget alerts at 75% shelf life → block at expiry BACKEND · fg_aging insert i WHAT THIS DOES: This is the reflexion + lane history scoring — close the substrate loop. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: REFLEXION + LANE HISTORY SCORING — close the substrate loop. ACTION reflexion_writer.write({ workflow_type: 'wo_lifecycle_inventory_build_path', item_code, build_reason, target_qty, actual_qty, variance_pct, waste_qty, waste_pct, lead_time_days, cost_actual, build_success }) WRITES build_history (scoreboard for this item × line × crew) reflexion_log (workflow reflection) EFFECT Feeds future capacity_check + variance_audit predictions for this assembly_item. build_success scores update lane confidence (used in trigger_detection urgency rank). waste_pct trend influences future target_qty calculation (build buffer). LANE HISTORY same lane (item × line × crew) accumulates history for next build STATUS: REAL · reflexion writer live reflexion + lane history scoring writes build_history scoreboard variance · waste · lead_time · build_success feeds next capacity_check + variance prediction influences future target_qty (waste buffer) SECURITY · reflexion writer · closed loop i WHAT THIS DOES: This is the future so consumption preview · path 2 terminus — how so path 1 will eventually allocate this fg. step. It happens as part of the work-order / order-integration chain and produces the data, status change, or record described below. NS RECORD: see TECHNICAL DETAILS TECHNICAL DETAILS: FUTURE SO CONSUMPTION PREVIEW · PATH 2 TERMINUS — how SO Path 1 will eventually allocate this FG. PREVIEW next bid_release_order on B5875 will allocate from this lot predicted_consumers JSON (forward simulation): [{ "future_so": "expected B5875 release Q3-2026", "qty": 240, "lot_id": ? }, { "future_so": "stock for general fill", "qty": 232 }] SURFACES bid-command-center · item entity page · /inventory/preview.html get_assembly_inventory chat tool (now lists this lot as available) EVENT inventory.fg_credited (RSF-BURR-KIT, location 3, +472, lot_id=?) TERMINUS Path 2 ends here. Finance enters LATER when a future SO sells this FG. No Item Fulfillment · no invoice · no Finance handoff on the WO itself. Customer PO# threading does NOT apply on Path 2 (no parent SO). NOTE When the future SO consumes the FG, it follows ns-sales-order-path-1-inventory.html (allocation from inventory). STATUS: REAL future SO consumption preview · PATH 2 terminus predicted_consumers: B5875 release Q3-2026 (qty 240) · stock fill (qty 232) surfaces: bid-command-center · item entity · get_assembly_inventory tool event: inventory.fg_credited (RSF-BURR-KIT, loc 3, +472) Path 2 ends here · Finance enters via future SO Path 1 DATABASE · PATH 2 TERMINUS · future SO Path 1 takes over i key flow key flow step step step step step step step step step step step step step step step step step step step step step step step LEGEND Path 2 inventory-build lanes HITL gate lane reflexion / scoring lane decision gate issue / shortage branch branch arrow (dashed) no parent SO · no customer side · no Finance handoff on the WO · 20 nodes · 4 HITL gates (build reason, AsmBuild, variance, shortage)
Legend · color codes + icons used in this diagram
Color codes:
backend / NS record
work order / SO link
finance / invoice
TBD / escalation
cloud / worker
external / generic
Icon meanings:

NS records created / updated · field-level detail (Path 2)

StepNS recordFieldSample valueStatus
3WorkOrdbodyFields.tranid"WO-4499"REAL
3WorkOrdbodyFields.createdfromNULL (distinguishes Path 2 from Path 1)REAL
3WorkOrdbodyFields.assemblyitem"RSF-BURR-KIT"REAL
3WorkOrdbodyFields.quantity480REAL
3WorkOrdbodyFields.location3 (Heartland)REAL
3WorkOrdbodyFields.memo — operator note (NOT customer PO# — no parent SO)"bid B5875 pre-build for QBL" · field still TBD globally pending Mike reviewTBD — Mike review pending (semantic: memo carries operator note on Path 2; on Path 1 expected to carry customer PO#)
3WorkOrdbodyFields.custbody_build_reason"bid_pre_build"REAL
7(WkOrdIss)per component consumeTORTILLA-LG -480 · BEAN-1LB -480 · SAUCE-PAC -480REAL
8AsmBuildbodyFields.tranid"AB-1902"REAL
8AsmBuildbodyFields.createdfrom4499 (WO id)REAL
8AsmBuildbodyFields.item"RSF-BURR-KIT"REAL
8AsmBuildbodyFields.quantity472REAL
8AsmBuildbodyFields.custbody_waste8REAL
8AsmBuildbodyFields.location3 (Heartland)REAL
9(none)inventory_balance.quantityavailable += 472D1 UPDATE for FG at location_id = 3REAL
10(WkOrdIss)formal component consumption postedper componentREAL
11WorkOrdbodyFields.status"Built"REAL
11(event)events.event_type"workorder.built"REAL
12(none)FG allocatable to future SOsinventory_balance row remains until consumed by future SOREAL

Customer PO# threading on Path 2 (none — no parent SO)

Path 2 has no customer PO# threading because there is no parent SO. The WO is standalone (workorder.createdfrom = NULL). Mike's notes confirm PO# threading on SO/PO/Invoice/Vendor Bill chains — Path 2 is the only chain where this does not apply.

Schema-layer TBD reminder: The WO.memo field is still TBD globally pending Mike's review of the Path 1 customer PO# threading. On Path 2 the field is freeform (no PO# semantic), so the TBD does not block this path's flow — but every WO Schema reference is marked TBD until confirmed.

Sub-contract structured detail

CTR wo_lifecycle_inventory_build_path · risk 2 REAL

Sub-contract dispatched from the WO master when origin = inventory_build. Standalone WO — no parent SO, no Item Fulfillment, no Finance handoff on the WO itself. Finance enters later when the FG is sold via a future SO. Path 2 terminates at WO close; FG remains available for future Sales Orders.
Fan-out targets
create_wo · confirm_requirements · review_components · bom_consume · assembly_build · finished_goods_credit · close_wo
Tables touched
work_orders · assembly_bom · assembly_builds · inventory_balance · transactions · events · proposed_actions
HITL gates
/assembly-build.htmlproposed_actions → Mike approves
Verify checks
wo_standalone (createdfrom IS NULL) · assembly_build_posted · fg_credited · components_debited · wo_closed · fg_available_for_future_so
No customer side
no Item Fulfillment · no Finance alert · no invoice · no payment · no order.closed event
Build reasons
reorder_point · forecast · bid_pre_build · usda_drawdown · rd_pilot · other
Retry policy
max_attempts=3 · exponential backoff (1.5s base, 45s cap) · alert_on_final_failure