Execution Routing¶

Design draft

This section defines the target Routing Manager and TCP API contract. It is not implemented yet.

Execution Routing is the single source of truth for deciding how opening and closing requests continue. Routing selects a target but never executes or mutates a trade.

Trade request
    ↓
DealerPolicyService: normalize and preprocess
    ↓
ExecutionRoutingService: resolve from an immutable cache snapshot
    ├─ INTERNAL        → existing execution flow
    ├─ MANUAL_DEALER   → Dealing Center → confirmation → existing flow
    ├─ VIRTUAL_DEALER  → Virtual Dealer → confirmation → existing flow
    └─ REJECT          → reject request

GATEWAY is reserved for a later version and is not accepted by version 1 API.

Principles¶

Routing is evaluated before a request enters the current execution flow.
The main loop keeps responsibility for account, position, margin, persistence, and event invariants.
Routes are evaluated deterministically by priority ASC, route_id ASC.
The first matching enabled route wins.
No match falls back to SYSTEM_DEFAULT → INTERNAL.
GroupRecordSec.execution and confirmation are deprecated and stop participating after Routing is enabled.
Every resolution records route id, name, target, and snapshot version for audit.

Access¶

Planned permission	Purpose
`see_execution_routes`	List routes and run dry-run resolution
`manage_execution_routes`	Create, update, delete, enable, disable, and reorder routes

Administrators receive both permissions. Dealers normally receive read and dry-run access. Mutation requires BackOffice scope and manage_execution_routes.