For the Geeks

A quick frame before you read this page.

This is a trust page. Its job is to describe two pieces of the indicator's internal behaviour in enough detail that a careful reader can understand the reasoning and verify the result — without turning the page into an implementation walkthrough. It will not publish formulas, thresholds, pseudocode, the exact request wrapper pattern, the offset used inside the higher-timeframe expression, the accumulator loop that composes the blend, or the tie-break as written in code. None of that ships. What ships is the behaviour in mental-model language and a verification drill you can run yourself.

Two mechanics on the Base trim deserve that treatment: the confirmed-versus-live higher-timeframe posture, and the weighted blend with the majority-vote basis-trend rule.

Mechanic A — The confirmed-higher-timeframe posture

Why a naive higher-timeframe request is a trap

A multi-timeframe indicator has a real choice to make about how to read a higher-timeframe value onto a lower-timeframe chart. There are three families of approach, and two of them are dishonest in different ways.

• Naive request, no lookahead. The slot asks for the higher-timeframe value and gets the last completed higher-timeframe bar's value — but the request mechanism on most charting platforms returns that value offset by one higher-timeframe bar on history. Live, you see current values; on history, you see the bar from one higher-timeframe period earlier. The chart looks one way live and another way on replay, and the reader has to reason about which replay mode they are in.

• Lookahead on, no offset. The slot asks for the higher-timeframe value with a lookahead flag turned on. On history, the request returns values from higher-timeframe bars that had not yet closed relative to the chart bar position — which is a form of future-peeking. The chart looks decisive on replay because each chart bar is paired with a higher-timeframe value that was computed with information the reader would not have had in real time. This is the posture that produces the "96% accuracy" backtest and the disastrous live result.

• Explicit confirmed or live, under a named toggle. The slot returns either the previous confirmed higher-timeframe bar's values (honest under both live and replay, at the cost of one higher-timeframe bar of latency), or the current live higher-timeframe bar's values (honest about being live, with redraw exposure until the bar closes). The reader chooses, and both postures behave the same way live as they do on replay.

The Base trim uses the third approach. On Bar Close? is the switch. ON is the confirmed posture. OFF is the live posture. Both postures are documented behaviours — including their costs — rather than optimizations packaged as defaults.

The posture in plain language

ON. On each chart bar, each slot returns the values from the previous completed higher-timeframe bar for its Source:, Length:, StdDev Mult:, and Type:. The slot's three lines on your chart are the values at that previous higher-timeframe close. They do not change during the current higher-timeframe bar. When the current higher-timeframe bar closes, those values become the basis for the next chart-bar period, and the line steps.

OFF. On each chart bar, each slot returns the values from the current, still-open higher-timeframe bar. The higher-timeframe bar's close is not settled yet, which means the slot's values — computed from that bar — can change as the higher-timeframe bar's constituent ticks continue to update. The slot's three lines can drift during the higher-timeframe bar window, and the lines on past chart bars within that window can shift with them.

What the toggle is not doing

The toggle is not turning a smoothing filter on and off. It is not swapping algorithms. It is not applying a "stability pass." It is picking which higher-timeframe bar's values are being returned to the chart — the previous one (confirmed) or the current one (live). Everything else in the indicator is the same on both settings.

Why the toggle is global on the Base trim

The Base trim makes this a single global switch on purpose. A per-slot toggle would expand the inputs surface by one bool per slot, every teaching passage would branch, and the reader would have to track which slots are in which posture. The CTX trim accepts that surface cost; the Base trim does not. If per-slot control is what you need, switching trims is the right move. The Base trim's design boundary is part of what makes it the Base trim.

Verifying the posture on your own chart

You can verify both behaviours in about ninety seconds with the shipped defaults.

1. 1-minute chart. Default slots. On Bar Close? ON. Watch Slot 01 (the 5-minute teal lines) over one full 5-minute bar. The three lines hold, and step at the 5-minute close.

2. Flip On Bar Close? OFF. Watch Slot 01 over another full 5-minute bar. The three lines drift during the 5-minute bar and settle at its close.

3. Flip back to ON.

Two things you have now verified directly: the toggle does what this page says, and the toggle is not per-slot — Slot 02 and Slot 03 move together with Slot 01 when you flip it.

Mechanic B — The weighted blend and the majority-vote basis-trend

Why a composite must declare its rule

Any indicator that blends several inputs into one line owes the reader a statement of the blending rule. Without that statement, the composite is a verdict dressed up as a read, and the reader is treating a hidden decision as if it were a measurement. The distinction matters in both directions. A declared rule — even a rule you might disagree with — is something you can reason about, accept, reject, or offset with your own judgment. An undeclared rule cannot be reasoned with at all; it can only be trusted or distrusted as a whole, and traders who have been burned by a few undeclared composites over the years tend to distrust them rightly. The Base trim's composite — the red upper, the red lower, the lime basis — is composed by a rule that is simple enough to hold in your head, which is the whole reason it is worth stating.

Two rules, actually. One for the bands and one for the basis-trend direction.

The band rule

For each band — basis, upper, lower — the blended value is the weighted average of the corresponding slot values across enabled slots whose Blended Weight: is non-zero, as long as those contributing weights sum above zero.

