Strategy Workflow

A strategy moves through distinct research, test, library, publication, and operating states. No single button performs the entire lifecycle, and each consequential transition has its own review step.

1. Define the idea

State the assets, timeframe, entry, exit, size, schedule, and risk behavior. Keep the first version small enough to explain. If you use alternative data, specify the event and timing assumption.

2. Inspect the generated specification

Read the asset definitions, derived series, signals, rules, orders, and protective instructions. The code view is not decorative: it is the reviewable contract for what the backtest will run.

3. Backtest and diagnose

Run a historical simulation, then inspect return, drawdown, risk-adjusted metrics, trade count, equity, orders, Analysis, and Replay. Revise one meaningful assumption at a time so comparisons remain interpretable.

See Backtesting & Replay for metric and simulation guidance.

4. Save privately

Saving creates a reusable private strategy. Saved work can appear in Terminal, Dashboard, strategy detail surfaces, and private library flows. Saving does not make the strategy public and does not start monitoring or execution.

5. Choose an operating mode

Prediction-market strategies use the supported paper path where indicated by the deployment UI. Available modes can also be narrowed by account access, rollout flags, and the strategy itself.

6. Publish or share when intended

Publishing creates an Explore item associated with a public profile. Other users may view, discuss, save, copy, or open it. Publishing is not deployment, and deployment is not publication.

7. Monitor and stop

Use Terminal and Dashboard strategy surfaces to inspect current state, notifications, metrics, orders, and account health. Stopping or undeploying prevents future Astral-side activity for that deployment but does not necessarily close open broker positions.

Versioning a strategy

Treat a meaningful rule, data, sizing, or timeframe change as a new testable version. Keep the comparison dates and capital constant when you want to measure the effect of one revision. If several assumptions change together, the new result cannot tell you which change mattered.

A saved version should record enough context to reproduce the intent: assets, bar size, major rule idea, and what changed. A public publication or active deployment should not be assumed to adopt later edits made to another saved copy.

Deployment review

Before confirming any operating mode, review:

• The exact saved strategy and version.
• Assets and evaluation interval.
• Notification profile.
• Paper starting cash or connected account.
• Allocation and sizing assumptions.
• Mode-specific warnings and access gates.
• Current broker positions when live capital is involved.

The review screen is the last opportunity to catch a strategy-account mismatch. A backtest accepting an asset or action does not prove the selected broker supports it.

Monitoring after activation

Record the activation time and initial mode. Watch for last evaluation, emitted signals, simulated or live orders, health messages, connection status, and access changes. A strategy can remain active while producing no orders because its rule has not fired.

For broker-connected operation, compare Astral state with the broker regularly. Investigate rejections, unexpected positions, or ambiguous order state before resuming or creating another deployment.

Pausing, stopping, and revising

Pause or stop future Astral-side activity before making a consequential live revision. Then inspect broker orders and positions, save the revised strategy as an identifiable version, rerun the backtest, and complete a new deployment review.

Stopping is not liquidation. Existing broker orders and positions can remain until the broker confirms cancellation or closure.

Common workflow mistakes

• Publishing when the intended action was private saving.
• Deploying a copied community strategy before reproducing its result.
• Comparing different dates and calling the difference a rule improvement.
• Assuming an active label means the broker account is healthy.
• Editing a private copy and expecting an existing deployment to update automatically.
• Stopping a deployment without checking live positions.