Feature Flag¶
Software tool — instantiates Control Surface Creation
Implements a software control surface by allowing behavior to be enabled, disabled, targeted, or rolled out without redeploying the whole system.
Feature Flag is the software surface that decouples shipped from active. Code can be deployed dark and then switched on for no one, some, or everyone by flipping a flag — no rebuild, no redeploy. Its defining trait is staged, targeted, instantly reversible activation: behavior can be turned on for 1% of traffic, watched, widened to 50%, and killed in seconds if the numbers turn. This is what makes it distinct from a plain on/off setting — the flag is built for the rollout, for controlling exposure over a window while a feedback signal tells you whether to keep going or pull back. It turns a release from a one-way door into a dial you can advance and retreat on live traffic.
Example¶
A social app is rewriting the ranking that decides which posts appear first in the feed. Shipping it to everyone at once would be reckless — a bad ranker could tank engagement for tens of millions before anyone confirmed the metrics. The team wraps the new ranker in a feature flag. They deploy the code dark, then open an experiment window: 1% of users get the new ranking while the rest stay on the old. The flag is the control surface — a switch that targets cohorts by percentage — and the team watches a feedback signal (session length, report rate, error counts) split between the two groups. Seeing the new ranker hold, they widen to 10%, then 50%. When a latency regression surfaces at 50%, they flip the flag off and every user is back on the old ranker within seconds — the rollback path is the same switch, thrown the other way. No emergency redeploy, no all-nighter; just a dial advanced and, this time, retreated.
How it works¶
- Decouple deploy from activation. Ship the code behind a flag so "is it running" and "is it on" are separate switches, and the second needs no redeploy.
- Target by cohort. Make the flag address a slice — a percentage, a region, a user segment — so exposure grows deliberately rather than all at once.
- Advance across an experiment window. Widen exposure in stages, holding at each until the signal clears, so the rollout is a staged ramp, not a leap.
- Keep the off-switch instant. Wire the flag so flipping it back is immediate and needs no build — the rollback path and the control surface are the same switch.
Tuning parameters¶
- Ramp schedule — how fast exposure widens (1→10→50→100 or a slow crawl). Fast ramps learn quickly but expose more users to a bad change; slow ramps are cautious and drag.
- Targeting granularity — percentage, segment, region, or individual. Fine targeting contains blast radius[n1] and complicates reasoning; coarse targeting is simple and blunter.
- Kill-switch scope — whether one flip reverts one cohort or everyone. A global kill is safest in a crisis; scoped kills preserve a good partial rollout.
- Guardrail metrics — which feedback signals auto-hold or auto-revert a ramp. Tight guardrails catch regressions early and can halt a healthy rollout on noise.
- Flag lifespan — whether the flag is temporary (retired after full rollout) or permanent (an operational toggle). Stale flags are a leading source of flag debt.
When it helps, and when it misleads¶
Its strength is that it makes a software change a reversible, observable, staged event: exposure grows only as the feedback signal permits, and a regression is one flip away from gone — precisely the canary release discipline that keeps the blast radius of a bad change small.[n1]
Its failure mode is proliferation and rot. Flags accumulate — thousands of stale toggles nobody dares delete — and their combinations create untested states where two flags that are each fine interact badly. The classic misuse is leaving a temporary rollout flag in the code forever, so it silently becomes load-bearing configuration with no owner. The guarding discipline is a lifecycle: every rollout flag has an expiry and is deleted once fully ramped, permanent operational flags are named and owned, and guardrail metrics — not vibes — decide when a ramp advances or reverts.
How it implements the components¶
Feature Flag realizes the staged-reversible-rollout components — the ones that make a software change safe to advance and retreat on live traffic:
control_surface— the flag is the switch: enable, disable, or target behavior without redeploying.experiment_window— the staged, cohort-targeted ramp that grows exposure deliberately.rollback_or_recovery_path— the same flag flipped back, reverting instantly with no build.feedback_signal— the per-cohort metrics that decide whether the ramp advances or reverts.
It does not distribute human decision rights or wire an escalation trip-wire — that authority_scope/escalation_path protocol is Delegated Approval Rule's — and it does not build the effector its branch executes; that actuator is Actuator Installation's. A flag steers which code path runs; others govern who may act and what the action drives.
Related¶
- Instantiates: Control Surface Creation — the software surface for staged, targeted, instantly reversible activation.
- Sibling mechanisms: Actuator Installation · Adjustable Threshold · Admin Console · Configuration Template · Control API · Control Knob · Delegated Approval Rule · Manual Override · Policy Lever
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Feature Flag operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it implements a software control surface by allowing behavior to be enabled, disabled, targeted, or rolled out without redeploying the whole system.
Independent corroboration: The frozen evidence defines Feature Flag as 'Implements a software control surface by allowing behavior to be enabled, disabled, targeted, or rolled out without redeploying the whole system', so its operative form is Control, Automation & Runtime.
Nearest alternative: Structure, Architecture & Configuration — The flag is evaluated at runtime to target and activate behavior, while its named switch and wrapped code form the enabling configuration.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Runtime feature toggles are a software-engineering configuration and release-control technique.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] A canary release exposes a change to a small slice of traffic first and widens only if the slice stays healthy, keeping the blast radius — the number of users a bad change can reach — small; a feature flag is the switch that makes this staged exposure and its instant revert possible. ↩a ↩b