Item record review + push-back · risk 3 (Part 1 of 2)

Manually invoked from /item/<code> review page OR fired by data-quality watchdog when an item field drift is detected.

01 / Trigger 02 / Context + preconditions 03 / HITL gate (Mike approves) 04 / Fan-out (Part 1 of 2) 05 / Post actions (log_run + reflexion + events) 06 / Verify (SQL / R2 / HTTP checks) How this workflow gets kicked off. Could be a chat-tool invocation, a cron tick, an inbound event (e.g. price.changed), or Mike clicking 'execute' from an admin page. TRIGGER kind: ? glob: data_quality.item_flagged invoker: Mike (single-admin) risk_level: 3i Trigger manual_or_event risk 3 Before deciding anything, pull related data from D1 (the local mirror of NetSuite). Each query loads a slice of the entity's current state so the AI and Mike can review before any writes happen. LOAD CONTEXT (D1 queries before fan-out) current_item: SELECT id, itemid, displayname, salesdescription, custitem_brand, custitem_pack… current_spec: SELECT spec_id, brand, item_name, pack_size, claims_json, nutritionals_json, al… pricing_master_row: SELECT customer_name, case_price, cost_basis, school_year, status, last_updated… vendor_costs: SELECT vendor_name, vendor_item_code, unit_cost, effective_start, effective_end… assembly_memberships: SELECT a.id, a.item_code AS assembly_code, a.description FROM assemblies a JOIN… open_bid_lines: SELECT bid_id, customer_name, proposed_price FROM bid_lines WHERE UPPER(item_co… recent_transactions: SELECT COUNT(*) AS so_count_30d FROM so_lines WHERE UPPER(item)=UPPER(?1) AND t…i Load context 7 D1 queries Safety checks that must pass before any writes. 'block' severity halts the run; 'warn' surfaces a warning but continues. Without these, a bad input could cascade into NetSuite. PRECONDITIONS (checked before fan-out) [block] item_exists: current_item.id present [warn] item_active: current_item.isinactive = 0 [block] proposed_changes_non_empty: proposed_changes present [block] rationale_present: rationale present [warn] not_in_active_bid: open_bid_lines is nulli Preconditions 5 checks The HITL (Human-In-The-Loop) gate. The workflow stages a proposed_action and waits for Mike to approve in /proposed-actions.html. Only fires when risk_level >= 3. This is the invariant: no NS write happens without Mike's go-ahead. HITL GATE (Mike approves before fan-out) action_type: workflow_item_record_review entity_ref: workflow:item_record_review:run_<run_id> approver: mike (single-admin) risk_gate: >= 3 (this workflow = 3) approval window: typical <= 60 min envelope: proposed_actions row staged by runneri Mike approves stage_proposed_action risk ≥ 3 gate Queue a write for Mike's HITL approval - staged in the proposed_actions table with status='pending'. Doesn't touch NetSuite directly. Real implementation. FAN-OUT: stage_proposed_action kind: stage_proposed_action (not in contract — diagram-only annotation)i stage_proposed_action stage_proposed_action REAL Wipe one or more KV cache keys so the next read pulls fresh data instead of stale cache. Real implementation - runs synchronously. FAN-OUT: kv_invalidate kind: kv_invalidate (not in contract — diagram-only annotation)i kv_invalidate kv_invalidate REAL Wipe one or more KV cache keys so the next read pulls fresh data instead of stale cache. Real implementation - runs synchronously. FAN-OUT: kv_invalidate kind: kv_invalidate (not in contract — diagram-only annotation)i kv_invalidate kv_invalidate REAL Invoke an existing chat tool (one of 50+ registered in tool_registry) as part of the cascade. STUB today - runner doesn't yet dispatch. FAN-OUT: chat_tool kind: chat_tool (not in contract — diagram-only annotation)i chat_tool chat_tool STUB Write to the local D1 mirror (the read-side cache of NetSuite). Used for derived data and platform state. STUB today - per-tool d1_write logic lives in chat_tools/impls.ts. FAN-OUT: d1_write kind: d1_write (not in contract — diagram-only annotation)i d1_write d1_write STUB Set a follow-up flag on a row (e.g., 'needs_review') so a downstream cron or human picks it up later. STUB today. FAN-OUT: flag kind: flag (not in contract — diagram-only annotation)i flag flag STUB Always-runs at the end of every workflow execution: writes a row to workflow_run_log with status, duration, step counts, and errors. Real implementation. POST ACTION: log_run -> D1: workflow_run_log fields: run_id, workflow_type, status, started_at, completed_at, summary_json source: runner automatic (always)i log_run workflow_run_log REAL Writes an entry to reflexion_log so the AI 'remembers' what happened. Only fires if the contract has reflexion_enabled=1. Future workflows can search this log for prior context. Real implementation. POST ACTION: reflexion -> D1: reflexion_log tags: item_record_review reflexion_enabled: True fields: run_id, narrative, tags source: runner automatic (when reflexion_enabled=1)i reflexion reflexion_log REAL Fires a workflow.completed / workflow.partial / workflow.failed event into the event ledger so downstream subscriptions can react. Uses an idempotency_key so producer retries collapse. Real implementation (R564). POST ACTION: event -> Event ledger (recordEvent) types: workflow.completed | workflow.partial | workflow.failed idempotency_key per run_id source: runner automatici event workflow.completed REAL A post-execution sanity check. The runner stages this with status='pending'; the verify-scheduler cron (every :08 and :38 hourly) wakes up after the configured window (e.g. +24h) and executes the sql_check, then flips status to pass/fail/timeout. Real implementation (R564). VERIFY: ns_field_actually_upd… scheduler: verify cron @ :08/:38 (R563)i ns_field_actually_upd… ≤60m A post-execution sanity check. The runner stages this with status='pending'; the verify-scheduler cron (every :08 and :38 hourly) wakes up after the configured window (e.g. +24h) and executes the sql_check, then flips status to pass/fail/timeout. Real implementation (R564). VERIFY: pricing_master_still_… scheduler: verify cron @ :08/:38 (R563)i pricing_master_still_… ≤60m A post-execution sanity check. The runner stages this with status='pending'; the verify-scheduler cron (every :08 and :38 hourly) wakes up after the configured window (e.g. +24h) and executes the sql_check, then flips status to pass/fail/timeout. Real implementation (R564). VERIFY: spec_sheet_present_if… scheduler: verify cron @ :08/:38 (R563)i spec_sheet_present_if… ≤60m Legend User UI Agent logic Policy Tool action Context / trace

Contract

  • • Type: item_record_review
  • • Risk: 3
  • • Trigger: manual_or_event
  • • Fan-out: 6 targets (Part 1 of 2)

HITL semantics

  • • risk ≥ 3 ⇒ stage_proposed_action
  • • Mike approves before fan-out
  • • REAL = solid green · STUB = dashed

Post actions

  • • log_run → workflow_run_log
  • • reflexion → reflexion_log
  • • event → workflow.completed
  • • verify × 3

Workflow diagram • Built with Archify • Press T for theme and E for export