Alerts

Axiom CVD Osc STR exposes sixteen distinct alert conditions. They fall into four families. Fourteen of them are state descriptors that fire on every confirmed bar where the state holds. Two are divergence-event alerts — bullish and bearish — that can only fire on the bar where the geometry confirms. The families are different enough that this page treats them separately, because running them through the same mental model is a quiet way to get surprised by how often the state-descriptor alerts repeat.

Before you wire anything, read the posture section below. Every claim on this page depends on it.

Posture

Every alert in this script gates on barstate.isconfirmed. None of them can fire mid-bar. The evaluation happens at bar close on the alert's timeframe, which is the chart timeframe. That posture is honest but it carries a subtle cost worth naming: an alert does not ping when a state first flips mid-bar; it pings on the next confirmed bar that still holds the state. If the state flips and un-flips inside a single bar, you will never hear about it. This is the behavior the alert surface is built to give you — it keeps the stream free of intrabar thrash and the false positives that come with it — but it also means the alert is a description of what is true at the close of the bar that just confirmed, not a description of every transient state the bar passed through.

It also means every alert except the divergence alerts will fire repeatedly during sustained states, not only on flips. A slot that has been bullish for thirty confirmed bars will fire thirty Is Bullish alerts if the alert is armed. That is the correct behavior; the alert is restating "this state still holds at this confirmed bar." If you need flip-only firing, that gating belongs on the receiving side or in your alert platform.

None of these alerts are trade triggers. They are descriptors of pressure state, consensus state, and confirmed geometric events. Anything downstream that converts them into entries is a wrapper you wrote. The alert surface does not endorse such wrappers, and Workflows documents alert triage as the intended use pattern. Read each subsection below in that posture: what does this alert commit to, and what does it not commit to.

Alert inventory

Family 1 — Per-slot state alerts

Ten alerts total in this family — five bullish, five bearish.

What each one commits to: at this confirmed bar, this slot's CVD sits above (or below) this slot's own signal line.

What none of them commits to:

• A statement about the other slots.

• A statement about the blend.

• A claim that the slot "just flipped." The alert does not distinguish between the bar where the state first flipped and any subsequent bar where the state still holds. If the slot has been bullish for forty confirmed bars in a row, you have received forty Is Bullish alerts on that slot if the alert was armed.

• A directional claim about price. The slot is a pressure read. Price can do anything while a slot is in any state.

Important: a slot that is enabled but currently returning na — for example on the first bars after load, or when a requested symbol/timeframe has no returned value — does not fire these alerts in either direction until it resolves to a real value. A session reset by itself does not automatically make the slot na; it restarts the accumulation and normalization window.

Weight does not matter for per-slot alerts. A slot with weight 0.0 still fires its own alerts at full posture. This is the point of the weight-zero pattern: you can watch a slot's alert surface without letting it steer the blend.

Hide Plot does not matter for per-slot alerts. A hidden slot fires the same alerts as a visible one.

Family 2 — Blended state alerts

Two alerts. Same repeat-fire behavior as the per-slot alerts — they fire on every confirmed bar where the state holds, not only on the flip.

What they commit to: at this confirmed bar, the blend's line sits above (or below) the blended signal line.

What they do not commit to:

• A read on the underlying slot stack. The blend is a weighted mean; two blends that sit above their signals can have completely different underlying slot configurations. If you care about slot agreement, wire Family 3 alerts.

• A directional claim about price.

Family 3 — All-slots-aligned alerts

Two alerts. Same confirmed-bar gate. Same repeat-fire behavior.

What they commit to: every slot currently enabled and currently returning a real value is on the same side of its own signal at this confirmed bar. A slot that is enabled but returning na is skipped — it does not count against the alignment — so the alert can still fire if only the non-na slots agree. That skip behavior is about missing values, not about ordinary session resets.

What they do not commit to:

• A claim that the aligned slots agree "strongly." Any slot above its own signal counts, regardless of how far above.

• A claim about the blend. The alignment is over per-slot states, not over the blend.

• A read on how long the alignment has held. The first bar of alignment and the twentieth bar of alignment fire identically.

The alert's correct reading is "the slots I enabled are currently leaning in the same direction." That is an unusual pane state that is worth reading. It is not an entry.

Family 4 — Divergence alerts

This family is different enough from the other three that it deserves its own subsection.

Two alerts.

These are the only alerts in the script that are one-shot per confirmation bar. The divergence flag is only true inside a barstate.isconfirmed block where a new bullish (or bearish) pivot confirmation has produced a valid geometric comparison against the previous pivot pair. The flag is not carried forward across subsequent bars. If the divergence geometry still describes the chart on the next bar, the alert does not fire again — there is no "new" pivot to confirm.

What the alert commits to: at this confirmed bar, a strict pivot has just confirmed on chart price; the blended-CVD value at the same offset satisfies the divergence inequality against the previous confirmed pivot pair.

What the alert does not commit to:

