Design the Request Path for a Latency-Constrained Policy Service

You're designing the serving path for an in-app "next best action" policy (show a tutorial tip, offer a discount, do nothing) that must respond within a 50 ms budget as part of a page load, at 80,000 requests/second peak. The policy must respect a hard rule ("never show a discount to a user currently in a live support chat, to avoid undercutting the agent") and must log enough data to support future off-policy evaluation.

1. Lay out the request path stage by stage with a rough latency budget per stage, showing where the hard discount rule is enforced and why you placed it there rather than elsewhere.
2. Explain exactly what gets written to the decision log and at what point in the pipeline it is written, given that the "reward" for this system (e.g., whether the user converts) may not be known for hours.
3. A teammate suggests skipping the exploration layer for this particular action space "since it's low-stakes, just show something reasonable." Explain the concrete cost of that shortcut six months from now.