Define the scope of a change freeze

Define this change freeze.

Sort pending changes:
1. **Freeze** — anything touching the systems that must not fail during this period, plus anything whose blast radius is unclear.
2. **Allow** — changes that reduce risk during the period: monitoring, alerting, rate limits, feature flags that let you turn things off.
3. **Must ship before the freeze** — anything the period itself depends on. Name the cutoff date.
4. **Exempt with approval** — security fixes, data-loss bugs, and anything where not shipping is riskier than shipping.

Then:
- **The exception procedure.** Who approves, what evidence is needed, who tests. *A freeze with no exception path gets bypassed informally, which is worse than having no freeze.*
- **The unfreeze plan.** Everything queued ships at once otherwise, which concentrates risk exactly when attention is lowest. Stagger it and say how.
- What gets riskier *because* of the freeze: stale dependencies, unpatched issues, a growing untested delta.
- What to monitor during the freeze, since nobody is deploying and attention drifts.

Rules:
- Freeze the narrowest set that achieves the goal. A broad freeze is easier to declare and harder to hold.
- Say plainly if the freeze is not warranted for this period.