Strategy RMS Engine ​
The Strategy RMS Engine runs configured multi-leg option strategies and signal-driven strategies with durable order intent, per-leg protection, and run-level risk controls. It preserves the operational distinction that matters: an exit request is not a flat position until broker fills confirm it.
What It Supports ​
Batch strategies ​
Batch strategies resolve and enter their configured legs together. They are controlled with start and stop, and can use per-leg stop loss, target, and trailing rules; overall MTM stop loss and target; lock-profit and trail-to-entry controls; scheduled starts and square-off; and daily loss limits.
Signal strategies ​
Signal strategies act on one configured leg at a time. Alert actions are long_entry, long_exit, short_entry, and short_exit. The first accepted signal for the platform session opens the run; there is no separate start action or mode field for this strategy kind.
The engine treats a repeated entry or an exit for a position that is not held as a successful no-op. That prevents an alert sender retry from becoming a second position. A direction or leg mismatch is rejected so it can be corrected in the sender or strategy configuration.
How A Run Is Managed ​
- The engine records a durable pending order intent before it calls a broker.
- It records the broker acknowledgement against that exact intent, then consumes broker order updates and fills.
- A stop or close request records its intent, submits MARKET exits for the exact held contracts, and remains managed while any fill, retry, or reconciliation is pending.
- Only confirmed-flat ownership and fill evidence finalises the run and writes its realised P&L.
An overall_target or overall_sl stop reason records the risk rule that initiated the exit, not a promise that the eventual realised P&L equals the threshold. Prices can move while individual MARKET exits are filled.
Modes And Safety Gates ​
- New strategies are sandbox-only. Live trading must be enabled explicitly on the strategy page before any
livestart is accepted. - Batch starts require an explicit
modeofsandboxorlive; there is no default that could accidentally place live orders. - A leg whose entry has been accepted but is not yet filled is never exited at its configured quantity. Doing so could create a naked position if the entry later cancels. The run remains managed and reports the refusal.
- A refused exit remains retryable. It does not falsely mark the leg flat or finalise the run.
- Risk rules use the basket's latest known LTP marks. If the WebSocket source becomes stale, the engine uses its polling fallback while it can; stale data is recorded in the event trail.
Monitoring And Audit ​
The strategy detail page shows the active run and broker-backed orderbook, tradebook, and positions where the broker supports them. A broker response is preferred for broker truth; local strategy rows are retained as a labelled fallback when that source is unavailable.
Use the strategy's Events and History views, or the RESTX API, to investigate a run. In particular, treat these events as operator-action items:
| Event | Meaning |
|---|---|
run_stop_failed | A stop could not flatten all owned exposure. The run remains open and managed. |
order_ack_unrecorded | The broker accepted an order but its acknowledgement was not persisted after retry; it needs reconciliation. |
leg_expiry_fallback | The configured expiry rank was unavailable and a nearer expiry was traded. |
flip_outgoing_exit_rejected | The old side of a signal flip is still held and remains separately managed. |
The run history records finalised P&L. While a run is still open, live P&L is a mark, not final settlement; a stopped run has zero unrealised P&L.
Alerts And API Automation ​
Use the Public Strategy Webhook for alert senders such as TradingView. Its URL includes a high-entropy token, which is the credential. Do not put an API key inside the alert body; protect the token in sender configuration and every proxy/access-log layer, and rotate it if exposure is suspected.
Use the authenticated Strategy RMS RESTX API for lifecycle actions and audits from a script, integration, or dashboard. It can list, inspect, start, stop, close, and query history, but cannot create or edit a strategy, enable live trading, rotate the webhook token, or delete a strategy.
Operational Boundaries ​
Strategy RMS validates strategy configuration and manages the orders it owns; it is not a substitute for broker RMS or account-level margin controls. Before using live mode, validate each strategy in sandbox, understand the broker's product and market-data support, and retain an operational path to inspect or close broker positions during an incident.
Existing Installations: Required Migration ​
An existing Tradeboard installation must run the standard migration runner before starting this version. Take a consistent database backup first (or stop the application before making a filesystem copy), then run:
cd upgrade
uv run migrate_all.pyThe Strategy RMS migration is idempotent. It creates the six sm_ strategy tables on installations that do not have them and, for earlier Strategy RMS installations, adds nullable durable-order and pending-stop columns plus the ownership index. Existing strategy/order rows are preserved; values that were never recorded on an older row remain null rather than being guessed.
This migration is required: if it fails, migrate_all.py exits non-zero. Do not start the updated application until it succeeds. See Upgrade Tradeboard for backup and post-upgrade checks.