• Any claim about direction. The geometry is lower-low-in-price paired with higher-low-in-blend (bullish) or higher-high-in-price paired with lower-high-in-blend (bearish). That is a description, not a prediction.

• Any claim that the setup will work out. Confirmed divergences print directly into continuations all the time. The alert is doing its job when that happens.

• Any claim that the marker's visual location is where the alert fired. If Plot On Pivot is ON, the triangle marker is back-shifted by Pivot Len bars to sit on the original pivot bar. The alert still fired on the confirmation bar, not on the back-shifted bar. Do not confuse marker position with alert timing.

A divergence alert is an invitation to read the rest of the pane, not a conclusion about it.

Repeat-fire, flip-fire, and what to do with it

Families 1, 2, and 3 fire on every confirmed bar where their state holds. If your receiving system cannot tolerate repeat firings, you have three options:

1. Add edge detection on the receiving side. Track the last alert and only act when the state changes.

2. Throttle in your alert platform. TradingView's "Once Per Bar" and "Once Per Bar Close" options change when the alert is evaluated but not how the condition is defined. Use whichever matches your intended cadence.

3. Convert the alert to a journaling entry, not a trigger. This is the recommended working pattern and is documented as the alert-triage workflow in Workflows. State alerts read well as queued observations for review. They read poorly as automated triggers.

The divergence alerts do not have this problem. They are already one-shot per confirmation bar. Treat them as events, not as states.

What is not exposed

The following events are visible in the pane but are not exposed as alerts. If you need any of them, you need to wire them yourself on the receiving side.

• Overbought or oversold guide crossings. The 20 and 80 guide lines are visual only. No alert fires when a slot or the blend crosses them.

• Donchian breakout events. A touch or push of the upper or lower stepline is not exposed as an alert.

• Keltner envelope touches. The upper and lower lines are visual; a touch does not fire.

• BBWP threshold crossings. The column color flips at the threshold, but that flip is not exposed as an alert.

• Master smoothing state. If Master Smoothing is enabled on the blend, the blend alerts describe the smoothed blend, but there is no separate "smoothed blend state" alert.

The intentional gap is that none of these events is a pressure-state flip or a geometrically confirmed pattern. They are configurable visual references whose meaning depends on the reader's thresholds, and shipping alerts on them would invite people to build automated setups on top of display settings that the indicator does not endorse as triggers.

Post-alert verification

When an alert fires, a short verification pass before you act on it:

• If it is a per-slot state alert: confirm the slot's state visually. Is the slot hidden? Is it returning na? Is the blend doing something different? Is the slot weighted zero on purpose and you are still reading its state?

• If it is a blended state alert: look at the slot stack. A blended bullish alert with three disagreeing slots is a weaker read than the same alert with three agreeing slots. The blend cannot tell you which case you are in.

• If it is an all-slots-aligned alert: check the bar count since the last session reset. Alignment very early in a fresh window is more likely to be reset-noise than conviction. Look at the previous few bars to see whether the alignment was already forming or just emerged from a tight back-and-forth.

• If it is a divergence alert: check whether Plot On Pivot is OFF. If it is, the marker is on the confirmation bar, and the pivot itself is Pivot Len bars earlier. Look at where the pivots actually sit. Look at what the slot stack is saying. Look at whether the blend is stretched on the envelope or mid-range. Look at whether BBWP is expanding or compressing. Only then decide whether the geometry is worth leaning on.

Useful wiring patterns

These are the alert wiring patterns the pack endorses, in roughly the order most readers find them useful.

• Weight-zero alert watch. Set a slot's weight to 0.0, keep it enabled, and wire its per-slot alerts to a review queue. You get the slot's state surface without letting it steer the blend. This is the cleanest way to add a watched timeframe without adding a vote.

• Correlated-instrument alert. Enable a slot, set its Optional Ticker to a correlated symbol, set its weight to 0.0, and wire its per-slot alerts. Now you have a separate alert stream for the correlated instrument, on the same pane, without merging its state into your primary blend. This is one of the few independent corroboration surfaces available inside STR — the correlated symbol is a different data feed, not a different construction on the same line.

• Alignment-as-slowdown. Use All CVD Slots Bullish and All CVD Slots Bearish as prompts to slow down and re-read, not to act. These states are unusual and they deserve attention. They are not tickets. The right response to an alignment alert is to look harder, not to look faster.

• Divergence into triage. Every divergence alert should go to a review queue, not to an executor. Write down the pivot positions, the slot stack at the moment, the blend's distance from the basis, and the BBWP read. Over a few dozen divergences logged in this format, you will learn how the geometry behaves around your instrument at your timeframe — which is the only honest way to develop intuition for whether a triangle is worth leaning on. This is also the practice that protects you from the easy story; the log is harder to argue with than memory.

Where to go next

• For what the alert states actually look like in the pane, Visuals and Logic.

• For the confirmation timing that makes the divergence alert one-shot, MTF and Repainting.

• For named workflows that use these alerts as triage inputs rather than triggers, Workflows.

• For the honest limits behind the alert surface, Limitations and Trust Boundaries.