Freeze config the night before you cut over.

Cutover night is when unattended edits win

The release is rehearsed. The runbook has steps. Then, the evening before, someone fixes a flag “just for the test,” a cron job deploys an old config, or a secret rotation lands because Tuesday is rotation day. In the morning the bits you cut over are not the bits you reviewed. The runbook still reads as if they were.

A freeze is useful when named configuration is pinned, a role is the only one who may change it, and drift is something you can detect by comparing a list—not by hoping the right person is awake. It is not useful when the channel says “nobody touch prod” and three automation paths do not read the channel.

This note is the TWIMCO Config Drift Freeze Card. It covers environment keys, references to secrets (never the secret values), feature flags that change go-live behavior, and cron or scheduled jobs that can rewrite config or data. It is not the cutover runbook. The runbook is the sequence of steps. This card is the set of values that must not move while those steps run, who may break the seal, and the check you run before you call it live. It is also not a pin of model, prompt, and tool versions. Those matter, and they belong on their own card. Mixing them into this one is how both lists get vague.

There is no live freeze-card tool. If the open question is whether the workflow should be automated at all, the live AI workflow readiness check is the place to start. Readiness will not pin your cron.

On Sutton|Place, the ongoing partnership treats who may act as something you can inspect: disclosure and decisions carry an actor, and a claim is not the same thing as a check. A freeze is that habit applied to configuration. “We agreed not to change it” is a claim. The diff before go-live is the check. Do not read the case study as a description of Sutton|Place’s deploy tooling. It is not that. It is the standard that authority stays named when the pressure is on.

Write the card before the freeze window starts. A card written during the window is already late; you will miss the jobs that fire while you are still listing them.

What is pinned, and what is deliberately not

One page. Four lists and two roles. If a list is empty, write “none” after someone looked. An empty list without that word looks like a finished freeze and behaves like no freeze.

Environment keys. The keys whose values change behavior at go-live: endpoints, feature gates stored as env, mode flags, tenant or partner identifiers you do not intend to edit overnight. Record the key name and where it lives. You may record a non-secret fingerprint such as length or a hash you already use. Do not paste secrets, tokens, or connection strings onto the card. The card will be copied into a channel. Treat it as readable by everyone in the review.

Secret references. The secret’s name in the store, the version or rotation generation you expect to be current, and the owner of rotation. “No rotation during the window” is a line the rotation owner agrees to, not a wish the release owner makes alone. If a rotation must happen, it is a planned change under the break-glass role, with a before-and-after reference, not a value.

Feature flags. The flags that would change what go-live means if they flipped: the path under test, a kill switch you are counting on, a dependent flag that must stay with its parent. Point at the kill-switch card if you have one. The freeze card does not replace it. It says these flags do not move unless the break-glass role moves them and records why.

Cron and schedulers. Jobs that deploy, migrate, sync, rotate, or rewrite the pinned keys. For each: name, what it writes, and whether it is suspended for the window. A job you did not suspend is not frozen just because humans agreed to be careful. Include the deploy pipeline if it can ship config without a human in the room.

Out of freeze. Say what may still change: copy in a draft, a non-prod environment, observability sampling, anything you are explicitly leaving free. A freeze of “everything” that everybody violates is worse than a short list people keep. The short list must include every key that would make tomorrow’s system differ from the one you approved.

Who may change. One break-glass role, plus a backup. Everyone else, including well-meaning automation owners, does not edit pinned items during the window. The role records the key, the reason, and the time. A change without that note is drift even if the person had access.

The card is not ready if you cannot say where the expected values were captured, or if cron was shrugged off as “we’ll watch the channel.”

Detect drift before you call it live

Walk the window as a sequence. Times are yours to set. This page does not give you a clock.

Capture. At the start of the freeze, record the expected snapshot: key names, non-secret fingerprints, flag states, cron suspend states, secret version references. Store it where the go-live review can open it. The person who captures it signs the card. If capture is “we looked at the dashboard,” you cannot diff later.

