Strategy anatomy

A strategy revision is the saved version of a strategy that Structure can validate, compile, evaluate, and run through live deployments, paper deployments, and backtest jobs. This section explains the parts of a revision and how they work together.

The model is intentionally explicit. A revision separates calculation, state, intent, persistence, reuse, validation, and runtime preparation so that users can inspect what the strategy is doing and why.

How a revision fits together

At a high level, a revision follows this path:

Source events act as evaluation triggers for the graph paths inside their source-event containers.
The strategy graph computes typed values from event data, other available inputs, constants, memory reads, and derived logic.
Labels expose named typed values for state transitions and strategy actions.
The state machine decides whether the strategy stays in its current state or transitions to another state.
Strategy actions describe what each state should express or do. Today, the public strategy action type is the target-position action.
Memory slots preserve selected values across evaluations.
Groups package reusable graph logic behind typed inputs and outputs.
Validation and compilation turn a valid revision into a stable runtime artifact.

That structure is what lets the same revision be used across live deployments, paper deployments, and backtest jobs while keeping the selected revision, Strategy Variable values, venue, instrument, and run context traceable.

What belongs to the revision

A revision contains the strategy definition that Structure evaluates:

DAG logic in the graph.
Source-event containers and graph paths.
State-machine logic and transition branches.
Strategy actions, currently target-position actions.
Memory slots and group definitions/imports.
Fixed node parameters.
Validation state.
Compile output.
Compiled revision artifact or binary.
Revision-owned venue and instrument.

Strategy Variables are different. They are run-provided values for exposed node parameters. A live deployment, paper deployment, or backtest job can provide Strategy Variable values without changing the saved revision.

Current execution posture

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.

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.

Pages in this section

Strategy graph explains DAGs, graph nodes, source-event containers, labels, validation errors, and draft/revision behavior.
Source events and evaluation explains source-event containers, graph paths, event timing, data access, and evaluation order.
Typed values and labels explains typed values, labels, and Numeric behavior.
State machines explains states, transitions, and the state-machine logic that moves the strategy between them.
Actions and target-position actions explains how the Actions concept currently maps states to desired exposure.
Memory slots explains persistence across evaluations.
Groups explains reusable typed graph interfaces.
Validation and compiled revisions explains validation state, compile output, and compiled revision artifacts.