For the Geeks

This page exists to give the serious reader enough mental model of the pipeline that they can trust what the rest of the manual says. It is not a reference implementation. It does not contain formulas, pseudocode, lib...

Written By Axiom Admin

Last updated 22 days ago

For the Geeks

This page exists to give the serious reader enough mental model of the pipeline that they can trust what the rest of the manual says. It is not a reference implementation. It does not contain formulas, pseudocode, library internals, or numeric recipes presented as recommendations. What it does contain is the chain of operations the indicator runs, in language precise enough that you can reason about edge cases without having to read the source.

If you came here looking to reproduce the math, you should know up front that this is not the page for it. The math behind the moving averages lives in the Axiom MA library; the slot pipeline composes that library into a workbench. The math itself stays in the library, and the library stays out of this page on purpose.

The pipeline at a glance

For each enabled slot, the script does roughly the following, in this order:

  1. Decides which symbol to read — the chart symbol if the slot has no optional ticker, or the slot's optional ticker if one is set.

  2. Asks for the slot's higher-timeframe series of the chosen source — close by default — at the slot's configured timeframe.

  3. Computes RSI on that series at the slot's RSI length.

  4. Smooths the RSI with the slot's chosen RSI MA (length, type, and any type-specific tuning the slot's power-user knobs supply).

  5. Smooths the result again with the slot's chosen signal MA, producing the slot's calculated signal value.

  6. Clamps both the smoothed RSI and the signal value into the 0..100 range.

  7. Decides what to return for "this chart bar's value": the most recent confirmed previous higher-timeframe bar's value if On Bar Close? is on, or the live higher-timeframe bar's value if it is off.

That is one slot. The script repeats this for every enabled slot.

After the slot pipelines, the script combines them:

  1. For both the RSI value and the signal value, it computes a weighted average across enabled, non-zero-weight slots whose RSI value is available.

  2. It clamps the resulting blended pair into 0..100 for the unsmoothed blend.

  3. If master smoothing is enabled, it applies one additional smoothing pass to the raw blended pair using the master MA's length, type, and tuning.

  4. It clamps the final master-smoothed pair into 0..100.

Finally:

  1. The plot stage colors slot lines based on the relation of each slot's RSI to its signal (with an RSI-vs-50 fallback for the warm-up case where the signal is NA), colors the blended pair on the same rule, and draws everything inside the 0..100 frame defined by the reference lines.

That is the whole sequence. Everything else in the script is input wiring, alert plumbing, and visual configuration around this pipeline.

Why the clamp exists

RSI is by construction a value in the 0..100 range. So why does the script clamp anything at all?

Two reasons:

  1. Safety against edge cases in the smoothing chain. Some of the moving-average types in the library can, under unusual inputs (especially short series or extreme tuning), produce values that step momentarily outside the input series's range. Clamping each slot after smoothing keeps the slot lines visually honest.

  2. Honesty about the weighted blend. A weighted average of values that are individually inside 0..100 will also be inside 0..100, but only if the weights are non-negative and the average is computed on values that are not NA. The clamp on the blended pair is a defensive boundary that ensures the visible composite stays inside the frame the rest of the indicator is drawn against.

Practically, you should not see clamp activity in normal use. If you ever see a line pinned at exactly 0 or exactly 100, treat it as "the value the indicator can report has run out of room" rather than as a measured extreme of the underlying series.

Why the weighted blend ignores zero-weight and NA slots

The blend is computed by accumulating each slot's contribution: each slot's value times its weight, summed across the enabled slots, divided by the total of the active weights. Two cases drop out of that accumulation:

  • Zero-weight slots. A slot with weight zero contributes zero to the numerator and zero to the denominator. It cannot move the blended value. The script also explicitly skips zero-weight slots so they do not show up in the active-weight total.

  • NA slots. A slot whose RSI value is currently NA — typically during warm-up — has nothing to contribute. The script skips it in the numerator and in the denominator. The slot signal normally falls back to the slot RSI while its own MA warms up, so the blend's practical availability gate is the slot RSI value.

The reason this matters for your mental model: the blend is not a fixed-denominator average over all ten slots. It is an average over the slots that are currently capable of contributing. As slots warm up, the denominator can change. As you toggle slots on and off, the denominator changes. As you set weights, the denominator changes. The composite's responsiveness depends on which slots are actually in the average at the moment you are reading it.

