Kill the flag, or do not half-kill it.

A flag is a kill path, or it is a permanent branch

Someone adds a flag so a new path can ship before it is finished. The happy setting is on for a few accounts. Weeks later the flag is still in the code, the off state was never designed, and turning it off would strand a write that the on state already promised. The flag became a second product with no owner.

A kill switch is useful when a named role can turn the flag off, users land in a state you have described, and flags that depend on it die with it. It is not useful when “we can always disable it” is a sentence in a ticket and the off path is untested.

This note is the TWIMCO Feature-Flag Kill-Switch Card. One card, one flag. You name who may kill it, what a person sees and what the system does when it dies, what evidence must exist before anyone turns it back on, and the dependent flags that must not remain on alone. There is no live generator for this card. If you are still deciding whether the path should be a product at all, use the live custom product build brief. Do not treat a flag inventory in a vendor console as the card.

On Sutton|Place, who may act is part of the record: disclosure and decisions stay attached to an actor, and a supplied claim is not the same thing as a checked one. A flag kill is an action. It needs a role, not a hope that someone with dashboard access will do the sensible thing. Spin:Market is a different public lesson in the same direction: TWIMCO built both the application and the player software, and updates were scheduled for idle periods rather than dropped into a room mid-experience. A flag that changes what operators or devices do needs the same respect for the moment you pull it. Neither case study is a feature-flag postmortem. Do not borrow them as proof that a particular flag was safe.

Write the card when the flag is introduced, not the night it misbehaves. If you cannot say what “off” means for the user, you do not have a kill switch. You have a boolean.

Four lines that make the off state real

Keep the card to one page. Fill it in ordinary language.

Flag. Name in code, name a human would use, and the path it gates. Say whether it is a user-visible behavior, a write path, or both. A flag that only hides a button but still accepts the old API is two flags wearing one name. Split them on the card or admit you will half-kill.

Who may kill. A role. Not “anyone in engineering,” unless that truly is the role and you accept the blast radius. Name a backup role for when the owner is unavailable. Say whether kill is a config change, a deploy, or a data fix. If it requires a deploy, the card’s time-to-off is “next release,” and you should not describe it as immediate.

What people see. The screen, message, or fallback path when the flag is off. Include in-flight work: a form already open, a job already queued, a device already sent a command. “They see the old UI” is incomplete if the new path already stored a row the old UI cannot read. Write the one sentence support will be allowed to say. If you cannot write it, the off state is not designed.

Evidence before restore. What must be true before the flag goes on again. A fixed build, a check you can point at, a named approver. “We think it’s fine” is not evidence. Restore is a second action with its own actor. Killing does not authorize the same person to restore unless the card says so.

Do not half-kill. List dependent flags, jobs, and copy that assume this flag is on. Either they switch off in the same action, or the card explains why they remain safe while this one is off. A child flag left on, writing into a path the parent just closed, is the failure this line exists to prevent.

Optional, still useful: where the change is recorded (audit log, deploy note, or the card itself appended to the incident), and how long the off state is allowed to live before someone must delete the flag or rebuild the default. A kill switch that lives for a year is a fork.

The card is not ready for production use if who-may-kill, what-people-see, restore evidence, or the dependent list is blank. A blank dependent list is allowed only when you write “none known” after someone looked.

Kill, hold, and restore are different acts

Walk the flag as a short timeline so the team stops treating the dashboard toggle as a single gesture.

Armed. The flag exists. The card is filled. The off path has been exercised at least once outside production, including one in-flight case. Support has the sentence they may say.

Killed. The role turns it off. In-flight work follows the rule on the card: finish on the old path, abort, or pause for a human. Dependents move with it. The actor and time are recorded. Users see the state you named, not a stack trace and not a half-rendered new screen.

Held. The flag stays off while you learn. No one “just peeks” by enabling it for an unnamed account. If you need a narrower audience, that is a new decision—see a canary audience, not a quiet exception on this card.

Restore. The evidence line is satisfied. The restore approver acts. Dependents return only if their own cards allow it. You do not restore a parent and assume children are harmless.

Retire. Either the path is now the default and the flag is deleted, or the path is abandoned and the flag’s off behavior becomes the only code. Leaving both paths because removal is scary is how the next kill gets harder.

On a platform like Spin:Market, where commands go out to devices and status comes back, a control change during the experience is not theoretical. Schedule the kill the way you would schedule maintenance: know what is in flight, and do not describe the off state as instant if players or jobs will keep the old behavior until they check in. On Sutton|Place-shaped work, the kill itself should stay as inspectable as a disclosure: actor, time, and the distinction between “we turned it off” and “we have checked that off is what users got.”

If two flags must move together, write one action that does both, or write an order and the failure rule if the second write does not stick. “Toggle them both” in a runbook that nobody holds is a half-kill waiting for a partial save.

Half-kills that look like caution

These patterns are composites from delivery arguments, not measurements from a client flag system.

Off hides the button only. The API still accepts the new write. Support says the feature is disabled. The database says otherwise.

Dependent left on. A follow-up job, email, or agent tool keeps acting on the new path after the flag that was supposed to gate it is off. The team calls this a graceful degrade. Users call it a promise you withdrew in the interface and kept in the worker.

Restore by the killer. The same person who turned it off turns it on an hour later because the channel got loud. No evidence line. The incident and the relaunch are the same mood.

Kill requires a hero. Only one engineer knows which config store is live. The card says “on-call,” but on-call cannot reach the switch. Time-to-off is folklore.

Permanent temporary flag. The off path rots. The next kill is more dangerous than the bug you wanted to stop. The card’s retire line was never filled, so the fork became architecture.

When you see these, do not add another flag to guard the first. Fill the card, or remove the path. The unreproducible asset is the filled TWIMCO Feature-Flag Kill-Switch Card: your flag name, your kill role, your user-visible off state, your restore evidence, and your dependent list with “none known” only where someone actually looked. A blog post about progressive delivery does not contain those lines. Your release record can.

Use the card next to the change note for that path. It does not replace security review or a rollback plan for the deploy itself. A deploy rollback returns code. A flag kill returns behavior while code stays. Confusing the two is how a team reverts a release and leaves the flag on, or kills the flag and thinks the bad code is gone.

If the flag gates an agent or another automated actor, say so on the card. Turning off the button while the agent keeps the tool is a half-kill with a polite interface. AI applications and agents are in scope when the thing being killed is allowed to act, not only to display. The public Sutton|Place standard still applies: judgment and action stay with a named role when the automation should stop.

Put this into practice

1. Choose one flag that already gates a path a user or worker can notice.
2. Fill who may kill, what people see (including in-flight work), evidence before restore, and dependents.
3. Exercise the off path once outside production. Save what you saw in a sentence on the card.
4. Refuse to call it a kill switch until those lines are filled and the off path has been seen.
5. When the path is kept or deleted, retire the flag on purpose. If the card shows you do not actually know what off does, bring that into a web applications scoping conversation rather than shipping a second product behind a boolean. Read Sutton|Place for how an action stays attached to a role, and Spin:Market for how a control change has to respect the thing already in motion.

A flag is a courtesy to the release only if you can put it down cleanly.