Skip to content

Runtime model

Target-position execution model

Structure’s current public execution path is target-position based. The strategy revision expresses desired exposure. The Target Position Executor manages order activity to move account positions toward that desired exposure.

This model keeps strategy logic focused on intent while keeping execution behavior visible as part of what users evaluate.

At a high level, the current execution loop is:

  1. A source event causes the selected revision to evaluate.
  2. The strategy engine emits the latest target positions.
  3. The Target Position Executor compares target positions with account position state.
  4. The executor manages order activity for the selected execution destination.
  5. Fills and order state update the account state available for monitoring and later evaluation.

The exact order activity depends on the execution destination, venue context, account state, and configured assumptions. The user-facing boundary is stable: the revision emits target positions, and the Target Position Executor manages order activity toward those targets.

Target Position Executor flow The executor turns target positions into order activity for the selected destination without exposing direct venue order control in strategy logic.
Inputs
Target positions Desired exposure from the strategy engine
Account position state Latest live or simulated position context
Constraints or assumptions Live venue constraints or simulator assumptions
Execution component
Target Position Executor Manages order activity toward target positions
Destination
Live exchange gateway Live deployments
Venue Simulator Paper deployments and backtest jobs
Review state
Fills where available Live or simulated execution results
Order state where available Submitted, filled, rejected, canceled, or errored
Account state Positions, balances, margin, and health where supported
Current capability The current public strategy action type emits target positions. Direct order actions are roadmap functionality.
No low-level algorithm claim The user-facing boundary is the intent, execution destination, order activity, and review state.
Legend
  • 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.
  • Run settings Run-provided values, balances, ranges, or assumptions.
  • Target positions Desired exposure emitted by strategy evaluation.

A target position is the strategy’s desired exposure for a particular instrument.

Target positions can represent intent such as:

  • Move toward flat exposure.
  • Move toward a long quantity.
  • Move toward a short quantity.
  • Reduce current exposure.
  • Maintain a target while conditions remain active.

Target positions are not direct venue order instructions. They describe desired account exposure. The Target Position Executor is the component that turns that intent into order activity for the selected execution destination.

The Target Position Executor evaluates the relationship between desired exposure and current account state.

Conceptually, the executor uses:

  • Latest target positions emitted by the strategy revision.
  • Current or simulated account position state.
  • Selected venue and instrument.
  • Connected account or simulated account context.
  • Order state and fills where available.
  • Execution destination.
  • Venue constraints or simulator assumptions.

This is why the current path evaluates both the strategy revision and the Target Position Executor. A backtest job, paper deployment, or live deployment is not only evaluating signal logic; it is also evaluating the current target-position execution path.

The Target Position Executor sends order activity to different destinations depending on the path.

PathData sourceExecution destinationWhat happens to order activity
Live deploymentLive market data serverLive exchange gatewayOrder messages are sent to a live venue through the connected account.
Paper deploymentLive market data serverVenue SimulatorOrder activity is simulated using live market data and simulator assumptions.
Backtest jobHistorical market data serverVenue SimulatorOrder activity is simulated over a historical time range under recorded assumptions.

Live deployments can affect real capital in the connected venue account. Paper deployments and backtest jobs use the Venue Simulator and do not send order messages to the live exchange gateway.

Order activity is the executor’s activity to move account positions toward target positions.

Users may review related information such as:

  • Target exposure.
  • Current account position.
  • Order activity.
  • Fills where available.
  • Order state where available.
  • PnL and margin context where available.
  • Logs, errors, and health signals.

Live exchange gateway order messages are distinct from account position state. The live exchange gateway sends order messages to live venues and receives live venue order messages. Position and balance state is surfaced for monitoring where supported by the venue.

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.

Until direct order actions are exposed, model the current public execution path as:

Strategy revision -> target positions -> Target Position Executor -> execution destination

Target-position execution separates strategy intent from venue-facing order activity. To understand a result, review the selected revision, Strategy Variable values, target positions, account state, execution destination, and either live venue constraints or simulator assumptions.