Freeze. The window is open. Humans are told, and the jobs you listed are actually suspended or pointed at a no-op. Verify the suspend. A commented intention in the runbook is not a suspended job.

Change, if any. Only the break-glass role. Each change appends to the card: what moved, why, and the new fingerprint. The snapshot is updated on purpose so the morning diff has a target. An oral change does not update the target and will look like drift, which is what you want until it is written down.

Detect. Before go-live, compare live values to the snapshot plus approved changes. The comparison is a diff of the named keys, flag states, secret versions, and cron states. It is not a graph and it is not a feeling that the deploy “looked normal.” Who runs the diff is named. What they do on mismatch is named: stop, or accept a new break-glass line and diff again. Proceeding on mismatch because the room is tired is the failure mode the card is for.

Close. After go-live is called, the freeze ends on purpose. Suspended jobs are restored by the same role that suspended them, and that restoration is a line on the card. A freeze that never ends blocks legitimate rotation. A freeze that ends by everyone assuming it ended will miss a job you left suspended, which is the other outage.

Rehearse the diff once before the real window, in a non-production environment, by changing one pinned key without telling the reviewer and confirming they stop. If the rehearsal cannot see the change, the snapshot is of the wrong store. Fix the capture before you trust the night.

Sutton|Place-shaped work rewards the same shape: the snapshot is the supplied baseline, the diff is the check, and break-glass is a decision with an actor. Keep those distinct on the card so a later reader can tell a planned change from a surprise. Ongoing partnership does not help if the only person who knows which store is live is asleep. The card is how the review survives that.

Freezes that are only etiquette

Composites, not incident statistics.

The channel freeze. “No touches after six.” A scheduler in another repo ships at six-thirty because it does not read the channel. The keys moved. The runbook proceeds.

Secrets on the card. Someone pastes a connection string so the reviewer can “see the real value.” The card is now a leak, and the value will be rotated mid-window in a panic, which is drift you caused by trying to be thorough.

Flags off to the side. Env is pinned. The flag that selects the new path is flipped by a product owner who thought flags were not config. Go-live tests the wrong path and the diff, which omitted flags, stays green.

Diff as theater. The reviewer glances at a console and says it looks like yesterday. There is no list of keys. Drift in the one key that points at the old endpoint survives the glance.

Break-glass as shared password. Everyone can change everything, so the role line is decorative. Afterward you cannot tell an emergency from a preference.

When you see these, do not add a louder message. Narrow the list, suspend the jobs, and make the diff a comparison against that list. The unreproducible asset is the filled TWIMCO Config Drift Freeze Card: your keys, your secret references without values, your flags, your suspended jobs, your break-glass role, and a rehearsal note that an unannounced edit was caught. A sentence in a runbook that says “freeze config” does not name the keys. The card does.

Use the card beside the runbook, not as a substitute for it. Steps still need owners. The card stops the ground from moving under the steps. If a model prompt or a tool definition can change behavior overnight, pin those on the separate card meant for them, and say so here under out-of-freeze or under a pointer. Do not leave them implicit.

Business process automation is the right conversation when the thing defeating the freeze is a job between systems. Web applications fits when the values live in the app’s own config and nobody can say which store is live. Either way, the public habit to copy from Sutton|Place is simple: name who may act, and do not call a claim checked until you have compared it to something.

Put this into practice

1. Before the window, list env keys, secret references, flags, and cron jobs that would change go-live if they moved. Write “none” only after looking.
2. Name the break-glass role and the backup. Agree secret rotation with the rotation owner. Keep values off the card.
3. Capture a snapshot at the start. Suspend the jobs you listed and verify the suspend.
4. Diff before go-live. On mismatch, stop or record a break-glass change and diff again. Rehearse that stop once ahead of the real night.
5. End the freeze on purpose and restore suspended jobs in a written line. If you cannot tell which store is live, do not start the window; bring that to business process automation or web applications. Read Sutton|Place for authority that stays inspectable when the work is under pressure.

A careful team can still lose a night to a job that was never on the list. Put the job on the list.