Structural Premise
XR is built on the premise that execution is a state machine, not a transaction. Every component in the system — orders, positions, strategies, venue connections, FIX sessions — exists in a defined state at all times, and transitions between states are explicit, typed, and auditable. This is a deliberate rejection of the request-response pattern most retail platforms use, where you click "buy" and hope for the best. In XR, an order doesn't just succeed or fail — it moves through a lifecycle that the system tracks, the UI reflects, and the risk engine gates. The same principle extends to multi-leg strategies, where the composite state is derived from its legs rather than assumed, and to venue connections, where degraded or reconnecting states are first-class concepts rather than silent failures. The structural premise is that if something can happen in a trading system, it should have a state, and that state should be visible.
The architecture is notably modern compared to legacy trading platforms. The event bus pattern (XRBus) is a clean separation from the old monolithic order management systems — it makes the module composable and embeddable rather than locked into a single platform. The reducer-based order state machine is another smart choice. Legacy platforms often have order state scattered across multiple services with race conditions everywhere. XR keeps it deterministic and traceable in one place.
The context menu with OCO, stop, and stop-limit orders directly from the ladder is the kind of UX that legacy platforms bury behind multiple screens and dialogs. That alone is a workflow accelerator for active traders.
The price feed with throttling, stale detection, and flash highlighting shows you've thought about real-world conditions — not just the happy path. Legacy systems often just freeze or show stale data silently, which is dangerous.
Structural Integration
Every module in XR is self-contained but communicates through two shared surfaces: the type system and the event bus. The type system acts as a compile-time contract — if riskEngine.ts expects a Position with a strike field, and orderEngine.ts doesn't provide one, the build fails before anything runs. The event bus acts as a runtime contract — modules don't call each other directly, they emit and subscribe to typed events. This means orderEngine doesn't know or care whether fills come from a FIX gateway, a broker API, or a local simulator. It listens for xr:fill-notify and processes whatever arrives. The result is that any module can be replaced, extended, or rewired without cascading changes. The venue router doesn't touch the risk engine. The position manager doesn't touch the strategy builder. They all operate on shared data structures and communicate through shared events, but they never reach into each other's internals.
Architectural Position
XR occupies a specific and intentional position in the trading technology stack: it is the execution layer between the trader and the infrastructure. It is not a broker. It is not a market data provider. It is not an order management system in the back-office sense. It sits above all of those, consuming their services through defined interfaces — price feeds in, order events out, FIX messages translated at the boundary — while owning the experience of building, validating, routing, and monitoring trades. This positioning is what makes it hand-off ready. A platform team doesn't need to refactor XR to integrate it — they need to implement the interfaces XR already defines. The FIX bridge specifies the message format. The venue router specifies the routing contract. The bus specifies every event type and payload shape. XR's architectural position is that of a client to infrastructure services, and it defines the terms of that client relationship through its type system rather than leaving integration to guesswork.