Project: OpenFeature (Observability and Analysis / Feature Flagging)
File: glossary.md

title: Glossary description: A list of terms used within the OpenFeature specification. sidebar_position: 1 This document defines some terms that are used across this specification. <details> <summary>Table of Contents</summary> <!-- toc --> - - - - - - - - - - - - - - - - <!-- tocstop --> </details> A mechanism that allows an Application Author to define alternative codepaths within a deployed piece of software, which is conditionally executed at runtime, based on a rule set. A developer of an application or service which utilizes the feature flags SDK. This person writes code which calls into the SDK to make flagging decisions. A developer who is setting up or configuring an application or service to use the feature flags SDK. They would write code like "We should speak to the open source flagging service, not $vendor" or "The way the system should handle telemetry is through $library". The maintainer of an API-compliant which implements the necessary interfaces required for flag evaluation. The maintainer of an API-compliant integration which implements additional secondary functionality besides flag evaluation. The maintainer of a shared library which is a dependency of many applications or libraries, which utilizes the feature flags SDK to allow consumers to manage library functionality. The libraries used by the Application Author to implement feature flags in their application or service. The interfaces defined in these libraries adhere to the Feature Flag API. An SDK which is built for usage in client applications (e.g. single-page web applications), and typically uses the . An SDK which is built for usage in server applications (e.g. REST services), and typically uses the . The interfaces and abstractions used by authors (Application, Integration, Provider). Provider & Integration authors adhere to the API to add support for their feature flag implementation or integration. Application authors use it via the Feature Flag SDK. The subset of the that the Application Author uses to evaluate flags. A source-of-truth for flag values and rules. Flag management systems may include SaaS feature flag vendors, custom "in-house" feature flag infrastructure, or open-source implementations. A lightweight abstraction that provides functions to evaluate feature flags. A client is associated with a single provider, which it uses to perform evaluations. An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the as an abstraction for the system in question. The possible states and transitions of a provider over the course of its usage, as defined by the . An identifier which logically binds clients with providers, allowing for multiple providers to be used simultaneously within a single application. Domain binding is dynamic; it may change over the course of an application's lifetime (ie: a client associated to the default provider via an unbound domain will be bound to a new provider if a provider is subsequently assigned to that domain). An SDK-compliant secondary function that is abstracted by the Feature Flag API, and requires only minimal configuration by the Application Author. Examples include telemetry, tracking, custom logging and monitoring. Context object for flag evaluation, which may contain information about the runtime environment, details of the transport method encapsulating the flag evaluation, the host, the client, the subject (user), etc. This data may be used as a basis for differential evaluation of feature flags based on rules that can be defined in the flag

Context data may be provided by merging static global context, arguments to flag evaluation, and implicit language-dependant state propagation mechanisms (thread-local storage, promise chains, continuations, etc). An SDK-compliant implementation that stores and returns transaction-specific evaluation context. A transaction might be a web request or application event, which carries its contextual data in a thread or continuation storage. The process of retrieving a feature flag value in it's entirety, including: any effects resulting from hooks resolving a flag value from a configured provider falling back to a supplied default, in the case of abnormal execution The process of a provider retrieving a feature flag value from it's particular source-of-truth. ```mermaid erDiagram Flag ||--|{ variant: "has many" variant ||--|| value: "has" Flag ||--o{ rule: "Has zero or many" rule }|--|{ variant : "links to many" ``` Flags represent a single pivot point of logic. Flags have a type, like `string`, `boolean`, `json`, etc. Examples: `redesign_enabled` or `header-order` A string that logically identifies a particular flag. A variant is a semantic identifier for a value. This allows for referral to particular values without necessarily including the value itself, which may be quite prohibitively large or otherwise unsuitable in some cases. Individual variants have values associated with them. These values adhere to the flag's type. For the `header-order` variants, we may have values like: ```text reverse: [5,4,3,2,1] wonky: [3,5,2,1,4] standard: [1,2,3,4,5] ``` The application of rules, specific user overrides, or fractional evaluations in feature flag resolution. A string logically identifying the subject of evaluation (end-user, service, etc). Pseudorandomly resolve flag values using a context property, such as a targeting key, based on a configured proportion or percentage (ie: 50/50). A rule is some criteria that's used to determine which variant a particular context should be mapped to. Feature flag frameworks have SDKs which operate in two distinct paradigms: those designed for use with a single user client application (e.g. mobile phones, single-page web apps), and those designed for multi-user applications, such as web server applications. Some parts of the OpenFeature specification diverge depending on the paradigm. Server-side applications typically perform flag evaluations on behalf of many users, with each request or event being associated with a particular user or client. For this reason, server frameworks typically operate similarly to this: the application is initialized with some static context (geography, service name, hostname, etc) with each request or event, relevant dynamic context (for example, user session data, unique user identifiers) is provided to flag evaluations In contrast to server-side or other service-type applications, client side applications typically operate in the context of a single user. Most feature flagging libraries for these applications have been designed with this in mind. Frequently, client/web libraries operate similarly to this: an initialization occurs, which fetches evaluated flags in bulk for a given context (user) the evaluated flags are cached in the library flag evaluations take place against this cache, without a need to provide context (context was already used to evaluate flags in bulk) libraries provide a mechanism to update context (e.g. if a user logs in), meaning cached evaluations are no longer valid and must be re-evaluated, frequently involving a network request or I/O operation Not all client libraries work this way, but generally, libraries that accept dynamic context per evaluation can build providers which conform to this model with relative ease, while the reverse is not true.