Runtime model
System architecture overview
Structure runs strategy revisions through three operating paths:
- Live deployments use live market data and send order messages to a live venue through a live exchange gateway.
- Paper deployments use live market data and simulated execution through the Venue Simulator.
- Backtest jobs use historical market data and simulated execution through the Venue Simulator.
In the current target-position execution path, the strategy revision and Target Position Executor are both part of what users evaluate. The data source, execution destination, account context, and run lifetime change by path.
Direct order actions are roadmap functionality. When introduced, they will let strategies place, cancel, and modify orders directly for strategies that need order-level control.
- Market data Live or historical market data sources.
- Strategy engine Runtime evaluation of the selected compiled revision.
- Target Position Executor Target-position intent converted into order activity.
- Live exchange gateway Venue-facing live order message boundary.
- Venue Simulator Simulated execution destination and assumptions.
- Account state Live or simulated positions, fills, balances, and order state.
- Results Recorded metrics, telemetry, and review context.
- Live path Long-running live deployment or live venue boundary.
- Paper path Long-running paper deployment boundary.
- Backtest path Finite backtest job boundary.
Runtime components
Section titled “Runtime components”Structure separates the trading workflow into six major runtime components.
| Component | Role |
|---|---|
| Live market data server | Streams current venue market data into live deployments and paper deployments. |
| Historical market data server | Streams historical market data into backtest jobs. |
| Strategy engine | Evaluates the selected compiled strategy revision and emits target positions. |
| Target Position Executor | Receives target positions and manages order activity for the selected execution destination. |
| Live exchange gateway | Sends order messages to live venues and receives live venue order messages. |
| Venue Simulator | Provides simulated execution for paper deployments and backtest jobs. |
Operating paths
Section titled “Operating paths”Live deployment
Section titled “Live deployment”Live market data server -> Strategy engine -> Target Position Executor -> Live exchange gateway
A live deployment is a long-running path. It receives live market data, evaluates the selected strategy revision, and routes order activity through the live exchange gateway for the connected venue account. The live path interprets target positions against live account state, venue permissions, live venue constraints, fills, order state, and health signals where available.
Paper deployment
Section titled “Paper deployment”Live market data server -> Strategy engine -> Target Position Executor -> Venue Simulator
A paper deployment is also a long-running path. It receives live market data and evaluates real-time strategy behavior, but order activity goes to the Venue Simulator instead of a live venue. The paper path evaluates the selected revision and current Target Position Executor behavior under simulated account state and simulator assumptions.
Backtest job
Section titled “Backtest job”Historical market data server -> Strategy engine -> Target Position Executor -> Venue Simulator
A backtest job is finite. It starts with a configured historical time range, runs the selected revision through that range, records results, and terminates when the requested evaluation completes or fails. The backtest path evaluates the selected revision and current Target Position Executor behavior against historical market data, starting balances, and recorded simulator assumptions.
Conceptual message flow
Section titled “Conceptual message flow”The runtime uses a small set of message categories across the paths.
| Message category | What it represents |
|---|---|
| Market data messages | Price, trade, funding, or other market inputs available to the strategy revision. |
| Strategy evaluation messages | The strategy engine’s evaluation of the selected revision against incoming data. |
| Target position messages | The strategy’s desired exposure after evaluation. |
| Order activity messages | The Target Position Executor’s order activity based on current account state and target positions. |
| Account state messages | Live or simulated account balances, positions, fills, and order state surfaced for review. |
| Result and telemetry messages | Job status, deployment health, logs, metrics, assumptions, and run context. |
The exact fields vary by path and venue. The important user-facing boundary is stable: Structure keeps strategy logic, market data, target-position intent, execution destination, account state, and result telemetry separate enough to review.
For the detailed execution boundary, see Target-position execution model and Execution context and account state.
Lifecycle states
Section titled “Lifecycle states”Live deployments and paper deployments keep running until the user stops them or a failure path ends the deployment.
Common deployment lifecycle states:
drafting: the deployment parameters are being specified by the user.provisioning: Structure is preparing the selected revision and runtime path.running: the deployment is active.stopping: Structure is shutting the deployment down.stopped: the deployment is no longer running.failed: the deployment could not start or continue.
Backtest jobs are finite evaluations.
Common backtest job lifecycle states:
drafting: the user is filling out the job parameters.provisioning: Structure is preparing the selected revision and runtime path.running: historical data is driving the selected revision.completed: the job finished and results are available.failed: the job stopped before completion and exposes an error reason where available.
Strategy revisions and Strategy Variables
Section titled “Strategy revisions and Strategy Variables”A strategy revision contains the strategy model that Structure evaluates: DAG logic, state-machine logic, fixed node parameters, validation state, compile output, and the compiled revision artifact used by the runtime. Structure constructs validated strategy revisions into Rust code for runtime evaluation. Users do not manage that code directly, but the compiled revision artifact and compile output stay connected to the saved revision.
Strategy Variables are run-provided values for node parameters exposed by the strategy author. A live deployment, paper deployment, or backtest job can provide concrete Strategy Variable values without changing the revision’s fixed logic.
Venue and instrument are revision-owned parameters. A run shows those values with the deployment or job context so users can understand what was evaluated or operated.
Failure handling overview
Section titled “Failure handling overview”Structure exposes failures at the workflow surface where users can act on them.
| Failure area | What users review |
|---|---|
| Strategy validation or compile failure | The revision, validation state, and error detail available in the strategy workflow. |
| Market data gap | The requested range, available complete segments, and any result caveats for affected backtest jobs. |
| Backtest job failure | The job status, selected revision, time range, Strategy Variable values, simulator settings, and error detail where available. |
| Paper deployment issue | Deployment status, live market data availability, simulator context, logs, and health state. |
| Live deployment issue | Deployment status, connected account, venue messages, order state, permissions, logs, and health state. |