Core Concepts

This page explains the mental model behind ReleaseAnchor. Understanding these concepts will make everything else click.

The hierarchy

Organization
└── Project (e.g. "Mobile App")
    └── Environment (e.g. "Production")
        └── Feature Flag
            └── Rules (evaluated top-to-bottom)

Every flag lives inside an environment inside a project inside your organization. A flag in Production is completely independent from the same flag in Staging — they can have different states, different rules, different values.

Feature flags

A feature flag is a named boolean. You give it a key (e.g. new-checkout) and your code checks that key at runtime.

flag key: "new-checkout"
         ↓
   your code calls evaluate("new-checkout", userId)
         ↓
   ReleaseAnchor returns: { value: true, matchedRuleType: "PERCENTAGE" }

The key is permanent and referenced in your code. The name and description are for humans.

Environments

Each project has isolated environments. A flag enabled in Staging is not automatically enabled in Production — you control each independently.

Environment	Typical use
Production	Real users. Changes here are live.
Staging	Pre-release testing. Usually mirrors prod config.
Development	Local development. Often everything enabled.

These are common examples — you can create any environment names you need (e.g. QA, Canary, Region-EU).

Each environment has its own API key. Your production app uses the production key; your staging app uses the staging key. The key determines which environment's flag state is returned.

Rules

Rules determine what value a flag returns for a specific user. A flag can have a single rule or multiple rules. When there are multiple rules, they are evaluated in priority order and the first matching rule wins.

Percentage Rollout

Matches a stable, deterministic percentage of your users. The bucket is computed from a hash of the user identifier, flag key, and environment — so the same user always gets the same result.

10% rollout diagram — A deterministic rollout bucket keeps the same users included as you expand percentage over time.

A user who gets true at 10% will still get true when you expand to 50% — they never flip.

Use for: Gradual rollouts, canary deployments, A/B testing.

Segment

A segment is a named group of user identifiers. You define it once and reference it in flag rules across multiple flags.

Segment: "Beta Testers"
Members: user-001, user-002

Matches users whose identifier is in a named segment. You maintain the segment independently — flag rules just reference it by name.

Segment rule evaluation diagram — Segment rules let you reuse a named user group across multiple flags.

IS_IN — User is in the segment → rule matches, return the configured value.
IS_NOT_IN — User is not in the segment → rule matches, return the configured value.

Use for: QA team, VIP users, internal team access, allowlists, denylists.

When you target this segment in a rule, any user in that list gets the overriding value.

Segments are scoped to a project + environment. A segment defined in Platform/Production is only available to flags in that environment.

Static

Always matches — no conditions. Every user satisfies a Static rule.

Place it last in your rule list as an explicit fallback. You configure the value — it can return true or false.

When you have multiple rules, you don't have to add a Static rule as the last step. If no rule matches, the flag returns false by default.

Use for: Explicit fallback values, global on/off default.

Evaluation order matters

Rules are checked top-to-bottom. The first matching rule wins — the rest are never evaluated.

Rule evaluation order diagram — Rules are evaluated in order, and evaluation stops at the first match.

Evaluation flow

When your code calls evaluate("my-flag", userId), this is what happens:

API Keys

Each environment has its own API keys. Keys are environment-scoped — using a Staging key will always return Staging flag values, regardless of what environment your code thinks it's in.

Never commit API keys to source control or expose them in client-side code. Keep them secret.

Best practices

Create flags as disabled — Add new flags with the flag disabled. Configure your rules first, then enable when ready.
Verify before enabling — Confirm that your API key and the evaluate API work correctly (e.g. with a curl test or in Staging) before enabling a flag in Production.
Use Staging first — Test flag changes in Staging before rolling them out to Production.
Start small on rollouts — When using percentage rollout, start with a low percentage (e.g. 5–10%) and increase gradually.

Was this helpful?