[Feature Flags] Add core concepts folder

config/_default/menus/main.en.yaml

@@ -6047,6 +6047,46 @@ menu:
       parent: feature_flags
       identifier: feature_flags_server
       weight: 2
+    - name: Concepts
+      url: feature_flags/concepts
+      parent: feature_flags
+      identifier: feature_flags_concepts
+      weight: 3
+    - name: Environments
+      url: feature_flags/concepts/environments
+      parent: feature_flags_concepts
+      identifier: feature_flags_concepts_environments
+      weight: 301
+    - name: Variants and Flag Types
+      url: feature_flags/concepts/variants_and_flag_types
+      parent: feature_flags_concepts
+      identifier: feature_flags_concepts_variants
+      weight: 302
+    - name: Targeting Rules and Filters
+      url: feature_flags/concepts/targeting_rules
+      parent: feature_flags_concepts
+      identifier: feature_flags_concepts_targeting_rules
+      weight: 303
+    - name: Traffic Splitting and Randomization
+      url: feature_flags/concepts/traffic_splitting
+      parent: feature_flags_concepts
+      identifier: feature_flags_concepts_traffic_splitting
+      weight: 304
+    - name: Distribution Channels
+      url: feature_flags/concepts/distribution_channels
+      parent: feature_flags_concepts
+      identifier: feature_flags_concepts_distribution_channels
+      weight: 305
+    - name: Flag History
+      url: feature_flags/concepts/flag_history
+      parent: feature_flags_concepts
+      identifier: feature_flags_history
+      weight: 306
+    - name: MCP Server
+      url: feature_flags/concepts/feature_flag_mcp_server
+      parent: feature_flags_concepts
+      identifier: feature_flags_mcp_server
+      weight: 307
     - name: .NET
       url: feature_flags/server/dotnet
       parent: feature_flags_server
@@ -6077,16 +6117,6 @@ menu:
       parent: feature_flags_server
       identifier: feature_flags_server_ruby
       weight: 206
-    - name: Flag History
-      url: feature_flags/history
-      parent: feature_flags
-      identifier: feature_flags_history
-      weight: 6
-    - name: MCP Server
-      url: feature_flags/feature_flag_mcp_server
-      parent: feature_flags
-      identifier: feature_flags_mcp_server
-      weight: 8
     - name: Guides
       url: feature_flags/guide
       parent: feature_flags

content/en/feature_flags/_index.md

@@ -11,6 +11,9 @@ further_reading:
 - link: "/getting_started/feature_flags/"
   tag: "Documentation"
   text: "Getting started with Feature Flags"
+- link: "/feature_flags/concepts/"
+  tag: "Documentation"
+  text: "Learn the core concepts of Feature Flags"
 - link: "/feature_flags/client/"
   tag: "Documentation"
   text: "Set up Feature Flags for client-side applications"

content/en/feature_flags/client/_index.md

@@ -28,7 +28,7 @@ Datadog supports these testing approaches:
 - **Integration tests**: Point `DatadogProvider` at a dedicated test environment and control flag values from the Datadog UI. This exercises the real provider end-to-end, including the CDN-delivered flag assignments.
 - **Unit tests**: Swap `DatadogProvider` for OpenFeature's standard `InMemoryProvider` (or an equivalent test stub, where no in-memory provider is available in the language) and set flag values directly in test code. This keeps tests hermetic and offline.
 
-This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.
+This section covers the in-memory approach. Because the OpenFeature API is designed to make providers swappable at runtime, your application code does not change — only the provider registered during test setup.
 
 A typical test follows this pattern:
 
