diff --git a/develop-docs/sdk/data-model/event-payloads/contexts.mdx b/develop-docs/sdk/data-model/event-payloads/contexts.mdx
index d12c0c43da2e31..6c6e5ff41a221c 100644
--- a/develop-docs/sdk/data-model/event-payloads/contexts.mdx
+++ b/develop-docs/sdk/data-model/event-payloads/contexts.mdx
@@ -832,3 +832,37 @@ The required field is `package` which should contain the package or framework wh
   }
 }
 ```
+
+## Feature Flag Context
+
+The feature flag context contains information about the flags evaluated prior to an error occurring. Flag evaluation results are placed into the `values` key which is an array of 0 or more flag evaluation result objects.
+
+`flag`
+
+: **Required.** The name of the flag which was evaluated.
+
+- Example: `"feature-is-enabled"`
+
+`result`
+
+: **Required.** The boolean result of flag evaluation.
+
+- Example: `false`
+
+
+### Example Feature Flag Context
+
+```json
+{
+  "contexts": {
+    "flags": {
+      "values": [
+        {
+          "flag": "my_flag_name",
+          "result": true
+        }
+      ]
+    }
+  }
+}
+```
diff --git a/develop-docs/sdk/expected-features/index.mdx b/develop-docs/sdk/expected-features/index.mdx
index 9b88e052a951e5..a5040bbd7f5e81 100644
--- a/develop-docs/sdk/expected-features/index.mdx
+++ b/develop-docs/sdk/expected-features/index.mdx
@@ -91,6 +91,27 @@ Local variable names and values for each stack frame, where possible. Restrictio
 
 This functionality should be gated behind the `includeLocalVariables` option, which is `true` by default.
 
+## Feature Flags
+
+An SDK may expose a Scope property for tracking feature flag evaluations. When the scope forks, it's important to clone the feature flags property. Leaking flag evaluations between threads could lead to inaccurate feature flag evaluation logs.
+
+The Scope's flag property should have a capped capacity and should prefer recently-evaluated flags over less-recently-evaluated flags. The recommended data structure is a LRU-cache but it is not required so long as the data structure behaves similarly. Serious deviations from the behavior of an LRU-cache should be documented for your language.
+
+The Scope's flag property should expose two methods: `get/0` and `set/2`. `set/2` takes two arguments. The first argument is the name of the flag. It is of type string. The second argument is the evaluation result. It is of type boolean. `set/2` should remove all entries from the LRU-cache which match the provided flag's name and append the new evaluation result to the end of the queue. `get/0` accepts zero arguments. The `get/0` method must return a list of serialized flag evaluation results in order of evaluation. Oldest values first, newest values last. See the <Link to="/sdk/data-model/event-payload/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation for details.
+
+### Integrations
+
+Integrations automate the work of tracking feature flag evaluations and serializing them on error context. An integration should hook into third-party SDK and record feature flag evaluations using the current scope. For example, in Python an integration would call `sentry_sdk.get_current_scope().flags.set(...)` on each flag evaluation.
+
+An integration is also responsible for registering an "on error" hook with the Sentry SDK. When an error occurs the integration should request the current scope and serialize the flags property. For example, in Python an integration might define this callback function:
+
+```python
+def flag_error_processor(event, exc_info):
+    scope = sentry_sdk.get_current_scope()
+    event["contexts"]["flags"] = {"values": scope.flags.get()}
+    return event
+```
+
 ## Desymbolication
 
 Turn compiled or obfuscated code/method names in stack traces back into the original. Desymbolication always requires Sentry backend support. Not necessary for many languages.