Documentation
Saved & Deployed Strategies
Astral keeps private saved strategies, public publications, and active deployments as related but distinct records. Understanding the difference prevents accidental sharing or live operation.
Strategy states
| State | Meaning |
|---|---|
| In-session | Generated in a Terminal conversation and available to inspect or backtest. |
| Saved | Stored privately in your account library. |
| Published | Explicitly shared to Explore and a public profile. |
| Notifications only | Active signal monitoring with a notification profile and no tracked portfolio execution. |
| Astral Paper | Active simulated portfolio with configured starting cash. |
| Broker connected | Active against an eligible verified connected account for live order routing. |
| Paused or stopped | No longer operating normally; inspect the reason and any live broker state. |
Review a strategy
Strategy detail surfaces can show description, code, assets, timeframe, historical dates, metrics, equity, orders or trades, current execution mode, notification profile, capital, and health state. Availability differs between a historical saved result and an active deployment.
For notifications-only modes, portfolio metrics may be intentionally unavailable because no Astral paper or broker ledger is being tracked. Paper and broker metrics should identify their data source.
Copying and publishing
Copying an Explore strategy creates or associates your own saved version so you can inspect and modify it. It does not inherit the author’s suitability, account assumptions, or future changes. Run your own backtest.
Publishing requires public-profile context and makes the selected strategy visible to others. Private saved strategies remain private until an explicit publication action succeeds.
Stop, undeploy, and delete
Stopping a deployment prevents future Astral-side operation for that deployment. It does not necessarily close existing broker positions or cancel every broker-side order. Deleting or unsaving a private strategy is also separate from stopping a deployment or removing a publication.
A strategy is more than its code
The inspectable rule set is central, but a usable strategy also depends on its assets, bar size, historical range, capital assumptions, data availability, version, and intended execution mode. Two saved records with similar code can produce different results when any of those inputs differ.
Name saved versions so the difference is understandable later. A useful title or description records the market, interval, and major revision instead of only saying “final” or “new.”
Historical, paper, and connected results
| Result source | What it represents | What it cannot prove |
|---|---|---|
| Backtest | A historical simulation over selected data and assumptions. | Future performance or broker fill quality. |
| Astral Paper | Ongoing simulated activity with configured paper capital. | That live orders would fill at the same price or size. |
| Broker connected | Account and order state reported through the connected execution path. | That every value is instantaneous or free from broker restrictions. |
Never splice these sources into one continuous performance claim without labeling the transitions. A paper deployment beginning today does not inherit the backtest’s historical ledger, and a live account can include activity unrelated to one Astral strategy.
Strategy health and lifecycle events
An active label alone is not enough to prove normal operation. Review last evaluation time, current mode, notification profile, paper or broker account, health messages, and any pause reason. Common interruptions include access changes, expired broker authorization, rejected orders, insufficient funds, position-integrity conflicts, or unavailable data.
When you revise a strategy, confirm whether you are editing a draft, saving a new version, or replacing the record associated with a deployment. Do not assume an active deployment automatically adopts changes made elsewhere.
Before deleting anything
Trace the relationships first: private saved record, public publication, Terminal session, backtest, and deployment. Deleting one record may remove a convenient route back to the logic while leaving other records or live broker state intact. Export or record anything you need for audit before removal.