Wheeling-Alerts — CSP and CC Signal Engine

Python-based cash-secured put and covered call signal engine
Confluence-driven, volatility-aware wheeling model
Outputs: Discord, email, SMS, and structured event payloads

Overview

Wheeling-Alerts is a regime-aware options signal engine designed to evaluate when a cash-secured put, covered call, profit-taking event, or no-trade state is most appropriate. It combines directional context, volatility analysis, multi-module confluence, and options-structure validation to support a full wheeling lifecycle from put sale through assignment, covered call management, and exit conditions. github

The engine is designed to emphasize signal quality over trade frequency. Its main objective is to avoid low-quality premium-selling entries during volatility expansion, trend acceleration, momentum instability, or structurally weak confluence states. andreabergia

Strategy Role

The engine evaluates whether the current environment supports:

This framework is intended to align premium-selling decisions with market regime, volatility state, and underlying trend behavior rather than forcing entries on a fixed schedule.

Signal Architecture

Wheeling-Alerts is organized into five core layers:

  1. Market and option data ingestion.
  2. Indicator and confluence computation.
  3. Strike and credit modeling.
  4. Symbol-level state management.
  5. Structured alert generation. dev

This layered design separates market interpretation, structure validation, and lifecycle state handling so that each decision stage remains explicit.

Data Layer

The data layer processes OHLCV inputs and option-chain context for supported underlyings. Session timestamps are normalized to a consistent market-time reference so that confluence and state transitions are evaluated against the same bar sequence and session boundaries.

The engine supports both underlying-price context and option-structure context. This allows directional and volatility filters to be combined with strike-location, credit, and probability-style constraints before a signal is promoted.

Indicator Engine

The engine uses a five-module confluence system, with each module contributing a directional score from -2 to +2.

Module Primary role
MACD Momentum direction and acceleration
VWAP Institutional bias and mean-reference context
SMC Structural context, including breaks and zones
TTM Squeeze Volatility compression and expansion state
Ichimoku Cloud Trend regime and crossover context

Additional supporting inputs include:

These components are evaluated together rather than independently. The result is a normalized confluence score used to validate CSP and covered call candidates while filtering out lower-quality states.

Confluence Model

Each module returns one of five directional states:

The summed output is normalized to a 0-10 confluence scale. That score is then used to determine whether the environment supports a premium-selling entry, requires additional caution, or should be classified as WAIT.

This approach allows the engine to measure both directional bias and confidence level without reducing the decision to a single indicator trigger.

Strike and Credit Model

Strike and credit selection is informed by:

When option-chain data is available, the engine refines structure selection using marketable strikes, mid-price estimates, and contract quality filters. When chain data is limited, the model can still evaluate structure candidates through a volatility-based approximation layer.

This ensures that signal generation depends not only on market direction, but also on whether the proposed option structure meets the quality requirements of the wheeling model.

State Model

Each symbol maintains its own persistent lifecycle state, including:

This state model supports complete wheeling-cycle awareness rather than isolated one-bar alerts. It also allows the engine to manage transitions between cash-secured put and covered call phases while preserving signal continuity across sessions.

Decision Logic

Cash-Secured Put

A CSP candidate is considered when confluence is constructive, volatility is acceptable, downside trend pressure is limited, and expected move context supports a sufficiently out-of-the-money structure.

CSP candidates are blocked when bearish trend structure strengthens, volatility exceeds acceptable thresholds, confluence weakens, or the broader regime suggests elevated downside continuation risk.

Covered Call

A covered call candidate is considered when the symbol is in the appropriate post-assignment phase, confluence is sufficient, upside continuation risk is limited, and the structure can be placed at an acceptable distance and credit profile.

Covered call candidates are blocked when bullish continuation, breakout structure, or trend-regime confirmation raises the risk of selling calls into active upside expansion.

WAIT

WAIT is produced when confluence is weak, regime classification is unstable, volatility is abnormal, structure quality is incomplete, or the market is in a transitional state. WAIT acts as a deliberate risk-control outcome rather than a missing signal.

Entry Protection

Wheeling-Alerts includes several protection layers intended to suppress low-quality entries.

Confluence threshold

Signals require the normalized score to meet a minimum quality level before entry is considered.

Volatility cap

The engine suppresses premium-selling entries during elevated volatility conditions that fall outside acceptable regime limits.

Trend filters

CSP candidates are restricted during stronger downtrend conditions, and covered call candidates are restricted during stronger uptrend continuation states.

Squeeze logic

The model treats volatility compression and immediate post-expansion states with additional caution to avoid entering during unstable transitions.

Cloud regime validation

Ichimoku structure is used as an additional trend-regime filter so that signals are not promoted against the dominant cloud-defined backdrop.

Hold and alert controls

Minimum hold logic and alert-throttling controls reduce flip-flop behavior and suppress excessive signal churn in choppy conditions.

Option structure validation

If strike, credit, or chain quality conditions are not met, the engine does not advance the candidate to a trade signal state.

Alert Model

Alert payloads can include:

Output channels

Channel Status Purpose
Discord Active Rich signal presentation
Email Active Text-based alert delivery
SMS Active Compact mobile notification
Signal event payload Active Structured downstream consumption

The alert layer is designed for both direct review and machine-readable ingestion.

Design Boundaries

What the engine is

Wheeling-Alerts is a volatility-aware wheeling signal engine built to:

What the engine is not

The engine is not intended to maximize signal count or force participation in every session. Its role is selective premium-selling signal generation, lifecycle-aware state evaluation, and structured alert publication.

Positioning

Wheeling-Alerts is designed for:

Send the Strategy Picker draft next, and I’ll keep the same style so all bot pages and the TastyDayTraders About section feel unified.