Two consequences worth holding in your head:

  • A configuration where every weight is zero produces a denominator of zero. The blend has nothing to compute and is NA. The script does not silently fall back to equal weights; if you said no slot should steer the blend, the blend has nothing to steer with.

  • A configuration where one slot is dominating because of weighting is not visually obvious from the blended pair alone. The slot lines tell that story; the blend does not.

What master smoothing is doing

Master smoothing applies one more smoothing pass to the raw blended pair after the weighted average. The visible result is clamped after that pass. The pass uses its own MA type, its own length, and its own tuning, separately from the per-slot MAs.

This compounds with the per-slot smoothing in a specific way. Each slot's plotted RSI is already a smoothed value (raw RSI smoothed by the RSI MA). The signal is a further smoothed value on top of that. The weighted average across slots is a third operation. Master smoothing adds a fourth.

Practical implications of the compounding:

  • The total latency between the underlying price action and the master-smoothed blended pair is the sum (in some non-linear sense, depending on the MAs in question) of all four operations. Any one of them can be the dominant source of latency in a given configuration.

  • Increasing master length when per-slot smoothing is also long produces a result that is calmer than either smoothing alone would suggest, but at correspondingly more latency.

  • Reducing master length to zero (well, length 1 with a typical MA type) effectively passes the blend through unchanged. Disabling master smoothing entirely is more honest than running it at length 1 — fewer moving parts to mentally model.

Do not interpret the master-smoothed blend as "the same composite, just calmer." It is a different series — derived from the composite, but no longer sharing its responsiveness. Cross-check against the slot plots whenever the smoothed blend's behavior is doing the work in your read.

One more subtle property of the compounding: master smoothing applied to a blend of slots that each already smooth raw RSI twice (RSI MA and signal MA) means the visible blended RSI is, in informational terms, quite far from the underlying price's momentum. It is not that the information is corrupted — each smoothing step is deterministic and recoverable if you know the inputs — but the distance between what the price did this minute and what the master-smoothed blended RSI will show you about it is larger than most readers realize. If the blended pair feels numbed during active price moves, the numbing is the chain you built, not the market.

Why on-bar-close is implemented as "return the previous bar"

A reader who has seen other multi-timeframe tools may notice that this indicator does not implement repaint protection by simply hiding the slot until its higher-timeframe bar closes. Instead, the slot returns the previous confirmed higher-timeframe bar's value continuously, until the next bar closes and a new value becomes available.

There are good reasons for that choice:

  • Continuous plotting. A slot that hides between higher-timeframe closes would draw as a series of disconnected segments. The pane would be harder to read and would create the visual impression that the slot was unreliable. Returning the previous confirmed value instead keeps the slot's line continuous on every chart bar — the line is honest, and the value is the most recent thing the script can confidently say about that timeframe.

  • Consistent semantics across timeframes. With the on-bar-close switch on, every slot reports a confirmed previous-bar value. That is a consistent semantic across the whole pane. With the switch off on a given slot, that slot reports a live value. The two semantics live side by side without contaminating each other; the switch is per slot.

  • Symmetry of the alerts. Because alerts are gated on barstate.isconfirmed at the chart level, a slot that disappears between higher-timeframe closes would either fire alerts on phantom states or miss them entirely. Returning the previous bar gives the alert layer something concrete to evaluate on every confirmed chart bar.

The alternative implementation — hiding or holding the slot to NA between closes — would change the meaning of the pane in ways that are hard to undo. The chosen implementation makes the tradeoff explicit at a single switch instead.

What the script does and does not do with the higher-timeframe request

A short, honest description of the higher-timeframe data path, at the level of mental model rather than code:

  • The slot makes one higher-timeframe request per slot, per chart bar, per chart load. The request asks TradingView for the slot's chosen series at the slot's chosen timeframe on the slot's chosen symbol.

  • The request uses lookahead. Lookahead, on its own, would let the script see the future of the higher-timeframe bar before that bar has closed in real time — which is the source of repaint behavior in many naive multi-timeframe implementations.

  • The on-bar-close switch is the gate between the lookahead-enabled request and what gets returned to the rest of the script. With the switch on, the script returns the previous bar's value, fencing the lookahead. With the switch off, the script returns the live value, exposing the user to the live-bar movement they explicitly asked for.

