fix whitespace

docs/source/guides/llm_router.rst

@@ -4,7 +4,7 @@ LLM Routing
 ==============================================================
 
 
-LLM Router systems are designed to direct incoming queries to the most appropriate model or processing pipeline. The core challenge stems from the complexity of natural language, the wide spectrum of incoming requests, and the ambiguity of task definitions. 
+LLM Router systems are designed to direct incoming queries to the most appropriate model or processing pipeline. The core challenge stems from the complexity of natural language, the wide spectrum of incoming requests, and the ambiguity of task definitions.
 Traditional **performance-based** routing focus on selecting the language model most likely to deliver high-quality responses for each query while staying within cost and latency constraints.
 For **preference-based routing**, instead of predicting raw model quality, it routes incoming query to the option that best aligns with human preferences provided by end users in terms of a route usage config which defines the routing logic and selects the model for each task category.
 
@@ -12,7 +12,7 @@ For **preference-based routing**, instead of predicting raw model quality, it ro
 Arch Router
 -----------
  is a powerful feature in Arch that allows your application to dynamically change the response LLM based on user prompts.
-Arch-Router matches user prompts to high-level task categories specified by developers (e.g., FAQ answer, creative writing, code generation), and routes each query to the corresponding model or pipeline. 
+Arch-Router matches user prompts to high-level task categories specified by developers (e.g., FAQ answer, creative writing, code generation), and routes each query to the corresponding model or pipeline.
 This developer-first approach makes routing decisions more transparent and adaptable, reflecting the practical definitions of quality that matter in production environments.
 
 
@@ -21,11 +21,11 @@ Routing Workflow
 
 #. **Prompt Parsing**
 
-    When a user submits a prompt, Arch analyzes it to determine the most relevant route matching to the context. 
+    When a user submits a prompt, Arch analyzes it to determine the most relevant route matching to the context.
 
 #. **Response Handling**
 
-    After the route has been detected, the Arch Router selects the appropriate model or pipeline to handle the request. 
+    After the route has been detected, the Arch Router selects the appropriate model or pipeline to handle the request.
 
 Arch-Router-1.5B
 -------------------------
@@ -93,7 +93,7 @@ There is a sample configuration below that demonstrates how to set up a prompt t
 .. Note::
     For a complete reference of attributes that you can configure in a prompt target, see :ref:`here <defining_prompt_target_parameters>`.
 
-Route description guide 
+Route description guide
 -------------------------
 
 The model is trained to perform routing on the following Domain-Action Taxonomy: a two-tier hierarchical structure that separates:
@@ -104,25 +104,25 @@ Best practice
 -------------------------
 - **✅ Consistent Naming:**  Route names should align with their descriptions.
 
-  - ❌ Bad:  
+  - ❌ Bad:
     ```json
     {"name": "math", "description": "handle solving, understanding quadratic equations"}
     ```
-  - ✅ Better:  
+  - ✅ Better:
     ```json
     {"name": "quadratic_equation", "description": "solving and explaining quadratic equations"}
     ```
 
-- **✅ Use Nouns:**  
+- **✅ Use Nouns:**
   Preference-based routing benefits from noun-based descriptions, which provide better semantic coverage.
 
 - **✅ Be Specific:**  Avoid vague or overly broad route definitions.
 
-  - ❌ Bad:  
+  - ❌ Bad:
     ```json
     {"name": "math", "description": "math"}
     ```
-  - ✅ Better:  
+  - ✅ Better:
     ```json
     {"name": "math_concepts", "description": "solving math problems and explaining core math concepts"}
     ```
@@ -132,13 +132,13 @@ Unsupported Features
 
 The following features are **not supported** by the Arch-Router model:
 
-- **❌ Multi-Modality:**  
+- **❌ Multi-Modality:**
   The model is not trained to process raw image or audio inputs. While it can handle textual queries *about* these modalities (e.g., "generate an image of a cat"), it cannot interpret encoded multimedia data directly.
 
-- **❌ Function Calling:**  
+- **❌ Function Calling:**
   This model is designed for **semantic preference matching**, not exact intent classification or tool execution. For structured function invocation, use models in the **Arch-Function-Calling** collection.
 
-- **❌ System Prompt Dependency:**  
+- **❌ System Prompt Dependency:**
   Arch-Router routes based solely on the user’s conversation history. It does not use or rely on system prompts for routing decisions.
 
 Remember, working with LLMs is part science, part art. Don't be afraid to experiment and iterate to find what works best for your specific use case.

docs/source/index.rst

@@ -52,6 +52,7 @@ Welcome to Arch!
       guides/prompt_guard
       guides/agent_routing
       guides/function_calling
+      guides/llm_router
       guides/observability/observability
 
   .. tab-item:: Build with Arch