The change calendar is three overlapping calendars — the MSP's scheduled changes, each
client's freeze windows, and each client's business rhythm. A proposed window has to clear
all three. Run that clearance and schedule (or bounce) the change.
1. Load the change ticket: affected systems, affected clients, proposed window, expected
duration INCLUDING rollback time. A window that fits the change but not
change-plus-rollback is not a fitting window.
2. FREEZE CHECK: look up each affected client's freeze calendar (see
maintenance-freeze-windows). A window inside a freeze is an automatic bounce to the
requester with the freeze cited — the exception path lives in maintenance-freeze-windows,
not here.
3. BUSINESS-CALENDAR CHECK: compare the window against the client's documented operating
hours and known busy periods (month-end close, seasonal peaks, published events).
"Saturday night" is not universally safe — some clients run weekends. If operating hours
aren't documented, say so and ask rather than assuming 9-to-5.
4. COLLISION CHECK: search for other approved or scheduled changes overlapping the
window on the same systems, the same client, or shared infrastructure in the dependency
path. Flag both hard collisions (same system, overlapping window) and soft ones (same
client hit by two unrelated maintenances in one week — reads as instability to the
client even when each change is fine).
5. Render a verdict: CLEAR (all three checks pass), CONFLICT (cite each conflict
specifically), or INSUFFICIENT (missing duration, undocumented client hours — list
what's needed).
6. On CLEAR and with the requester's confirmation, place the window on the calendar (or move the existing entry when relocating one), and post a plain-text note recording
the checks performed and their outcomes — the clearance is audit trail, not just a green
light.
7. On CONFLICT, propose up to two alternative windows that clear all three calendars, but
only propose — moving another team's scheduled change is a human conversation, never a
silent reschedule.
8. Remind the requester of the client-notice obligation for user-visible windows.
Guardrails: never silently reschedule anything — conflicts are surfaced to humans with
options, and the requester confirms before any schedule write. A freeze window always wins
over convenience; only the documented exception path overrides it. Check shared-
infrastructure dependencies, not just the named system — two changes to "different servers"
on the same host or uplink are a collision. Scheduling is not approval: a change on the
calendar without its approval recorded gets flagged, not executed. Result-cap honesty: if
the collision search may have hit a cap, say the sweep is partial rather than declaring the
calendar clear.
Magic Library