In plain words: for each slot that is enabled and has a non-zero weight, multiply its band value by its weight. Sum those products. Divide by the total weight of the contributing slots. That is the blended band's value for that bar when the total weight is positive. Do it for upper, basis, and lower independently.

A weight of zero excludes the slot from the sum and from the divisor. A disabled slot is excluded entirely. The script does not enforce positive weights, though, so keep normal blend configurations at zero or positive values. If the contributing weights sum to zero or less, the script returns zero values rather than a meaningful composite.

One warm-up edge is worth saying out loud because it is not the cleanest possible behaviour. A slot still waiting on enough history can return na, and the runtime pushes nz(...) values into the blend arrays. That means early warm-up slots can contribute zero-valued bands instead of being skipped. Do not read the blended band as ready until the enabled slots have valid values.

Consequences worth naming:

• Three slots at 33.3 / 33.3 / 33.3 is a simple average of the three bands.

• Two slots at 50 / 50 is a simple average of the two. Setting the third slot's weight to zero produces exactly that read.

• Two slots at 70 / 30 is a weighted blend where the 70-weight slot pulls the composite more strongly. Dropping the 30-weight slot's weight to zero snaps the composite onto the remaining slot's band exactly.

You can verify every one of those claims directly on your chart by changing weights and reading the blended basis value from TradingView's data window.

The basis-trend rule

The blended basis-trend state — the yes-or-no the two blended basis-trend alerts read from — is decided by a weight-majority vote across the same set of slots that feed the band composition.

• Each contributing slot has a basis-trend state of its own: uptrend if its basis is greater than or equal to its basis value Basis Trend Length bars ago, downtrend otherwise.

• The indicator sums the weights of slots whose state is uptrend and the weights of slots whose state is downtrend.

• The blended basis reports uptrend when the uptrend weight is greater than or equal to the downtrend weight. Ties count as uptrend.

• It reports downtrend when the downtrend weight is strictly greater.

Why ties count as uptrend

Any tie-break rule is, by nature, an arbitrary choice about which side wins when the vote is split exactly. The indicator picks uptrend on purpose and names the choice rather than leaving it buried. What matters is that the rule is stable and declared; you can reason about edge cases without guessing. If a tie-break in favour of downtrend would change a read you are doing, the correct response is to set weights that make exact ties unlikely — or to read the per-slot states directly for that decision rather than the blended vote.

The deeper point, and the reason to state the tie-break at all, is that the honest version of "the edge case happens rarely" is not "so we hid it." An edge case that happens rarely is still an edge case that eventually happens to someone, and the reader who trips it should not be left reverse-engineering the tool's behaviour from a surprising alert fire. Stating the rule where ties go is how the tool stays answerable at its seams instead of only at its middle.

Why a vote instead of a blended-curve slope

The intuitive alternative is "read the slope of the blended basis curve over Basis Trend Length bars." That works fine when all slot weights are similar and all slot basis-trend lengths are similar. It breaks in two specific cases:

• When the slot weights are uneven, a curve-slope read produces a number that depends on which timeframe's basis is doing the most pulling — which is a legitimate read, but it is a different read from "majority of the voices you are listening to agree."

• When the slot basis-trend lengths differ across slots, a single curve-slope over a single lookback collapses several lookback choices into one. The voting rule respects each slot's own Basis Trend Length:.

The vote is not the "right" rule in every sense. It is the rule that matches how the reader is already reading the slots — each slot has its own basis-trend state already, and the vote aggregates those states in proportion to the weights the reader set. That is cleaner to explain and cleaner to reason about than a lookback-over-a-weighted-curve read.

Verifying the blend rule on your own chart

Two short drills.

Band composition. Enable only Slot 01 and Slot 02. Set both Blended Weight: values to the same number — for example, 50 / 50. Read the blended basis value from the data window. It should equal the simple average of the Slot 01 basis and the Slot 02 basis. Now set Slot 01's weight to 0. The blended basis should snap onto Slot 02's basis exactly.

Majority vote. With the shipped defaults and three enabled slots, find a state where one slot is in uptrend and two slots are in downtrend. Blended basis-trend should read downtrend; the corresponding alert, at chart bar close, will fire downtrend. Now give the uptrend slot a weight greater than the sum of the other two — for example, 60 / 20 / 20 with the uptrend slot at 60. At chart bar close the blended basis-trend should flip to uptrend, because the uptrend weight is now the majority.

Protected implementation detail

What this page intentionally does not describe:

• The specific higher-timeframe request wrapper pattern, including the offset used inside the higher-timeframe expression and the lookahead setting at the request boundary.

• The accumulator loop that computes the weighted band sums and the weight totals.

• The exact code form of the tie-break for the basis-trend vote.

• The Lite moving-average library's internal moving-average implementations.

• Any formulas, thresholds, or pseudocode.

None of those are required for trust. The behaviour and the verification drills above are. If you have reached this page wanting the implementation to be disclosed, the honest answer is that the trust we are trying to build is about being able to name, verify, and reason about what the tool is doing — not about being able to reproduce the tool from its documentation.