docs: Moved configuration system under about

docs/about/concepts/configuration.md

@@ -0,0 +1,67 @@
+(configuration-concepts)=
+
+# Configuration System
+
+NeMo Gym uses YAML configuration files to define [Model, Resources, and Agent servers](./core-components.md). Each server gets its own configuration block, providing modular control over the entire training environment.
+
+## How Servers Connect
+
+A training environment typically includes all three server types working together. The Agent server config specifies which Model and Resources servers to use by referencing their server IDs. These references connect each training environment together — the Agent knows which Model to call and which Resources to use.
+
+## Config File Locations
+
+Each server type has a dedicated directory with its implementations and their configs:
+
+```text
+# Model Server Config
+responses_api_models/
+  └── openai_model/
+      └── configs/openai_model.yaml
+
+# Resources Server Config
+resources_servers/
+  └── example_simple_weather/
+      └── configs/simple_weather.yaml
+
+# Agent Server Config
+responses_api_agents/
+  └── simple_agent/
+      └── configs/simple_agent.yaml
+```
+
+## Server Block Structure
+
+Each config file defines a server using this structure:
+```yaml
+server_id:                    # Your unique name for this server
+  server_type:                # responses_api_models | resources_servers | responses_api_agents
+    implementation:           # Directory name inside the server type directory
+      entrypoint: app.py      # Python file to run
+      # ... additional fields vary by server type
+```
+
+Different server types have additional required fields (e.g., `domain` for resources servers, `resources_server` and `model_server` for agents). See {doc}`/reference/configuration` for complete field specifications.
+
+Config files in NeMo Gym often use the same name for both server ID and implementation:
+
+```yaml
+example_simple_weather:        # ← Server ID
+  resources_servers:
+    example_simple_weather:    # ← Implementation
+```
+
+These serve different purposes:
+
+- **Server ID** (`example_simple_weather` on line 1): Your chosen identifier for this server instance. Used in API requests and when other servers reference it. You could name it `my_weather` or `weather_prod` instead.
+
+- **Implementation** (`example_simple_weather` on line 3): Must match the folder `resources_servers/example_simple_weather/`. This tells NeMo Gym which code to run.
+
+Examples often use matching names for simplicity, but the two values are independent choices.
+
+---
+
+:::{seealso}
+- {doc}`/reference/configuration` for complete syntax and field specifications
+- {doc}`/troubleshooting/configuration` for troubleshooting configuration related errors
+:::
+

docs/about/concepts/index.md

@@ -26,12 +26,6 @@ Each explainer below covers one foundational idea and links to deeper material.
 Understand how Models, Resources, and Agents remain decoupled yet coordinated as independent HTTP services, including which endpoints each component exposes.
 :::
 
-:::{grid-item-card} {octicon}`gear;1.5em;sd-mr-1` Configuration System
-:link: configuration-management
-:link-type: ref
-Learn how NeMo Gym's three-tier configuration system (YAML → env.yaml → CLI) enables secure secrets management and flexible multi-environment deployments.
-:::
-
 :::{grid-item-card} {octicon}`check-circle;1.5em;sd-mr-1` Task Verification
 :link: task-verification
 :link-type: ref
@@ -44,6 +38,12 @@ Explore how resource servers score agent outputs with `verify()` implementations
 Essential vocabulary for agent training, RL workflows, and NeMo Gym. This glossary defines terms you'll encounter throughout the tutorials and documentation.
 :::
 
+:::{grid-item-card} {octicon}`gear;1.5em;sd-mr-1` Configuration System
+:link: configuration-concepts
+:link-type: ref
+Understand the three-level config pattern and why server IDs and implementations are independent choices.
+:::
+
 ::::
 
 ---
@@ -53,7 +53,7 @@ Essential vocabulary for agent training, RL workflows, and NeMo Gym. This glossa
 :maxdepth: 1
 
 Core Components <core-components>
-Configuration System <configuration-system>
+Configuration System <configuration>
 Task Verification <task-verification>
 Key Terminology <key-terminology>
 ```

docs/get-started/setup-installation.md

@@ -123,14 +123,15 @@ Replace `sk-your-actual-openai-api-key-here` with your real OpenAI API key. This
 - The model must support function calling (most GPT-4 models do)
 - Refer to [OpenAI's models documentation](https://platform.openai.com/docs/models) 🔗 for available models
 
+Refer to {doc}`/reference/configuration` for additional `env.yaml` options.
+
 **Why GPT-4.1?** We use GPT-4.1 for getting started because it provides low latency (no reasoning step) and reliable function calling support out-of-the-box, letting you focus on learning NeMo Gym without configuration complexity.
 
 **Can I use my own model?** Yes! NeMo Gym works with any OpenAI-compatible inference server that supports function calling:
 - **Self-hosted models**: Use vLLM to serve your own models (see the [vLLM setup guide](../how-to-faq.md#how-to-use-nemo-gym-with-a-non-responses-compatible-api-endpoint-like-vllm))
 - **Other providers**: Any inference server that implements the OpenAI API specification
 
 Simply update `policy_base_url`, `policy_api_key`, and `policy_model_name` in your `env.yaml` to point to your chosen endpoint.
-
 :::
 
 :::{dropdown} Optional: Validate your API key before proceeding

docs/index.md

@@ -172,8 +172,18 @@ reference/cli-commands.md
 ```
 
 ```{toctree}
-:caption: Development
+:caption: Reference
 :hidden:
+:maxdepth: 1
 
+Configuration <reference/configuration>
 apidocs/index.rst
 ```
+
+```{toctree}
+:caption: Troubleshooting
+:hidden:
+:maxdepth: 1
+
+troubleshooting/configuration.md
+```