Alerts

The script wires exactly sixteen alert conditions. This page walks all sixteen in four groups, names the gating pattern that applies across them, flags a current behavior in the alignment group that every reader should understand before relying on it, and ends with a list of what is deliberately absent. The absences matter as much as the presences — much of what readers expect an RSI pane to alert on is not wired here, and that is a design choice this page will name rather than bury.

A framing note before the inventory. Every alert on this pane is a state alert, not a transition alert. That is: a condition that holds across multiple consecutive confirmed bars will fire the alert on every one of those confirmed bars, not only when the bar the state first becomes true. If the blend is bullish for fifteen closed bars, the bullish blend alert fires fifteen times. If you want transition-only alerts — fire once when the state flips, then silence until it flips again — you will need to do that edge detection on the receiving side. Your routing system, your journal, your notebook, or whatever workflow consumes these alerts is where the flip logic belongs. This pack does not pretend the script carries a feature it does not carry, and does not apologize for a design choice that serves review-queue workflows better than it serves automated-execution workflows.

Gating that applies across the whole alert list

• Confirmed-bar gating. Every alert condition is evaluated only inside barstate.isconfirmed. A condition that holds on an unclosed bar does not fire an alert until that bar closes.

• Enabled-slot gating for per-slot conditions. A per-slot alert can only fire if the corresponding slot is enabled.

• Repeat-fire behavior. Because these are state alerts, a sustained state produces repeated firings. Wire accordingly.

Group one — per-slot state alerts (10 conditions, 2 per slot)

Every slot has two alerts:

• RSI <slot label> Is Bullish — fires on a confirmed bar when the slot is enabled and the slot's smoothed RSI is above its own signal (with both values non-na).

• RSI <slot label> Is Bearish — the mirror. Fires on a confirmed bar when the slot is enabled and the slot's smoothed RSI is below its own signal (with both values non-na).

That is ten alerts total — two per slot across slots 01 through 05. The condition reads the same RSI-vs-signal relationship that drives the slot's plot color, and a confirmed-bar bullish alert on a slot whose color is lime at that moment is reporting the same thing the color is reporting. One equality detail matters: the visible faded/down tone includes equality because the plot color is strict on the bullish side, but the bearish alert itself is also strict. Equal RSI and signal values fire neither bullish nor bearish.

What it is not. These are not threshold-crossing alerts on the reference bands. Nothing in the per-slot alert group fires on a slot crossing 70 or 30. The reference bands are visual bumpers; no alert condition reads them.

What it is not, again. These are not transition alerts. A slot that holds an RSI-above-signal state across twenty confirmed bars will fire the bullish alert twenty times.

Group two — blended state alerts (2 conditions)

• Blended RSI Is Bullish — fires on a confirmed bar when blend RSI is above blend signal, with both values non-na.

• Blended RSI Is Bearish — the mirror.

The condition reads the same color rule that drives the blend's line color. A confirmed-bar bullish blend alert on a lime-colored blend is reporting the same thing the blend color is reporting.

Repeat-fire applies here too. A sustained blend-bullish state fires on every confirmed bar.

Group three — alignment alerts (2 conditions)

• All RSI Slots Bullish — fires on a confirmed bar when all enabled slots are individually bullish.

• All RSI Slots Bearish — fires on a confirmed bar when all enabled slots are individually bearish.

The logic behind these alerts compares an active-slot count against a count of slots whose RSI-vs-signal is bullish (or bearish) at the moment. When the two counts match and there is at least one active slot, the alignment condition is true.

This block also carries an STR-specific current behavior that every reader should hold in working memory before wiring either alignment alert.

Slot 05 alignment current behavior — name it plainly

The All RSI Slots Bullish and All RSI Slots Bearish alerts, as currently implemented in the script at the time of this pack, do not fire when slot 05 is enabled. The reason is a behavior in the alignment counter's slot-05 arm: the arm contains additional increments beyond the intended single increment, which inflate the active-slot count past what the per-slot bullish count can ever reach. Once slot 05 is enabled, the alignment condition can no longer become true, regardless of what the five slots are actually doing.

What this means in practice:

• If you run a four-slot configuration (slots 01–04 enabled, slot 05 disabled), the alignment alerts behave as documented.

• If you enable slot 05, the alignment alerts cannot fire. Per-slot alerts, blend-state alerts, and divergence alerts remain unaffected.

This pack does not edit Pine source and does not promise the behavior is fixed. We are naming the behavior honestly rather than burying it in a footnote. The reason it is on this page, in this block, instead of in a disclaimer at the bottom: a reader who wires the alignment alert without reading about this first will spend time and attention debugging their routing system for a fire they were never going to receive. The honest disclosure is the cheapest fix, and the pack owes it.

