Strategy anatomy
Strategy graph
In Structure, most of a strategy is built in its graph. The graph is where you wire together the values, logic, and typed outputs that shape a revision’s behavior.
The graph behaves like a DAG: values flow through connected nodes, and downstream nodes depend on the values produced upstream. That makes the calculation path inspectable. A user can trace how an input becomes a signal, how a signal becomes a state-transition condition, and how a label becomes the quantity used by a strategy action.
Strategy view overview
Section titled “Strategy view overview”Opening a strategy revision takes you to the strategy view.
The strategy view is composed of four distinct areas:
- Chat panel on the far left: collaborate on strategy changes and review suggested edits where chat assistance is available.
- Strategy details on the left: edit strategy metadata, switch revisions, and create new revisions.
- Canvas in the center: build or inspect source-event containers, graph paths, nodes, and labels.
- Settings panes on the right: define revision settings that belong outside the graph canvas, such as states, strategy actions, memory slots, and other structured configuration.
Nodes, edges, and labels
Section titled “Nodes, edges, and labels”Graph nodes represent typed operations or values. Examples include constants, accessors, computations, memory reads, memory writes, and group imports.
Edges connect node outputs to node inputs. An edge is not just a visual line; it says that one value depends on another value. Structure uses those dependencies to evaluate the graph in an order that respects the data flow.
Labels are named typed outputs from the graph. They are important because they form the interface between graph calculations and other parts of the revision:
- A state-transition branch can use a
Boollabel as its condition. - A target-position action, the current public strategy action type, can use a numeric label as its quantity.
- A label can make an intermediate value easier to inspect and reuse.
Use labels for values that need to leave the local graph path and become part of the strategy’s state-machine logic or strategy action logic.
Source-event containers
Section titled “Source-event containers”Graph logic lives inside the large source-event containers on the canvas. A source event is the trigger that tells Structure when to evaluate the graph paths inside that container.
The source event determines when calculations run. The graph nodes determine what data is read and computed at that time. The event may include data the graph uses directly, such as a market data update, or it may simply cause the graph to read other available values at that moment.
For example, a strategy might recompute a statistic for instrument A whenever the book for instrument B updates, even if the strategy never trades instrument B. In that case, the source event is the book update for instrument B, while the graph paths inside the container decide which values to read, compute, label, or store.
Inside a source-event container, each disconnected starting node acts as the beginning of its own graph path. When that source event fires, Structure evaluates the graph paths for that container.
The placement of a node on the canvas does not define evaluation order by itself. The dependencies between nodes define what must be available before another node can evaluate.
For a deeper explanation, see Source events and evaluation.
Validation errors
Section titled “Validation errors”When you are building a revision, validation errors may appear in the error pane at the bottom of the strategy view.
Clicking the error pane expands it and shows details about the validation failure.
In this example, a numeric memory-slot type is being fed an integer value. The fix is to feed a decimal typed value, such as ConstDecimal, into the Memory Write node.
Validation is part of the strategy model. It checks that graph structure, types, labels, memory writes, state transitions, and strategy actions are internally consistent before the revision is saved or prepared for runtime evaluation.
Drafts and saved revisions
Section titled “Drafts and saved revisions”Every strategy opens in the special Draft revision by default.
The draft is where you can make changes before creating a saved revision.
Saved revisions are immutable. If you attempt to make a meaningful edit that conflicts with the current draft, Structure may show a divergence warning.
This warning means the current draft is incompatible with the change you are trying to make, and continuing will replace the current draft work in progress. If the draft is empty or does not contain important work, you can proceed. If it contains meaningful work, finish that draft and create a saved revision first.
Practical takeaway
Section titled “Practical takeaway”The graph is the calculation layer of a revision. If its nodes, labels, and source-event containers are clear, the state machine and strategy actions become much easier to understand.