Build Portfolio strategies

Portfolio strategies work with collections of assets and target allocations. Availability can depend on your plan.

Use this mode when the central question is which eligible assets should receive which target weights at a scheduled evaluation. A weight is a target portion of the portfolio; it is not a guaranteed holding or return. Start with the Portfolio example if you want a graph to inspect before building one from scratch.

Choose the primary activation

Use one primary Schedule Trigger for regular evaluation. Add Safety Trigger only as an auxiliary guard for a supported breach condition; it does not replace Schedule Trigger or join the primary path.

The control spine is Schedule Trigger → Rebalancer. The other portfolio nodes prepare values for that action through data edges. A Safety Trigger has only supported bounded emergency paths; do not use it to run an alternative general rebalance or to merge into the schedule path. A newly created Portfolio graph already has its primary trigger.

Build the portfolio data path

A typical path defines a Universe, optionally filters it, calculates or combines scores, ranks assets, and produces target weights. Connect compatible data ports even when the control path follows a different route.

Read the preparation path in order:

For example, 50%, 30%, and 20% are three target proportions totaling 100%. The editor does not infer those targets from node placement. A filtered universe can become empty, or a score can be unavailable for the chosen period, even when the diagram looks connected.

Try it here

Explore two strategy modes

Design a scheduled or safety-driven graph that selects assets, calculates weights, applies limits, and rebalances.

Exercise steps

1. Inspect the schedule, universe and target weights in the Portfolio example.
2. Set the allocation budget to 80%; inspect the configuration without submitting a rebalance.

Start lesson

Apply limits before rebalancing

Use Portfolio Constraint and Leverage Constraint where appropriate. Pass valid target weights and available constraints to Rebalancer. Handle constraint, empty-universe, and no-change outcomes explicitly.

Portfolio Constraint supplies restrictions such as allocation limits; Leverage Constraint supplies its supported adjustment when configured. They are data dependencies, not independent scheduled actions. Inspect each node's active Data Ports in the selected configuration. On Rebalancer, distinguish a submitted rebalance from a constraint rejection, empty selection, or no change. Connect outcomes you need to observe or respond to; an unconnected branch can end silently by design.

Verify

Check validation after every change to universe, weights, or constraints. Save before opening the Backtest flow, then review assumptions and costs before submission.

Before simulation, verify the primary control spine, each required data dependency, availability of the chosen instruments and period, and the behavior you expect for an empty universe or blocked constraint. Validation checks the graph; the Backtest then tests its behavior on a specific historical window with configured costs. An unchanged allocation is not automatically an error. If a rebalance is absent, check the recorded outcome and the data path before relaxing a risk limit.