Strategy anatomy
Memory slots
In Structure, a strategy often needs to remember values from one evaluation to the next. That remembered information is stored in memory slots.
Memory is part of the revision’s evaluated state. It lets the strategy compare current values with values from prior evaluations without hiding that behavior in an external process.
What memory slots do
Section titled “What memory slots do”Memory slots hold values the strategy will need again later.
Common examples include:
- Rolling numeric values.
- Timestamps such as the last entry or exit time.
- Flags or counters.
- Last observed signal values.
- Other values that help the strategy decide what to do next.
Use memory when the value must survive into a later evaluation. If a value only matters while the current source event is being evaluated, it usually belongs in the graph instead.
In the editor
Section titled “In the editor”You can create memory slots from their dedicated “Memory” pane on the right. This is where you give the memory slot its data type and display name.
You can place Memory Read or Memory Write nodes from the context menu.
After a slot exists, it becomes selectable on the node itself.
Reads, writes, and type discipline
Section titled “Reads, writes, and type discipline”A Memory Read node makes the current value of a memory slot available to the graph.
A Memory Write node stages a new value for the memory slot.
Memory writes are applied after the graph paths for the current source-event container finish evaluating successfully.
During that evaluation, the existing memory value is stable.
If the same subgraph reads from and writes to the same memory slot, every Memory Read in that subgraph uses the value that was already in the slot at the start of the evaluation.
The new value from the Memory Write becomes available only after the subgraph has finished successfully.
For example, suppose a memory slot starts an evaluation with the value 10.
The graph can read 10, compute 11, and stage 11 through a Memory Write.
Any other read of that same slot during the same source-event evaluation still sees 10.
The slot becomes 11 only after the evaluation completes without an error.
If the graph evaluation errors, staged memory writes are not applied.
The memory slot keeps its previous value.
In the example above, an evaluation error would leave the slot at 10.
The value written to a slot must match the slot’s type. This is why memory works closely with typed values and validation:
- A numeric memory slot should receive a value that validates as numeric or decimal behavior where required.
- A boolean memory slot should receive a boolean value.
- A timestamp-like value should be modeled consistently wherever the revision reads or writes it.
Validation errors around memory are useful. They usually point to a mismatch between the value a graph path produced and the type of value the memory slot is allowed to store.
Memory and reproducibility
Section titled “Memory and reproducibility”Memory can affect future evaluations, so it should be easy to explain.
When reviewing a revision, ask:
- What value is this slot remembering?
- Which graph path writes it?
- Which graph path reads it?
- Which state transition or strategy action depends on it?
- Is the slot name specific enough to make its purpose clear?
- If a graph reads and writes the same slot, is it clear that the write affects the next evaluation rather than the current one?
This matters across live deployments, paper deployments, and backtest jobs because memory is part of how the revision’s behavior unfolds over time.
Practical takeaway
Section titled “Practical takeaway”Memory slots should have a clear job. If a value needs to survive into the next evaluation, it belongs in memory. If it only matters for the current evaluation, it usually belongs in the graph instead.