Skip to content

Strategy anatomy

Actions and target-position actions

The Actions pane is the parent configuration surface for strategy actions. A strategy action describes what a strategy should express or do while it is in a given state.

Today, the public strategy action type is the target-position action. A target-position action describes the exposure a strategy wants while it is in a given state. It does not describe every venue order directly. It expresses the target that the current execution path should work toward.

Today, Structure’s public strategy action type is the target-position action. Strategies emit target positions, and the Target Position Executor manages order activity to move account positions toward those targets.

Many strategies are easier to reason about as desired exposure:

  • Flat.
  • Long a specific quantity.
  • Short a specific quantity.
  • Reduce exposure.
  • Hold the current state until a condition changes.

Target positions keep strategy logic focused on intent. The revision describes what position it wants, while the Target Position Executor manages order activity for the selected execution destination.

How target-position actions connect to states

Section titled “How target-position actions connect to states”

A state describes the strategy’s current intent. A strategy action describes what the strategy should express or do while it is in that state. Today, that means a target-position action describes the exposure associated with that intent.

For example:

  • Waiting can target flat or no exposure.
  • Long can target a positive quantity for the instrument.
  • Short can target a negative quantity for the instrument.
  • Reducing exposure can target a smaller position than the current account position.

The exact state names and quantities are strategy-specific. The important boundary is that state-machine logic decides the intent, and target-position actions express the position associated with that intent.

A target-position action can use a typed label from the graph as its quantity. That label should represent a value the strategy author wants to review, such as:

  • A fixed target size.
  • A risk-adjusted size.
  • A value based on Strategy Variables.
  • A value derived from market data and memory.

When a label feeds a target-position action, its type must match what the action expects. Numeric or decimal values are the usual fit for quantities.

What the Target Position Executor evaluates

Section titled “What the Target Position Executor evaluates”

In the current target-position execution path, the selected strategy revision and the Target Position Executor are both part of what users evaluate.

The strategy engine evaluates the revision and emits target positions. The Target Position Executor receives those targets and manages order activity to move account positions toward the latest target positions.

The execution destination depends on the path:

This means a backtest job or paper deployment is not only evaluating the revision’s signal logic. It is also evaluating the current target-position execution path under the selected assumptions.

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.

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. They will be another type of strategy action under the same Actions concept.

Until direct order actions are exposed, avoid modeling a strategy as if it directly manages venue orders. Model the public action path as target positions plus Target Position Executor behavior.

Use the Actions pane to keep the strategy’s state-level output explicit. Today, that means using target-position actions to keep the strategy’s exposure intent explicit. If the state machine says why the strategy changed intent, the target-position action says what exposure that intent should produce.

Once strategy actions are clear, the next question is what values need to survive across evaluations. That is the focus of Memory slots.

For the runtime execution boundary, see Target-position execution model.