Monitoring
Minimum runtime guard rails
Fourteen days by default, and never fewer than seven. Below a week you are measuring a Tuesday rather than a business.
Traffic is not the same on a Tuesday as on a Sunday, and neither is intent. An experiment stopped after four days has measured whichever days those were, and the effect it reports will not survive contact with a full week.
So a minimum runtime is enforced before an automated stop on significance is allowed. The default is fourteen days, which is two full business cycles, and it cannot be configured below seven at all. That floor is a hard limit rather than a warning, because the argument for going below it is always the same and always wrong.
It only gates the significance path. A scheduled end time still ends the experiment whenever it arrives, and a person can always stop one by hand. The guard rail exists to stop automation from acting on a reading taken too early, not to prevent you from managing your own programme.
It is checked before the no-traffic gate, deliberately. A freshly started experiment looks identical to one that has recorded nothing for a day, and blocking on that reading is terminal, so evaluating it before an experiment has had the chance to receive traffic would destroy every stop-on-significance schedule within a minute of going live.