The technical takeaway: the script is honest about which side of the gate you are on. It does not silently smuggle live values into a "confirmed" slot, and it does not pretend that the switch makes the live higher-timeframe value stop moving.

Why the alignment counts use enabled slots, not weighted slots

The alignment alerts (All RSI Slots Bullish, All RSI Slots Bearish) and the invisible counts (Active Bullish Count, Active Bearish Count) are computed over enabled slots whose RSI values are available — not over the slots with non-zero weight.

This is a design choice, not an oversight. Two reasons.

  • The blend already weighs slots. The blended pair is the place in the pane where weighting is expressed. The alignment count is a different question: do the slots agree with each other, regardless of how much steering they have? If alignment also weighed by weight, the count would collapse into a function of the blend, and the user would lose the ability to ask "how do my slots, considered as separate observations, compare?"

  • Disable is the cleaner mental model. A slot that is enabled is a slot the user is intentionally watching. A weight of zero says "do not let this slot steer the blend." Those are two different statements. By keeping alignment over enabled slots once their RSI values exist, the script forces the user to choose the appropriate mechanism for what they want.

The price of this choice: a user who expects alignment to mirror the blend will be surprised the first time a zero-weight slot breaks the alignment. The right response is to disable rather than zero-weight when the question is "which slots count?" The wrong response is to zero-weight everything you do not want in alignment and then wonder why the blend is empty.

What happens during the warm-up period

When the indicator is first added to a chart, or when a chart is reloaded, several values inside the pipeline are NA for a short period.

  • The RSI calculation needs at least its lookback length of bars before it can produce a value. The slot's RSI is NA before that.

  • The RSI MA needs at least its smoothing length of values before it can produce a smoothed RSI. The slot's plotted RSI is NA before that.

  • The signal MA needs at least its length of smoothed RSI values before it can produce a signal. The signal is NA before that.

While the signal is NA, the slot's color cannot be computed by the usual RSI-vs-signal comparison. The script falls back to comparing the slot's RSI to 50: above 50 is bright, below is dim. This is intentional — it gives the user a visible indication of the slot's state during warm-up — but it is not the same color logic as the rest of the slot's life.

The blended pair has the same kind of warm-up behavior. While the blended signal is NA, the blend's color falls back to RSI-vs-50.

Practical guidance: do not over-read the first handful of bars after a chart load. Let the warm-up complete before treating the colors as meaningful.

What is intentionally not on this page

Every absence here is on purpose.

  • Formulas for any MA type. The math lives in the Axiom MA library. This page does not reproduce it.

  • Pseudocode of the slot pipeline. The script implements the pipeline; the pipeline's mental model is what this page describes.

  • Library-side parameter relationships. The power-user knobs are listed in Settings by name; the relationships those knobs have inside the library are not something this page exposes.

  • Numeric "optimal" recipes. No combination of length, weight, MA type, or smoothing parameter is presented here as a recommendation. The trim is a workbench; the right configuration depends on what you are doing with it.

  • Internal function names from the script. The mental-model language in this page is deliberately phrased so that a reader can reason about the behavior without needing to know how it is named in code.

Posture

This page is here to make the rest of the pack believable. If a claim on Settings or Visuals and Logic seemed surprising, the pipeline above is the reason it is true. If the claim still seems surprising after reading this, the verification routines on MTF and Repainting and Workflows let you confirm the behavior on your own chart.

A working principle that sits behind the page: trust in an instrument is best built by understanding enough of its behavior that the edge cases stop being surprises. Not by hiding the mechanics, and not by exposing them so completely that the reader could reconstruct the tool. The middle — the mental model that lets you predict what the pane will do in a situation you have not yet seen — is what this page tries to give you. If you can close this page and answer "what would a length-50 master smoothing pass do to a blend that is currently mid-flip," you have the model. If you cannot, the page has failed for you and the verification routines on the other pages are the next move.

The instrument is honest about what it is doing. The point of this page is to make that honesty legible — not to hand you the parts list.

Where to go next