Appearance

Personalize your experience

Mode

Accent Color

Direction

Step 8 — Review & Deploy

What this step does

Review is the final step before . It presents the complete configuration in one place, runs validation checks, highlights errors and warnings, and lets you any section without navigating back through the . Once validation passes, deploy to paper trading to test with simulated capital, or to live markets with real orders.

Validation checklist

The review step runs comprehensive validation and displays a pre-deploy checklist. Errors block and must be ; warnings are advisories that you can proceed past if deliberate.

Critical validations (errors)

is set — required for identification
Trading symbol selected — the to trade
At least one entry condition defined — without it, no open
At least one exit mechanism configured — condition, , or take profit
Broker assigned — orders need a destination
Quantity greater than zero — otherwise no position size

Recommended validations (warnings)

configured — without it, unlimited downside on every trade
Take profit or exit condition present — positions need a profit-taking mechanism
Re-entry settings reviewed if is enabled
Partial exits configured if staged profit-taking is desired
Timeframe appropriate for the type ( → 1m/5m, swing → 4h/1d)
correct: continuous for 24/7, intraday for day trading, positional for swing

Caution:Fix all errors before deploying. The platform blocks when critical validations fail, and deploying a with missing or exit conditions creates unbounded risk.

Editable sections

Every section from the is collapsible and editable directly in the review step. Click any section header to expand it, the fields inline, and changes save immediately to the state. The "Fix → Step N" buttons in the validation jump straight to the relevant section.

Configuration sections

·Particulars — name, description, visibility, tags
·Symbol — broker, market type, instruments, timeframe, session mode
·Quantity — position sizing mode, fixed quantity, capital allocation
·Entry — entry signals, conditions, order configuration, re-entry settings
·Exit — exit signals, stop loss, take profit, partial exits, max daily loss

ℹ

Note:Inline editing in the review step is the fastest way to fix validation errors. Expand the relevant section, make the change, and validation re-runs automatically. No need to navigate back through steps.

DSL export and version control

The "View DSL" button displays the complete as code: entry conditions, exit rules, , quantity , and all configuration in a structured JSON format. Copy this DSL to store strategies in git, share with team members, or import into other environments.

Why export DSL

Version control

·Store strategies as text files in git — track changes over time
·Diff two versions to see exactly what changed between backtests
·Revert to previous versions when a change underperforms

Collaboration

·Share strategies with team members via text file
·Review proposed changes in pull requests
·Merge strategy improvements from multiple developers

Templates

·Save successful strategies as templates for new instruments
·Build a library of reusable signal components
·Parametrize strategies and generate variations programmatically

★

Pro tip:Name your DSL exports meaningfully: nifty-rsi-oversold-v3.json is far more useful six months from now than strategy-final-FINAL2.json. Include the , signal type, and version number.

Paper trading deployment

Paper trading runs the with simulated capital and . Orders execute at market prices but no real money moves. It is the mandatory step between backtest and live: backtest shows historical performance, paper shows real-time behavior.

What paper trading tests

Order submission — does the generate signals in real time?
Fill — how long between signal and fill at current market prices?
Slippage — do live match expected prices or deviate significantly?
Position management — do and take profit orders execute correctly?
Re-entry logic — do layer in as expected?
boundaries — do intraday strategies close positions at market close?
Gap handling — does the behave correctly over weekends or holidays?

Caution: is not optional. A that backtests well can still fail in real time due to timing, feed lag, or order routing issues. Paper catches these before real capital is at risk.

How long to paper trade

Run paper for at least 20–50 signals, or until you have confidence the behaves as designed. For intraday strategies, a week of paper trading usually suffices. For positional strategies, two to four weeks gives coverage of different market regimes.

Live deployment

Live routes orders to your broker with real capital. The executes automatically: signals orders, positions open and close, and profit and loss accumulate in your brokerage account. This is the final step — after successful paper trading.

