Project: OpenFeature (Observability and Analysis / Feature Flagging)
File: 03-evaluation-context.md

title: Evaluation Context description: The specification that defines the structure and expectations of evaluation context. tocmaxheading_level: 4 ](https://github.com/open-feature/spec/tree/main/specification#experimental) The `evaluation context` provides ambient information for the purposes of flag evaluation. Contextual data may be used as the basis for targeting, including rule-based evaluation, overrides for specific subjects, or fractional flag evaluation. The context might contain information about the end-user, the application, the host, or any other ambient data that might be useful in flag evaluation. For example, a flag system might define rules that return a specific value based on the user's email address, locale, or the time of day. The context provides this information. The context can be optionally provided at evaluation, and mutated in . [!NOTE] Field casing is not specified and should be chosen in accordance with language idioms. see: The `evaluation context` structure MUST define an optional `targeting key` field of type string, identifying the subject of the flag evaluation. The targeting key uniquely identifies the subject (end-user, or client service) of a flag evaluation. Providers may require this field for fractional flag evaluation, rules, or overrides targeting specific users. Such providers may behave unpredictably if a targeting key is not specified at flag resolution. The evaluation context MUST support the inclusion of custom fields, having keys of type `string`, and values of type `boolean | string | number | datetime | structure`. see: , The evaluation context MUST support fetching the custom fields by key and also fetching all key value pairs. The evaluation context fields MUST have an unique key. The key uniquely identifies a field in the `evaluation context` and it should be unique across all types to avoid any collision when marshalling the `evaluation context` by the provider. The implementation uses the dynamic-context paradigm. see: The API, Client and invocation MUST have a method for supplying `evaluation context`. API (global) `evaluation context` can be used to supply static data to flag evaluation, such as an application identifier, compute region, or hostname. Client and invocation `evaluation context` are ideal for dynamic data, such as end-user attributes. ](https://github.com/open-feature/spec/tree/main/specification#experimental) The implementation uses the static-context paradigm. see: The API MUST have a method for setting the global `evaluation context`. API (global) `evaluation context` can be used to supply data to flag evaluation, such as (but not limited to) user name, email, or user organization membership changes. The Client and invocation MUST NOT have a method for supplying `evaluation context`. In the static-context paradigm, context is global. The client and invocation cannot supply evaluation context. The API MUST have a method for setting `evaluation context` for a `domain`. In the static-context paradigm, provider specific context can be set using the associated `domain`. The global context is used if there is no matching provider specific context. See , for details. The API MUST have a mechanism to manage `evaluation context` for an associated `domain`. In the static-context paradigm, it's possible to create and remove provider-specific context. See , for details. Evaluation context MUST be merged in the order: API (global; lowest precedence) -> transaction -> client -> invocation -> before hooks (highest precedence), with duplicate values being overwritten. Any fields defined in the transaction `evaluation context` will overwrite duplicate fields defined in the global `evaluation context`, any fields defined in the client `evaluation context` will overwrite duplicate fields defined in the transaction `evaluation context`, and fields defined in the invocation `evaluation context` will overwrite duplicate fields defined globally or on the

Any resulting `evaluation context` from a will overwrite duplicate fields defined globally, on the client, or in the invocation. ```mermaid flowchart LR global("API (global)") transaction("Transaction") client("Client") invocation("Invocation") hook("Before Hooks") global --> transaction transaction --> client client --> invocation invocation --> hook ``` This describes the precedence of all `evaluation context` variants. Depending on the `paradigm`, not all variants might be available in an `SDK` implementation. ](https://github.com/open-feature/spec/tree/main/specification#experimental) The implementation uses the static-context paradigm. see: When the global `evaluation context` is set, the `on context changed` function MUST run. The SDK implementation must run the `on context changed` function on all registered provider that use the global `evaluation context` whenever it is mutated. When the `evaluation context` for a specific provider is set, the `on context changed` function MUST only run on the associated provider. The SDK implementation must run the `on context changed` function only on the provider that is scoped to the mutated `evaluation context`. ](https://github.com/open-feature/spec/tree/main/specification#experimental) `Transaction context` is a container for transaction-specific `evaluation context` (e.g. user id, user agent, IP). Transaction context can be set where specific data is available (e.g. an auth service or request handler) and by using the `transaction context propagator` it will automatically be applied to all flag evaluations within a transaction (e.g. a request or thread). The following shows a possible TypeScript implementation using : ```typescript export class AsyncLocalStorageTransactionContext implements TransactionContextPropagator { private asyncLocalStorage = new AsyncLocalStorage<EvaluationContext>(); getTransactionContext(): EvaluationContext { return this.asyncLocalStorage.getStore() ?? {}; } setTransactionContext(context: EvaluationContext, callback: () => void): void { this.asyncLocalStorage.run(context, callback); } } / This example is based on an express middleware. */ app.use((req: Request, res: Response, next: NextFunction) => { const ip = res.headers.get("X-Forwarded-For") OpenFeature.setTransactionContext({ targetingKey: req.user.id, ipAddress: ip }, () => { // The transaction context is used in any flag evaluation throughout the whole call chain of next next(); }); }) ``` The implementation uses the dynamic-context paradigm. see: The API SHOULD have a method for setting a `transaction context propagator`. If there already is a `transaction context propagator`, it is replaced with the new one. The SDK implements context propagation. A language may not have any applicable way of implementing `transaction context propagation` so the language SDK might not implement context propagation. The API MUST have a method for setting the `evaluation context` of the `transaction context propagator` for the current transaction. If a `transaction context propagator` is set, the SDK will call the with this `evaluation context` and so this `evaluation context` will be available during the current transaction. If no `transaction context propagator` is set, this `evaluation context` is not used for evaluations. This method then can be used for example in a request handler to add request-specific information to the `evaluation context`. A `transaction context propagator` MUST have a method for setting the `evaluation context` of the current transaction. A `transaction context propagator` is responsible for persisting context for the duration of a single transaction. Typically, a transaction context propagator will propagate the context using a language-specific carrier such as , , or another similar mechanism. A `transaction context propagator` MUST have a method for getting the `evaluation context` of the current transaction. This will be used by the SDK implementation when merging the context for evaluating a feature flag. The implementation uses the static-context paradigm. see: The API MUST NOT have a method for setting a `transaction context propagator`. In the static-context paradigm, context is global, so there must not be different contexts between transactions.