Operations

3.6 Trade State and Lifecycle

The execution model operates as a simple two-state system:

• Idle — no trade is currently active
• Active — a trade is in progress

Only one trade may be active at a time.

Two internal variables control the lifecycle logic:

• tradeActive — indicates whether a trade is currently active
• tradeDirection — the direction of the active trade (1 = long, -1 = short)

3.6.1 Trade Activation

When a valid breakout signal occurs and no trade is currently active, the system activates a trade and begins tracking stop and target levels.

At activation:

• entryPrice is set to the signal bar close
• Stop and target levels are calculated
• State transitions from Idle → Active

Trade Activation Logic

varip bool tradeActive = false  
  
if isLongSignal or isShortSignal  
	if not tradeActive  
		tradeActive := true

3.6.2 Trade Monitoring

While a trade is active, each completed bar is evaluated to determine whether the stop or target level has been reached.

Stop and target levels remain fixed for the duration of the trade. New signals are ignored while the system is in the Active state.

3.6.3 Trade Termination

If either the stop or target level is reached, the trade is closed and the system returns to the Idle state.

Trade Termination Logic

if tradeActive
    if tradeDirection == 1
        if low <= stopPrice
            tradeActive := false
        else if high >= targetPrice
            tradeActive := false
    else if tradeDirection == -1
        if high >= stopPrice
            tradeActive := false
        else if low <= targetPrice
            tradeActive := false

Lifecycle Diagram

4. Observability and Calibration

Model evaluation should be performed using structured trade logs.

note

Industry practice refers to structured performance tracking as trade journaling. Logging enables evaluation of signal quality, filter impact, and regime sensitivity.

Structured logging enables post-trade analysis of model inputs and outcomes. By comparing trade results against the conditions present at entry (such as volatility, participation, or filter configuration), analysts can identify patterns in signal behavior.

These observations support model calibration, including evaluation of parameter sensitivity, filter effectiveness, and regime behavior. Experimental adjustments should be validated using separate testing periods before being applied to future trades.

Statistical evaluation (such as win rate, R-multiple distribution, variance, and drawdown) is external to the indicator and must be performed using logged trade data. Trade logs also support identification of market regimes in which the model performs differently.

4.1 Recommended Logging Fields

The following fields are recommended for recording each trade.

Field	Description
Signal timestamp	Time the setup/entry signal occurred
Execution timestamp	Actual time the order filled
Exit timestamp	Time the trade was closed
Instrument	Ticker / symbol
Direction	Long / Short
Timeframe	Chart timeframe used
Market type	Stocks / Crypto / Forex / Futures
Entry price	Signal bar close or actual fill
Stop price	Calculated stop level
Target price	Calculated target level
ATR at entry	ATR value used for stop/target distances
Position size	Shares or contracts traded
Scheduled entry timestamp	If using delayed or conditional entries
Filters enabled	Sideways / green / volume / other system filters
Outcome	Stop hit / target hit / manual exit
Exit price	Actual exit price
R-multiple	Realized result normalized by stop distance
Strategy notes	Reasoning, rule triggers, discretionary context
Setup notes	Observations about the setup conditions

4.2 Optional Logging Fields

Field	Purpose
Screenshots	Chart state at entry/exit
Asset classification	Sector, theme, or additional categorization
External links	Video notes, research references, related docs
Status labels	Additional labels (e.g., partial exit, etc.)

5. Limitations

• The model does not define position sizing or capital allocation.
• The model does not model transaction costs (fees, spread, slippage).
• The model does not implement portfolio-level constraints (multi-position exposure, correlation limits).
• Thresholds and presets are heuristic; no parameter optimization is performed.

5.1 Validation Scope

The reference implementation is an indicator and does not perform embedded backtesting. No statistical optimization or parameter fitting is performed within the model.

Empirical evaluation requires external logging and analysis of recorded trades.

5.2 Platform and Data Dependency

The framework relies on TradingView's implementation of standard technical indicators and its aggregated market data feeds.

Minor discrepancies may occur across platforms due to differences in:

• Data sources
• Corporate action adjustments
• Indicator calculation boundaries

Consistent platform usage is assumed to maintain alignment between screening and execution.

5.3 Screener Dependency

External screeners may use proprietary calculations or data aggregation methods. As a result, screening results may not exactly match indicator signals across platforms.

Screeners should therefore be treated as candidate filters rather than deterministic signal generators.

6. Market Regime Sensitivity

The model is designed to detect breakout events following periods of range compression.

Signals are therefore most aligned with market environments characterized by:

• sustained directional trends
• volatility expansion following consolidation
• breakout continuation behavior

Signal quality may decrease during market conditions characterized by:

• mean-reverting price behavior
• prolonged low-volatility ranges without expansion
• abrupt news-driven reversals

The model does not attempt to detect or adapt to changes in market regime.

7. Platform Migration and Implementation Differences

7.1 Migration Overview

The original implementation of the model was developed in ThinkorSwim using ThinkScript. The model was later reimplemented in TradingView using Pine Script to improve cross-platform portability and support additional instrument classes.

Indicator and screener behavior differs across platforms due to variations in:

• indicator implementations
• available screener fields
• calculation boundaries

As a result, parameter defaults and filter structures were adjusted in the TradingView implementation to maintain comparable breakout detection behavior.

These adjustments reflect platform constraints and implementation differences and do not imply performance improvement.

7.2 Implementation Comparison

Feature	TradingView v5 (Reference)	ThinkorSwim v4 (Prior)
Form	Indicator (Pine Script)	Indicator (ThinkScript)
Centerline	EMA	Inertia
Direction support	Long / Short / Both toggle	Long-only
Volume filter	Required except Forex	Required
Sideways compression filter	Supported (default enabled)	Not implemented
Green candle filter	Supported (default enabled)	Not implemented
Parameter presets	Market/timeframe presets	Fixed inputs

Appendix A — Specification to Implementation Mapping

Specification Section	Script Region	Purpose
3.2 Configuration	// === GLOBAL TUNING PANEL ===	Defines user-configurable parameters
3.3 Screening	External (TradingView Screener UI)	Pre-filters the instrument universe
3.4 Signal Generation	// === ENHANCED BREAKOUT FILTERS ===	Implements breakout confirmation logic
3.5 Risk Framework	// === PERSISTENT STOP/TARGET LOGIC ===	Assigns ATR-based stop and target levels
3.6 Trade Lifecycle	tradeActive state block	Controls idle ↔ active trade state transitions