Skip to content

Implementation Notes

This document captures implementation-facing rationale and design considerations for the Live Stack: how real-time runtime execution is realized in practice, how Venue connectivity and operational control are integrated, and what patterns support execution-record persistence and observability.

Why Live Realization Matters

The Live Stack operates at the boundary between the System's deterministic processing model and the real market. Implementation choices here directly affect whether the Core Runtime's architectural guarantees — deterministic Event processing, structured lifecycle management, layered responsibility separation — are preserved through to real-time production execution.

A weak realization (e.g., Venue connectivity that bypasses the Venue Adapter boundary, execution records that are lost on failure, observability that is absent during critical conditions) undermines the System's architectural integrity in the context where it matters most — real trading with real financial consequences.

The implementation patterns described here are designed to ensure that the Live Stack's realization preserves the Core Runtime's processing model while meeting the operational demands of production trading.

Realizing Real-Time Runtime Execution

The Core Runtime processes Events deterministically. In Live mode, Events arrive from real-time Venue market-data feeds rather than from historical datasets. The implementation must bridge live market connectivity and the Core Runtime's Event-processing model without introducing semantic deviation.

Market-data integration. Live Venue feeds deliver data through Venue-specific protocols (WebSocket streams, FIX sessions, REST polling, proprietary APIs). The Live Market Input Handler must normalize this feed-specific traffic into the Event form the Core Runtime expects, without altering the data's semantic content. The implementation must handle:

  • Connection establishment, maintenance, and reconnection for each Venue feed.
  • Protocol-specific message parsing and translation into canonical Event representation.
  • Delivery of Events to the Core Runtime's processing loop with minimal and predictable latency.

Runtime hosting. The Core Runtime runs as a long-lived process during a live session. The implementation must ensure that the runtime environment is stable over session durations that may span hours or full trading days. This includes:

  • Process lifecycle management — clean startup, steady-state execution, and controlled shutdown.
  • Resource stability — memory, CPU, and I/O must remain within predictable bounds during sustained operation.
  • Isolation from infrastructure-level non-determinism — the Core Runtime's processing must not be affected by OS scheduling, garbage collection pauses, or resource contention in ways that alter processing outcomes.

Preserving Core Runtime semantics. The implementation hosts and feeds the Core Runtime but does not modify its processing model. Event processing, State derivation, Risk evaluation, Execution Control, and Order lifecycle behavior operate identically to their canonical definitions. The implementation's responsibility is to provide the real-time context — live inputs, real Venue connectivity — not to alter the processing that occurs within the Core Runtime.

Realizing Venue Connectivity and Operational Control

Venue connectivity

Real Venue interaction requires the Venue Connectivity Layer to manage active, bidirectional connections with one or more Venue APIs. Implementation concerns include:

  • Protocol diversity. Different Venues expose different APIs (FIX, WebSocket, REST, proprietary). The Venue Adapter must translate between the Core Runtime's canonical outbound actions and each Venue's specific protocol, and must translate Venue-specific responses back into canonical Execution Events.
  • Connection resilience. Live Venue connections may experience interruptions, timeouts, or degradation. The implementation must handle reconnection, message deduplication, and sequence recovery without introducing state that the Core Runtime's Event processing cannot account for.
  • Latency sensitivity. Outbound dispatch and inbound feedback are latency-sensitive in live trading. The implementation should minimize unnecessary buffering or processing delay between the Core Runtime's dispatch decisions and actual Venue transmission, and between Venue responses and their re-entry as Execution Events.

Operational control

The Operational Control Surface must be realized as a reliable, accessible interface through which operators and operational tooling can interact with the live trading session. Implementation patterns include:

  • Control channels. API endpoints, command-line interfaces, or message-based control surfaces that accept session lifecycle commands (start, stop), trading controls (enable, disable, kill-switch), and Configuration updates.
  • State visibility. Exposing current session state — trading status, active Strategy, active Configuration, connection status — so that operators can assess the system's condition before issuing control commands.
  • Control safety. Ensuring that control actions are applied reliably and that their effects are reflected in the Core Runtime's processing state. A kill-switch activation, for example, must reliably prevent further outbound dispatch — not merely signal an intent to stop.

Execution-Record and Output Persistence Patterns

Execution records are the Live Stack's durable output. The implementation must ensure that records are written reliably and promptly, not deferred to session end where they would be lost on failure.

Write-as-produced. Execution records — order submissions, Venue acknowledgements, fills, rejections, position updates, dispatch metadata — should be persisted as they are produced during execution. This ensures that a durable record exists even if the session terminates unexpectedly.

Storage surface usage. Records are written to the Data Storage Stack's Execution Record Storage surface. The implementation writes to this surface but does not manage its organization, retention, or access policies. The writing pattern should be compatible with the storage surface's expected access model (e.g., append-oriented writes, partitioned by session or time window).

Traceability. Each persisted record should carry sufficient context to be traceable — which session produced it, which Strategy and Configuration were in effect, which Venue interaction it relates to. This linkage is what makes post-hoc analysis by the Analysis Stack meaningful rather than a disconnected collection of records.

Failure resilience. The persistence path must be robust against transient storage failures. If a write fails, the implementation should buffer and retry rather than silently dropping execution records. The durable record of live execution is not optional — it is the mechanism by which the System retains knowledge of what it did in production.

Monitoring and Observability Integration

The Live Stack emits telemetry for consumption by the Monitoring Stack. Implementation concerns include:

Telemetry emission points. The implementation should expose observability surfaces at key points in the processing flow:

  • Market-data intake — feed connectivity status, message rates, latency.
  • Core Runtime processing — Event processing throughput, Strategy evaluation timing, dispatch decision rates.
  • Venue interaction — outbound request rates, response latency, fill rates, rejection rates, connection health.
  • Operational state — session status, trading enable/disable state, active Configuration.

Emission mechanism. Telemetry may be emitted through metrics libraries, structured logging, event buses, or other emission patterns compatible with the Monitoring Stack's ingestion model. The choice is an implementation decision; the requirement is that telemetry is emitted reliably and with low overhead relative to the Core Runtime's processing.

Non-interference. Observability integration must not interfere with the Core Runtime's processing. Telemetry emission should be non-blocking and should not introduce latency or state changes into the Event processing path.

The Live Stack emits telemetry; the Monitoring Stack owns the monitoring platform. The implementation boundary between the two is the telemetry emission surface — the Live Stack is responsible for what is emitted, not for how it is consumed, displayed, or alerted on.

Implementation Boundaries

Implementation choices, not canonical semantics. The connectivity patterns, control surfaces, persistence strategies, and observability integrations described here are implementation-level concerns. They do not define or modify the Core Runtime's Event, State, or lifecycle semantics.

The Core Runtime is executed, not redefined. The Live Stack's implementation wraps the Core Runtime in a production execution environment. It does not alter the Core Runtime's processing model. Determinism, Event processing, State derivation, and all canonical processing rules are as defined in architecture and concept documents.

No storage governance. The Live Stack writes execution records to the Data Storage Stack's persistent surfaces but does not manage those surfaces, their organization, or their retention policies.

No monitoring ownership. The Live Stack emits telemetry. The Monitoring Stack provides the monitoring platform. The implementation boundary is the emission surface.

No deployment specification. The patterns above describe design considerations and realization approaches. They do not prescribe specific hosting platforms, container runtimes, network topologies, or infrastructure-as-code templates. Those belong in deployment documentation.