Since the DSL is a high-level abstraction, it passes through a **Compiler/Orchestrator** that translates the logic into execution plans. 

The routing layer decides which engine to use through a combination of **Static Analysis (at compile time)** and **Resource Mapping (at runtime)**.

---

### 1. Static Analysis: The "Consistency Class"
When you write a module in the DSL, the compiler analyzes the **nodes and operators** used to assign a **Consistency Class** to that workflow.

*   **The "Fast Path" Class (Eventual Consistency):**
    If a module uses operators like `Suma`, `Delta`, `Tick`, or `Saga.Eventual`, the compiler tags it as `Consistency: Low`. It is routed to the **Combat Engine** (which prioritizes throughput and low-latency updates).
*   **The "Safe Path" Class (Strong Consistency):**
    If the compiler detects keywords like `Lock()`, `AtomicTransfer`, `Vault`, or `Saga.Atomic`, it automatically upgrades the module to `Consistency: High`. This is routed to the **Trade Engine** (which prioritizes ACID compliance and linearizability).

**Example of the Compiler's logic:**
> *"I see a `Lock` on a `PlayerWallet` and an `AtomicTransfer` call. This cannot be handled by the Fast Path. Routing this entire module to the High-Consistency Cluster."*

---

### 2. Resource-Based Routing (The "Object" Registry)
The routing layer doesn't just look at the *code*; it looks at the **Resource** being accessed. The system maintains a **Global Resource Registry** that defines the required consistency level for every object in the game.

| Resource | Type | Consistency Requirement | Route |
| :--- | :--- | :--- | :--- |
| `WorldBoss.HP` | Global State | Eventual (Delta) | **Combat Engine** |
| `Player.Position` | Spatial State | Eventual (Interpolated) | **Combat Engine** |
| `Player.Inventory` | Asset State | Strong (Atomic) | **Trade Engine** |
| `AuctionHouse.Vault` | Asset State | Strong (Atomic) | **Trade Engine** |

**How the request flows:**
1.  Request arrives: `TradeItem(PlayerA, PlayerB, ItemX)`.
2.  The Router checks the registry: `ItemX` $\rightarrow$ `Asset State` $\rightarrow$ `Strong Consistency`.
3.  The Router redirects the request to the **Trade Engine** cluster.

---

### 3. The "Dispatcher" Architecture
Physically, the routing layer acts as a **Smart Dispatcher** (similar to an API Gateway or a Service Mesh like Istio). It manages two entirely different infrastructure stacks:

#### The "Fast Path" Stack (The Combat Engine)
*   **Hardware:** High-CPU, high-RAM, optimized for computation.
*   **Storage:** In-memory data grids (e.g., Redis, Hazelcast).
*   **Behavior:** "Fire and Forget." It processes deltas and syncs them periodically.
*   **Goal:** Zero-lag interaction.

#### The "Safe Path" Stack (The Trade Engine)
*   **Hardware:** High-I/O, NVMe storage, optimized for disk writes.
*   **Storage:** Distributed SQL databases with Paxos/Raft consensus (e.g., CockroachDB, FoundationDB).
*   **Behavior:** "Confirm then Commit." It uses a two-phase commit to ensure the data is written to multiple nodes before confirming the trade.
*   **Goal:** Zero-loss integrity.

---

### 4. The "Escalation" Trigger (Dynamic Routing)
The most powerful part of this DSL is the ability to **escalate** a request from the Fast Path to the Safe Path in real-time.

**Scenario: The "Critical Hit" Reward**
Imagine a player hits the World Boss. Usually, this is a "Fast Path" event. But the AI determines that this specific hit was a "Legendary One-Shot" that entitles the player to a unique, one-of-a-kind item.

1.  **Combat Engine** handles the hit (Fast Path).
2.  **AI Director** triggers a "Rare Reward" event.
3.  The **Router** detects the `Reward` trigger and **escalates** the workflow.
4.  The flow is shifted from the **Combat Engine** $\rightarrow$ **Trade Engine** to ensure the rare item is minted and delivered with absolute consistency.

### Summary of Routing Logic

| Factor | Fast Path (Combat) | Safe Path (Trade) |
| :--- | :--- | :--- |
| **Trigger** | `Delta`, `Tick`, `Position` | `Lock`, `Vault`, `Atomic` |
| **Resource** | Boss HP, Player XYZ | Inventory, Wallet, Auction |
| **Consistency** | Eventual / Causal | Strong / Linearizable |
| **Infrastructure** | In-Memory $\rightarrow$ Distributed Cache | Distributed DB $\rightarrow$ Consensus Log |
| **Latency** | < 10ms | 50ms - 200ms |
| **Risk Profile** | "A bit of lag is okay" | "A single error is a disaster" |