The event-driven loop

Between Mode 1's daily rhythm and the real-time chaos of an operating supply chain sits the event-driven loop. Events arrive continuously — sales orders, supplier confirmations, capacity changes, FX ticks, customer pull-ins, supplier slips. The change-interpretation layer assesses each one, makes four decisions, and routes accordingly.

Decision 1: absorb or evaluate. Most events absorb as state updates without invoking the engine — a price tick that doesn't change a commit decision, a confirmed shipment that matches expectation, a routine acknowledgment. Decision 2: coalesce or fire. Related events within a time window batch together — six exception messages from the same supplier in 30 seconds become one evaluation, not six. Decision 3: scope. The dependency graph identifies which order lines and supply events are actually affected; the solve narrows to those rather than the full network. Decision 4: route. Heuristic engine for fast decisions, optimizer for material ones — driven by EVW and the value at risk.

The autonomy envelope is the human-in-the-loop boundary. The Decision Policy sets thresholds for auto-commit eligibility — by value at risk, by decision class, by resilience score, by EVW. Decisions inside the envelope commit automatically and write to the SoR; decisions outside surface to the human queue. The threshold is configurable per customer per Workspace per decision class — a strategic-account allocation might always surface even at small value, while a routine PO release below $50K with high resilience auto-commits.

The loop has memory. Today's events are interpreted against the system's record of yesterday's committed decisions. A supplier's 9-day slip on PO-2891 is read as "+5 days from current state" not "+9 days from original baseline" because last week's adjustment is in state. The change-interpretation layer reads the new event in context, not in isolation. Chapter 4.5 replays Maya's Tuesday morning with this memory active.