Runtime model
Strategy engine and compilation model
Structure evaluates saved strategy revisions through the strategy engine. Before a revision reaches runtime evaluation, Structure validates the revision and prepares a compiled revision artifact that the engine can evaluate consistently across live deployments, paper deployments, and backtest jobs.
The user-facing path is:
Draft revision -> validation -> compile output -> compiled revision artifact -> strategy engine evaluation
Users do not write runtime code or manage compilation directly. Users build strategy revisions, resolve validation errors, provide Strategy Variable values for a run, and select the revision for a live deployment, paper deployment, or backtest job.
- 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.
- Revision-owned Immutable strategy revision logic and settings.
- Run settings Run-provided values, balances, ranges, or assumptions.
- Compiled artifact Runtime artifact or binary attached to a validated revision.
Why Structure compiles revisions
Section titled “Why Structure compiles revisions”Compilation creates a stable runtime form of a saved revision.
That matters because Structure needs the same revision to remain traceable across different workflows:
- A backtest job should point to the exact revision and compiled artifact it evaluated.
- A paper deployment should evaluate the selected revision as live market data arrives.
- A live deployment should show which selected revision powers live operation.
- A comparison should keep the revision, Strategy Variable values, runtime path, and assumptions attached.
Compilation is part of that traceability boundary. It helps connect the editable strategy model to the runtime form the strategy engine evaluates.
What validation prepares
Section titled “What validation prepares”Validation checks that a revision is coherent before Structure prepares it for runtime evaluation.
Validation can cover:
- DAG structure and graph paths.
- Type compatibility between node outputs and inputs.
- Labels used by state transitions and strategy actions.
- State-machine branches and reachable states.
- Memory reads and writes.
- Group input and output interfaces.
- Fixed node parameters.
- Required Strategy Variable definitions.
- Revision-owned venue and instrument context.
Validation errors are surfaced in the strategy workflow so users can fix the revision before creating or using a saved revision.
What compilation includes
Section titled “What compilation includes”After validation, Structure compiles the saved revision into a runtime artifact or binary.
Conceptually, the compiled artifact represents:
- DAG logic.
- Source-event containers and graph paths.
- State-machine logic.
- Fixed node parameters.
- Memory definitions.
- Group definitions and imports.
- Strategy actions.
- Revision-owned venue and instrument.
- Compile output attached to the revision.
Structure constructs validated strategy revisions into Rust code for runtime evaluation. From a user perspective, this matters because it gives the revision a concrete runtime form focused on repeatable evaluation, performance, and traceability.
Users do not inspect or edit the generated Rust code as part of normal strategy work. The product surface is the revision, its validation state, compile output, and the runtime behavior observed in jobs and deployments.
Strategy Variable binding
Section titled “Strategy Variable binding”Strategy Variables are run-provided values for exposed node parameters.
The revision defines which parameters are exposed. A live deployment, paper deployment, or backtest job supplies concrete Strategy Variable values when the run is configured.
This separation lets users evaluate the same compiled revision with different run-provided values while keeping the revision’s fixed logic stable.
Strategy engine evaluation
Section titled “Strategy engine evaluation”At runtime, the strategy engine evaluates the selected revision as source events arrive.
Conceptually, the engine:
- Receives the selected compiled revision artifact.
- Applies the Strategy Variable values supplied for the run.
- Evaluates source-event graph paths.
- Reads and writes memory according to the revision model.
- Evaluates state-machine logic.
- Emits target positions.
The target positions then flow to the Target Position Executor, which manages order activity for the selected execution destination.
Consistency across paths
Section titled “Consistency across paths”The same revision model is used across Structure’s three operating 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 path changes the data source, execution destination, account context, assumptions, and lifetime. The selected revision, validation state, compile output, compiled artifact, and Strategy Variable values remain part of the run context users review.
Practical takeaway
Section titled “Practical takeaway”Validation makes a revision coherent. Compilation gives the saved revision a runtime form. The strategy engine evaluates that runtime form and emits target positions.
This is why revisions are stable reference points in Structure: the editable model, validation state, compile output, compiled artifact, and runtime behavior remain connected.