The workaround is plain. Until upstream remediation, treat the all-slot alignment alerts as four-slot-maximum signals, and do not rely on them when slot 05 is enabled. If a reading you care about specifically wants a five-slot alignment, wire from the five per-slot alerts or from a routing layer you control. The hidden bullCount / bearCount plots can carry count context inside alert messages that already fire, but they are not a standalone five-slot alignment condition and they do not expose active-slot count by themselves. Troubleshooting carries the symptom and the same workaround for readers arriving from a firing-behavior surprise rather than from this disclosure. Limitations and Trust Boundaries carries the framing — why a pack that does not edit Pine source still names upstream behavior honestly, and what the reader can rely on while the behavior is current.

The alignment-as-breadth trap is larger on STR than on Base

Even when it fires correctly, the alignment alert reports "the enabled slots agree on direction." It does not report "five independent witnesses agree." If the enabled slots share source, RSI length, smoothing, and MA family, alignment is one measurement sampled at several cadences. STR lets you enable five slots, and the visual authority of five-way self-agreement is larger than three-way self-agreement. That is a misread cost worth naming here and on Limitations and Trust Boundaries.

Group four — divergence alerts (2 conditions)

• Blended RSI Bullish Divergence — fires on a confirmed bar when the divergence engine registers a confirmed bullish divergence (chart lower-low in price paired with blended-RSI higher-low in the opposing direction, evaluated inside barstate.isconfirmed).

• Blended RSI Bearish Divergence — the mirror (chart higher-high paired with blended-RSI lower-high).

Two things to hold firmly on these two alerts.

First, the alert is a confirmed-geometry flag. It is not an entry. It is not a forecast. It does not say anything about the next bar. Any routing you build on top of a divergence alert should preserve that frame — treat the fired alert as a prompt to look at the underlying slot stack, not a command to act.

Second, Plot On Pivot does not change when the alert fires. Plot On Pivot = ON moves the visual triangle back to the original pivot bar; the alert still fires on the confirmation bar (which is Pivot Len bars to the right of the original pivot). If you wire a divergence alert and your routing records the alert's bar, that is the confirmation bar, not the original pivot bar. The visual is honest about where the geometry formed; the visual is misleading-looking about when a reader could have acted. See MTF and Repainting for the timing picture.

Hidden bullCount and bearCount plots — an advanced injection point

The script exposes two hidden plots (display turned off) for bullCount and bearCount. These count the active slots that are currently bullish and bearish as series values; when a confirmed-bar alert fires, readers can reference the hidden plot values through TradingView's alert templating — for example, to say "3 active slots are bullish" in an alert message body.

This is not a wrapped-in-alertcondition feature. You will not find a bullCount alert in the alert dialog. It is an injection point for readers who want to route richer information through an existing alert. If you do not need this, ignore the hidden plots; they do not affect the pane's visuals.

What is deliberately absent

The script carries no:

• Threshold-crossing alerts. Nothing fires on the blend or a slot crossing 70 or 30. If your workflow wants threshold triggers, build them at the routing layer or use a different tool.

• Transition alerts. Nothing fires on the bar where a slot's RSI first crosses above its signal (or the blend's first such cross). Only the state alerts exist. Flip-detection is a receiving-side concern.

• Live-pivot divergence alerts. No alert fires before the divergence pivot's right shoulder is confirmed. All divergence evaluation waits for barstate.isconfirmed and pivot confirmation.

• Cross-feature alerts. There is no alert that fires on "Keltner upper touch while Donchian press while BBWP above threshold." The four structure features co-exist; they are not wired into a combined alert.

Each of these absences is a design choice, and each matches the pack's posture: the tool describes, it does not trigger.

A note on routing these alerts

State alerts that repeat on every confirmed bar of a sustained state are useful for review queues and journaling workflows. A reader who wants to surface "the blend is in a bullish regime right now" during a manual chart review is well served by an alert that continues firing across the regime — it gives the review queue something to look at even if the regime started before the reviewer sat down.

They are less useful as direct handoffs to automated executors, which would fire repeatedly against unchanged underlying conditions and produce duplicate orders, redundant notifications, or rate-limit violations depending on the receiving side. If you are wiring any alert on this pane into an execution system, the flip-detection, the debouncing, and the state machine belong on the receiving side. The alert list is deliberately not trying to be a routing layer; keeping the state-vs-transition distinction at the receiving side is what lets the alerts serve both workflows without pretending to be either.

A reasonable default pattern: wire each state alert into a message queue or notification channel, then have the receiving system compare against the last-seen state and forward only transitions. That keeps the journaling workflow (every bar surfaces its state) and the transition workflow (only flips propagate) working off the same alert stream.

Where to go next

If you are still deciding which posture to wire, Workflows carries four scenario cards that include alert-triage framing. If you are debugging an alert that did not fire, Troubleshooting has symptom-to-cause routing. If you want the full timing picture behind the confirmed-bar gating, MTF and Repainting is the reference.