Reference
Strategy model
Structure represents strategy logic as explicit, versioned strategy revisions.
A revision is the object Structure evaluates in live deployments, paper deployments, and backtest jobs. The same revision model moves through validation, compilation, evaluation, promotion, monitoring, and revision. After validation, Structure prepares a compiled revision artifact for runtime evaluation by the strategy engine.
What a strategy revision contains
Section titled “What a strategy revision contains”A strategy revision contains the parts of the strategy that define its behavior:
- DAG logic.
- State-machine logic.
- Fixed node parameters.
- Validation state.
- Compile output.
- Compiled revision artifact.
- Revision-owned venue and instrument.
The revision is stable once saved. To change the strategy, create a new revision.
DAG logic
Section titled “DAG logic”The DAG represents the strategy’s computed values and dependencies.
It can include:
- Source events.
- Accessors.
- Typed computations.
- Derived values.
- Memory reads and writes.
- Values used by state transitions.
- Values used by strategy actions.
DAG structure makes the calculation path inspectable. Users can review which inputs feed a value and how that value contributes to strategy behavior.
State-machine logic
Section titled “State-machine logic”State-machine logic represents the strategy’s named behavioral states and transitions.
For example, a strategy can define states such as:
- Flat.
- Long.
- Short.
- Waiting.
- Reducing exposure.
The actual states are strategy-specific. The important model boundary is that state transitions describe when the strategy changes intent, while target positions describe the exposure associated with that intent.
Fixed node parameters and Strategy Variables
Section titled “Fixed node parameters and Strategy Variables”Structure separates fixed node parameters from Strategy Variables.
| Term | Meaning |
|---|---|
| Fixed node parameter | A value saved inside the strategy revision. Changing it creates a new revision. |
| Strategy Variable | A run-provided value for an exposed node parameter. Users provide concrete values when starting a live deployment, paper deployment, or backtest job. |
Use fixed node parameters for values that define the revision’s logic. Use Strategy Variables for values that the strategy author intentionally exposes for run configuration.
This separation lets users evaluate the same revision with different run-provided values while preserving revision traceability.
TargetPositions and actions
Section titled “TargetPositions and actions”TargetPositions express the strategy’s desired exposure.
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.
Today, Structure’s public strategy action type is the target-position action. 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.
Runtime paths
Section titled “Runtime paths”The same strategy revision can be used across three paths.
| Path | Data source | Execution destination | Lifetime |
|---|---|---|---|
| Live deployment | Live market data server | Live exchange gateway | Long-running deployment |
| Paper deployment | Live market data server | Venue Simulator | Long-running deployment |
| Backtest job | Historical market data server | Venue Simulator | Finite job |
The revision model stays fixed. The path changes the data source, execution destination, and lifetime.
Validation and compilation
Section titled “Validation and compilation”Validation checks that the revision is internally consistent before Structure evaluates it.
Validation can cover concepts such as:
- Graph structure.
- Type compatibility.
- State-machine consistency.
- Strategy action declarations.
- Required Strategy Variable values.
- Revision-owned venue and instrument context.
After validation, Structure compiles the revision for runtime evaluation. The compiled revision artifact is the runtime form of the saved revision, and compile output remains part of revision traceability.
Structure constructs validated strategy revisions into Rust code for runtime evaluation. Users do not manage that code directly; the user-facing objects are the saved revision, validation state, compile output, compiled artifact, and observed runtime behavior.
For the deeper architecture view, see Strategy engine and compilation model.
How the model supports comparison
Section titled “How the model supports comparison”Because revisions are stable, users can compare:
- One revision against another.
- Fixed node parameter changes.
- Strategy Variable values used by specific runs.
- Backtest job results.
- Paper deployment behavior.
- Live deployment behavior.
Comparison is useful only when the revision and run context remain attached to the result.