Flags and rules

Evaluation order

flag off globally?                  → default
prerequisite flags satisfied?       → if not, default
dev override for this subject?      → that value
first matching targeting rule?      → that value
percentage rollout bucket?          → that variant
                                    → default

Deterministic: the same subject always gets the same answer for the same configuration. That matters — a user whose feature flickers between page loads is a bug report.

Targeting rules

Match on subject attributes: user id, email domain, plan, country, device, anything you pass in the evaluation context.

IF  plan = "enterprise"      → on
IF  country IN ["AZ","TR"]   → on
IF  email ENDS WITH "@ourcompany.com" → on
ELSE                         → 20% rollout

Percentage rollout

Bucketed on a hash of the subject id, so the same user stays in the same bucket as you ramp. Going from 10% to 20% adds people; it does not reshuffle them.

Variants

A flag can serve several values with weights, which is what A/B tests are built on.

Prerequisites

A flag can require another flag. new-checkout-v2 might require new-checkout-base, so turning the base off turns everything built on it off.

This is what stops a half-enabled feature stack, which is a state nobody tests.

Per-environment

Every flag has independent state per environment. On in staging, 5% in production is the normal arrangement.

Dev overrides

An individual can force a value for themselves without affecting anyone. Scoped to the person and does not change the flag.

Scheduled changes

A change can be scheduled — on at 09:00 Monday, off at 18:00 Friday.

Snapshots

Flag configuration is snapshotted, so "what was this set to at 14:00" has an answer during an incident.

Typed values

Flags carry typed values — boolean, string, number, JSON. A JSON flag can carry a whole configuration object, which is a clean way to make something tunable without a deploy.