Caution:Live trading is irreversible. Once deployed, the places real orders that execute at market. A bug in entry logic or a missing costs real money. Deploy live only after:

Backtest shows positive over 100+
Paper trading runs successfully for the required
All validation errors and critical warnings are
You understand the maximum loss per trade and per day

Pre-live checklist

is configured and tested in paper trading
limit is set and appropriate for your capital
Position sizing is correct — not risking more than 1–2% per trade
Broker API are valid and have sufficient permissions
Sufficient margin or capital in the brokerage account
Market hours and match your trading
Re-entry limits are conservative — avoid on a single signal
Notifications or alerts are configured to monitor live execution

Monitoring live strategies

After deploying live, monitor execution closely for the first few . Watch the , verify that orders execute at expected prices, and that and take profit levels are correct. Most issues in the first few trades — catching them early limits damage.

Deploy workflow

ℹ

Note:The recommended from builder to live:

Backtest — validate the logic over historical
Review — fix all errors, resolve critical warnings
Paper — deploy with simulated capital, monitor for 20–50 signals
Live — deploy with real capital after paper proves behavior

Common deployment errors

Error	Description
No entry conditions	never opens positions because no is defined. Add at least one entry condition in Step 5.
No exit mechanism	Positions never close because no exit condition, , or take profit is configured. Add at least one in Step 6.
Zero quantity	Orders place with zero size, so no trade executes. Set quantity > 0 in Step 4.
No broker assigned	Orders have nowhere to route. Select a broker in .
Invalid timeframe	Backtest or live feed does not support the chosen interval. Select a standard timeframe: 1m, 5m, 15m, 1h, 4h, 1d.
Insufficient capital	Brokerage account balance is lower than the required margin for the position size. Reduce quantity or increase capital.

Before moving on

All validation errors — deploy button is active
Critical warnings reviewed and understood
and description are
DSL exported and stored in version control (optional but recommended)
Paper trading decided: how many signals before
Live risk understood: max loss per trade,
Broker API tested and confirmed working
in place: alerts, dashboards, review frequency

Step 0 — Particulars
Automation / Strategy Builder / Wizard Steps
Identity and metadata: the name, description, tags and visibility that make a strategy findable a year from now. Also where the immutable Strategy ID is minted.
Step 1 — Settings
Automation / Strategy Builder / Wizard Steps
Global behaviour that decides how entries and exits interact: whether the strategy builds a position in stages, which multi-entry model it follows, and how…
Step 2 — Tagging
Automation / Strategy Builder / Wizard Steps
Optional. Client order ID templates, signal-level metadata and order linking — the machinery that makes live orders reconcilable against broker statements.
Step 3 — Symbol
Automation / Strategy Builder / Wizard Steps
The trading context: broker, segment, instrument, timeframe and session mode. These choices decide what data exists, what order types are available, and…
Step 4 — Quantity & Capital
Automation / Strategy Builder / Wizard Steps
How much to trade. Four sizing modes, the capital they draw on, the leverage applied, and how capital is divided across entry sets.
Step 5 — Entry Signals
Automation / Strategy Builder / Wizard Steps
Where the strategy is actually written. Conditions, operators, nesting, order configuration, multiple entry sets, and the re-entry engine behind Grid, DCA…
Step 6 — Exit & Risk
Automation / Strategy Builder / Wizard Steps
Exit conditions, stop loss, take profit, staged partial exits and portfolio-level limits. The step that decides whether a losing trade costs you a percent…
Step 7 — Strategy Testing
Automation / Strategy Builder / Wizard Steps
The testing step offers three modes, each answering different questions about strategy behavior. Use all three in sequence: backtest to validate logic,…
Strategy DSL Format
Automation / Strategy Builder / Reference
The engine JSON a strategy saves as. The form, node and JSON editors all edit this one document, and the C++ engine runs it unchanged in backtests and live.

Browse all knowledge base articles →