MTF and Repainting

This page exists because the main trust boundary in Axiom CVD Osc Lite is behavioral, not cosmetic.

Multi-timeframe oscillators can look neat on history and still behave differently live if they are reading a higher-timeframe bar before that bar has closed. This indicator gives you one direct switch for that tradeoff, and it applies to the whole stack.

If you skip this page, it becomes much easier to build habits around a chart behavior you did not actually mean to trust.

That is why this page should come early. Most avoidable confusion in this indicator is not a mystery in the math. It is a mismatch between the trust mode the stack is using and the trust mode the trader thinks it is using.

The two modes

On Bar Close? | What the stack reads | What you gain | What you give up

• On — The last closed higher-timeframe values for every active slot; Better alignment between history and live behavior; Earlier feedback from still-forming higher-timeframe bars
• Off — The current still-forming higher-timeframe values for every active slot; Earlier awareness of what the higher timeframe is doing right now; A weaker trust boundary because the stack can move before the higher-timeframe bars close

If you only remember one line from this page, make it this: Earlier is not the same as safer.

What repaint means here

In this indicator, repaint risk is not a vague accusation. It is a specific behavior.

When On Bar Close? is off:

• active slots can update while their higher-timeframe candles are still open
• the stack can look cleaner in hindsight than it felt live
• the blend inherits those live-forming slot values

When On Bar Close? is on:

• the stack waits for the last confirmed higher-timeframe values
• the chart gives up some speed
• history and live observation are easier to compare honestly

This is why the manual avoids blanket no-repaint language. The tool gives you a trust choice. It does not erase the tradeoff.

The geometry rules that make the stack valid

Each enabled slot has to respect three hard rules:

1. slot timeframe must be at or above the chart timeframe
2. Lower TF Precision: must stay below the slot timeframe
3. Window: must stay at or above the slot timeframe

Those rules matter because this script is not only requesting one higher timeframe. It is also building a lower-timeframe sampling path and an active window around that slot.

If one of those relationships breaks, the script stops rather than pretending the request is still meaningful.

Why lower-timeframe precision matters

The slot tries to estimate participation from lower-timeframe OHLCV arrays inside the requested slot context.

That is why the lower-timeframe sampler has to stay below the slot timeframe. If it does not, the script loses the sampling hierarchy it was designed to use.

You do not need to know the internal recipe to use that rule well. You only need to remember the practical point: the lower sampler is there to refine the slot's evidence, not to collapse the slot into the same timeframe.

Why the window rule matters

Window: defines the active range the slot is allowed to accumulate across.

That means the window has to be large enough to hold the slot timeframe honestly. If the window is smaller than the slot timeframe, the slot no longer has a coherent container for its accumulation logic.

So treat the window rule as structural, not arbitrary.

Session mode versus Rolling mode

This page is about MTF trust, but window mode belongs here too because it changes how time behaves inside the slot.

Session mode

• the slot resets when the chosen anchor changes
• the slot can draw reset markers if it is visible
• the active story is "since this anchor started"

Rolling mode

• the slot keeps a sliding time window
• there are no reset markers
• the active story is "inside this moving duration"

Neither mode is more correct in the abstract. They answer different questions.

The chart-bar-close rule is separate

All alert conditions in this script are chart-bar-close gated.

That does not mean the higher-timeframe inputs are always confirmed.

If On Bar Close? is off, the stack can still be using live-forming higher-timeframe slot values by the time the chart bar closes. Keep that distinction visible:

• chart-bar-close gating controls when the alert condition becomes true
• On Bar Close? controls whether the slot data itself is confirmed or live-forming

If you mix those ideas together, the tool starts sounding safer than it is.

A five-minute verification drill

Run this once before you build habits around live-forming mode.

1. Open a chart timeframe that can legally request a higher slot timeframe.
2. Keep one slot on a clearly higher timeframe than the chart.
3. Leave On Bar Close? enabled and watch the slot during an unfinished higher-timeframe candle.
4. Notice that the slot stays anchored to the last closed higher-timeframe reading.
5. Turn On Bar Close? off.
6. Watch the same unfinished higher-timeframe candle again.
7. Note whether the slot or the blend now shifts before that higher-timeframe candle is finished.

What you are trying to learn is not whether one mode is morally better. You are trying to learn which trust tradeoff your workflow can actually carry.

When confirmed mode is usually the better default

Stay with confirmed mode when:

• you are still learning the indicator
• you care about cleaner history-to-live consistency
• you want the slot stack to behave in a more reproducible way
• you are building alerts around higher-timeframe structure and want fewer hidden moving parts

When live-forming mode may be worth testing

Test live-forming mode when:

• you know why earlier higher-timeframe feedback matters to your process
• you are prepared to verify it on live bars or replay
• you are willing to accept that the stack can move before the higher-timeframe candle closes

Even then, test it with one restrained stack first.

Common misuse to avoid

The common mistake is not turning confirmed mode off.

The common mistake is turning it off and then continuing to talk about the pane as though nothing about trust changed.

That usually shows up as:

• reading the live-forming stack like hindsight-clean evidence
• forgetting that the whole stack shares one trust choice
• assuming chart-bar-close alerts removed the higher-timeframe tradeoff

A healthy sentence to be able to say

"This stack is confirmed" or "This stack is live-forming." If you cannot say one of those clearly at a glance, the tool is already carrying more ambiguity than it should.

Visual placeholder: Side-by-side chart captures of the same stack with On Bar Close? on and off during one unfinished higher-timeframe candle, plus a second callout showing the slot-timeframe, lower-timeframe, and window rules.