In a candidate send-time model's traffic ramp, what sets how long one step must bake before the next increase?

## What bake time is for The **bake time** of a ramp step is the interval a step is held at its percentage before the ramp is allowed to advance. Its job is narrow and checkable: to make the step's guardrail halt *possible*. A step that ends before its guardrails could have moved has a halt on paper and none in practice, and the ramp then advances on the absence of evidence rather than on evidence of absence. So the question to ask of any proposed schedule is not "is two hours long enough to be safe?" but **"can the signal I would halt on have moved within two hours?"** ## The three delays that set the floor 1. **Exposure delay — the action has to happen.** A send-time model does nothing until the notifications it re-timed are actually sent. If the candidate moves a cohort's notification from 9am to 7am, the effect of that decision does not exist until 7am arrives for those users. A step therefore has to span at least one full daily send cycle, across time zones if the population spans them, before there is any candidate behaviour at all. 2. **Reaction delay — the user responds later than the action.** Opt-out and mute are deliberate acts. A user annoyed by an early notification often mutes at the next convenient moment, not at the moment of delivery. The guardrail's response is therefore smeared over hours after the send, and a window that closes at the send has measured nothing. 3. **Settling delay — the system blends at the boundary.** When the percentage changes, work planned under the old percentage is still in the queue. For the first part of a step the delivered mix is neither the old share nor the new one. Caches, a daily feature refresh and any warmup on the candidate's path add to the same effect. ## What caps it from above | Pressure | Direction | |---|---| | Guardrail signal latency | Pushes the step longer | | Reaction lag of a deliberate user action | Pushes the step longer | | Queue drain and cache warmup at the boundary | Pushes the step longer | | Users exposed to an unproven version | Pushes the step shorter | | Two model versions running and being watched | Pushes the step shorter | | Calendar pressure on the rollout | Pushes the step shorter | Bake time is the point where those two directions balance, and it is legitimately different per step: an early step exposes few users and can be held longer at low cost, while a late step has most of the population on it and the pressure to finish is real. ## Consequences worth stating in a design round - **Guardrails must be observable inside the window you chose.** A signal that only resolves days later cannot gate an hours-long step. Either the step lengthens to match the signal, or the step is gated on a faster-moving signal and the slow one is read after the ramp instead. - **Attribution has to survive the window.** Every send carries the version that produced it, so the guardrail can be computed per side inside the step rather than compared against last week. - **A halt is a hold, not a revert.** Reaching the end of a bake window with a moved guardrail stops the advance; deciding what to do about the exposed cohort is a separate decision. - **Bake time is not the same question as how confidently the effect will eventually be scored.** Here we are asking only whether the signal could have appeared at all inside the window. ## A worked shape For a candidate that changes when a daily notification is sent, a defensible schedule looks like a small first step held across a couple of full send cycles, then a larger step, then larger still — each step at least one complete cycle plus the mute-reaction lag, and each boundary treated as a blend until the previously queued sends have drained. What makes the schedule defensible is not the specific percentages but that each number in it was derived from a delay someone can name.