@@ -71,4 +71,6 @@ const evaluationContext = {
 
 ## Further reading
 
+For percentage-based rollouts and deterministic bucketing, see [Traffic Splitting and Randomization](/feature_flags/concepts/traffic_splitting/).
+
 {{< partial name="whats-next/whats-next.html" >}}

content/en/feature_flags/concepts/_index.md

@@ -0,0 +1,16 @@
+---
+title: Concepts
+description: Learn the core concepts and fundamentals of Datadog Feature Flags.
+---
+
+Learn how Datadog Feature Flags work and how to configure flags, environments, targeting, and governance.
+
+{{< whatsnext desc=" " >}}
+    {{< nextlink href="/feature_flags/concepts/environments" >}}Environments{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/variants_and_flag_types" >}}Variants and Flag Types{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/targeting_rules" >}}Targeting Rules and Filters{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/traffic_splitting" >}}Traffic Splitting and Randomization{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/distribution_channels" >}}Distribution Channels{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/flag_history" >}}Flag History{{< /nextlink >}}
+    {{< nextlink href="/feature_flags/concepts/feature_flag_mcp_server" >}}Feature Flags MCP Server{{< /nextlink >}}
+{{< /whatsnext >}}

content/en/feature_flags/concepts/distribution_channels.md

@@ -0,0 +1,46 @@
+---
+title: Distribution Channels
+description: Control which SDKs receive your feature flag configuration with distribution channels.
+further_reading:
+- link: "/feature_flags/concepts/variants_and_flag_types"
+  tag: "Documentation"
+  text: "Variants and Flag Types"
+- link: "/feature_flags/client/"
+  tag: "Documentation"
+  text: "Client-Side SDKs"
+- link: "/feature_flags/server/"
+  tag: "Documentation"
+  text: "Server-Side SDKs"
+---
+
+## Overview
+
+Distribution channels control which SDKs receive your flag configuration. When you create or edit a flag, you can set distribution channels to **Client**, **Server**, or both.
+
+## Why use distribution channels
+
+Use distribution channels to protect sensitive configuration and reduce payload size.
+
+### Protect sensitive configuration
+
+Client-side SDKs fetch flag configuration over the network. Flag keys and variant values sent to client SDKs can be visible in API requests. Restrict server-only flags to the **Server** distribution channel to avoid exposing sensitive flag keys or variant values to client SDKs.
+
+### Reduce payload size
+
+If you work with a large number of feature flags, limiting which flags each SDK type receives can reduce the size of the configuration payload. This can improve performance for client and server SDK initialization.
+
+## Configure distribution channels
+
+When you [create a feature flag][1], select which distribution channels should receive the flag:
+
+- **Client**: Client-side SDKs only (browser and mobile)
+- **Server**: Server-side SDKs only
+- **Both**: All SDK types
+
+You can also update distribution channels on an existing flag from the **Manage Implementation & Variants** section of the flag details page.
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://app.datadoghq.com/feature-flags/create

content/en/feature_flags/concepts/environments.md

@@ -0,0 +1,103 @@
+---
+title: Environments
+description: Learn how Datadog Feature Flags environments isolate flag configuration across deployment stages.
+further_reading:
+- link: "/getting_started/feature_flags/"
+  tag: "Documentation"
+  text: "Getting Started with Feature Flags"
+- link: "/feature_flags/concepts/variants_and_flag_types"
+  tag: "Documentation"
+  text: "Variants and Flag Types"
+- link: "/feature_flags/concepts/targeting_rules"
+  tag: "Documentation"
+  text: "Targeting Rules and Filters"
+---
+
+## Overview
+
+Environments represent different deployment stages or modes in your software delivery life cycle, such as Development, Staging, and Production. Flag configuration is isolated by environment. A flag can be enabled, disabled, overridden, or given targeting rules in one environment without affecting other environments.
+
+## Manage environments
+
+Manage environments from **Feature Flags > Settings > Environments**:
+
+{{< img src="getting_started/feature_flags/environments-list.png" alt="Environments list in Feature Flags settings." style="width:100%;" >}}
+
+### Add an environment
+
+1. Navigate to [**Feature Flags > Settings > Environments**][1].
+2. Click **Create Environment**.
+3. Configure the environment name, queries, and whether it is a production environment.
+
+### Edit an environment
+
+1. Navigate to [**Feature Flags > Settings > Environments**][1].
+2. Click the environment you want to edit.
+3. Update the environment settings and save.
+
+### Delete an environment
+
+1. Navigate to [**Feature Flags > Settings > Environments**][1].
+2. Hover over the environment you want to delete, then click the trash icon.
+
+## Default environments
+
+By default, Datadog creates three environments for your organization:
+
+- **Development**
+- **Staging**
+- **Production**
+
+You can modify these environments or add new ones to match how your team ships code.
+
+## Production environments
+
+Mark an environment as **production** to indicate that changes in that environment can affect customers. Production environments support additional governance controls, such as required change approvals.
+
+## Environment queries
+
+Each environment is configured with a **name** and a set of **queries**. Queries are the `env` or `DD_ENV` strings your applications send at runtime.
+
+Having multiple queries per environment lets you keep the `env` value consistent with the environment you pass to RUM, APM, or StatsD. For example, you might have `staging-eu` and `staging-us` as separate `env` values in your telemetry, but map both to a single **Staging** environment in Feature Flags. That way, you do not need to duplicate flag configuration across multiple Staging environments when you want to enable a flag across all of Staging.
+
+## Connect environments in the SDK
+
+The `env` value you use must match a query configured for the Feature Flags environment you want, such as `staging-us` or `production`. If you already set `env` or `DD_ENV` for RUM, APM, or tracing, use the **same value** for Feature Flags.
+
+### Client-side applications
+
+Set `env` when you initialize the Datadog OpenFeature provider (same value as RUM):
+
+```javascript
+import { DatadogProvider } from '@datadog/openfeature-browser';
+import { OpenFeature } from '@openfeature/web-sdk';
+
+const provider = new DatadogProvider({
+  clientToken: '<CLIENT_TOKEN>',
+  applicationId: '<APPLICATION_ID>',
+  site: 'datadoghq.com',
+  env: 'staging-us', // Must match an environment query in Feature Flags
+  service: '<SERVICE_NAME>',
+  version: '1.0.0',
+});
+
+await OpenFeature.setProviderAndWait(provider);
+```
+
+### Server-side applications
+
+Set `DD_ENV` in your deployment environment (shell, container, or orchestrator), not in application code:
+
+{{< code-block lang="bash" >}}
+export DD_ENV=staging-us  # Must match an environment query in Feature Flags
+export DD_SERVICE=<YOUR_SERVICE_NAME>
+export DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true
+{{< /code-block >}}
+
+This applies to Python, Go, Java, Node.js, Ruby, and .NET server SDKs. See [Server-Side Feature Flags](/feature_flags/server/) for language-specific setup.
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://app.datadoghq.com/feature-flags/settings/environments

content/en/feature_flags/feature_flag_mcp_server.md → content/en/feature_flags/concepts/feature_flag_mcp_server.md

@@ -1,6 +1,8 @@
 ---
 title: Feature Flags MCP Server
 description: "Learn how to use the Feature Flags toolset in the Datadog MCP Server"
+aliases:
+  - /feature_flags/feature_flag_mcp_server
 further_reading:
 - link: "getting_started/feature_flags"
   tag: "Documentation"

content/en/feature_flags/history.md → content/en/feature_flags/concepts/flag_history.md

@@ -1,6 +1,8 @@
 ---
 title: Feature Flag History
 description: "Track and manage the history of your feature flags"
+aliases:
+  - /feature_flags/history
 further_reading:
 - link: "/getting_started/feature_flags/"
   tag: "Documentation"