Glossary
A comprehensive reference of feature flag and FeatureSignals terminology. Each term links to its in-depth documentation page where available.
New to Feature Flags?
Start with the What is FeatureSignals? introduction, then explore the Feature Flags core concept page.
Feature Flag- A conditional switch in your code that lets you enable or disable functionality without deploying new code. Also called a feature toggle. FeatureSignals supports boolean, string, number, JSON, and A/B flag types. Learn more →
Toggle Category- A classification for feature flags that determines their expected lifespan and staleness thresholds. The four categories are: release (days to weeks), experiment (weeks to months), ops (indefinite), and permission (indefinite). Modeled after Martin Fowler's feature toggle taxonomy. Learn more →
Targeting- The mechanism that determines which users receive which flag variation. Targeting rules evaluate user attributes (email, plan, region, custom properties) against conditions to decide whether to serve a specific value or proceed to the next rule. Learn more →
Segment- A reusable, named group of users defined by a set of rules. Segments can be shared across multiple flags. For example, a 'Premium Users' segment matches users whose plan attribute equals 'premium'. Learn more →
Rollout- The process of gradually increasing the percentage of users who see a new feature. FeatureSignals supports percentage-based rollouts using consistent hashing — a given user always receives the same assignment throughout the rollout. Learn more →
A/B Experiment- A controlled test where users are split into groups (variants) and each group sees a different version of a feature. FeatureSignals tracks impressions and supports weighted variant assignment so you can measure the impact of each variant. Learn more →
Mutual Exclusion- A constraint that prevents two or more flags from being enabled for the same user at the same time. Used when running concurrent experiments that could interfere with each other. Flags in the same mutual exclusion group are evaluated in order — only the first matching flag wins. Learn more →
Prerequisites- Flags that must be enabled for a dependent flag to evaluate. Think of it as a dependency chain: flag B depends on flag A. If flag A is not enabled, flag B returns its default value regardless of its own configuration. Learn more →
Flag Lifecycle- The progression of a feature flag through statuses: active → rolled_out → deprecated → archived. Each status conveys whether a flag is in use, fully released, scheduled for removal, or permanently retired. Learn more →
Environment- An isolated context for flag evaluation — typically dev, staging, and production. Each environment has its own flag states, targeting rules, and rollouts. The same flag can be ON in dev and OFF in production. Learn more →
Project- A logical grouping of environments and flags. Projects typically map to applications or services. Each project has its own set of environments, flags, API keys, and team permissions. Learn more →
Organization- The top-level tenant boundary in FeatureSignals. An organization contains projects, users, API keys, and billing. All data is scoped through the organization chain: Organization → Project → Environment → Flag.
SDK- A client library that integrates with your application to evaluate feature flags. FeatureSignals provides OpenFeature-native server SDKs (Go, Node.js, Python, Java, Ruby, .NET) and client SDKs (JavaScript, React, iOS, Android). Learn more →
API Key- A secret token used by SDKs to authenticate with the FeatureSignals evaluation API. Server SDKs use server-side keys (full access to flag data). Client SDKs use environment-scoped keys (limited to the flags exposed to that environment). Learn more →
Evaluation- The process of determining which value a flag should return for a given user and context. The evaluation engine runs through the evaluation order: flag existence check → environment enabled check → mutual exclusion → prerequisites → targeting rules → percentage rollout → variant assignment. Learn more →
Relay Proxy- A lightweight sidecar that sits between your application and the FeatureSignals API. It caches flag rulesets locally, reducing latency and eliminating dependency on the FeatureSignals cloud for each evaluation. Ideal for high-throughput or air-gapped environments. Learn more →
AI Janitor- FeatureSignals' automated flag hygiene system. It scans your flags for staleness patterns — flags that haven't been evaluated recently, flags that always return the same value, unreachable targeting conditions, and zombie flags from removed code paths — and surfaces actionable cleanup recommendations.
Audit Log- An immutable record of every change made to flags, environments, segments, and permissions. Each entry includes who made the change, when, what changed, and the previous value. Used for compliance (SOC 2, ISO 27001), debugging, and change review.
Webhook- An HTTP callback that FeatureSignals sends to your URL when specific events occur — flag created, flag toggled, environment state changed, or stale flag detected. Use webhooks to integrate with CI/CD pipelines, incident management tools, and chat platforms.
RBAC- Role-Based Access Control. FeatureSignals Enterprise Edition includes predefined roles (Owner, Admin, Member, Viewer) and supports custom roles. Each role defines what actions a user can perform on which resources within an organization.
Idempotency Key- A unique identifier sent with mutating API requests (billing, provisioning) to ensure the operation is performed exactly once, even if the request is retried. If a request with the same idempotency key is retried, the server returns the original result instead of duplicating the operation.