MTF and Repainting

This page exists because timing is one of the main trust boundaries in this indicator.

Axiom RSI Osc Lite can read higher timeframes inside each slot. That is useful. It also means you need a clean mental model for what is already settled, what is still forming, and what changes when the whole stack shifts timing posture. Without that, the pane can look steadier in hindsight than it felt in live use.

If this page feels abstract, keep one practical question in front of you: am I looking at a settled higher-timeframe read, or a still-building one?

Start with the hard rule

Every enabled slot timeframe must stay at or above the chart timeframe.

If it does not, the script throws a runtime error. This is not a suggestion or a preference. It is a hard guard in the script.

Practical examples:

• 1m chart with 5 / 15 / 60 slots: valid
• 5m chart with 5 / 15 / 60 slots: valid
• 15m chart with 5 / 15 / 60 slots: invalid until you raise or disable the 5 slot

If the script fails as soon as you load it, check this first.

The timing switch is global

This build uses one On Bar Close? control for the whole indicator.

That means one switch changes:

• RSI 01
• RSI 02
• RSI 03
• the blended RSI and Signal
• every alert surface that depends on those values

If you came here expecting a per-slot timing switch, slow down there. That is not how this build is wired.

What On Bar Close? does

When On Bar Close? is on

The stack uses the last settled requested-timeframe values for each slot.

In practice, that means:

• higher-timeframe slots wait for their requested bar to finish
• the pane is steadier in replay and in historical review
• the tradeoff is later reaction

This is the safer baseline when you are building trust in the stack.

When On Bar Close? is off

The stack uses the current requested-timeframe values while that requested bar is still forming.

In practice, that means:

• higher-timeframe slots can react sooner
• the pane can change more while the requested bar is still alive
• the tradeoff is less settled history-to-live continuity

This mode is not "wrong." It is simply less final.

If you have not already learned the confirmed version of the stack, do that first. Faster mode is much easier to overread when you do not yet have a calm baseline in memory.

Why broad repaint slogans are not helpful here

This indicator uses requested-timeframe data on purpose. That means the honest question is not "does it repaint, yes or no?" The honest question is "what kind of timing posture am I using right now, and what does that imply?"

Use language like:

• confirmed
• still forming
• steadier
• earlier but less final

Avoid language like:

• perfect non-repaint promise
• no repaint ever
• safe by default in every mode

Those phrases hide the actual tradeoff instead of explaining it.

Alerts still evaluate on chart bar close

This matters because some readers expect the alert timing to mirror the slot timing exactly.

In this script:

• slot and blend values can come from confirmed or still-forming requested-timeframe reads
• alert conditions are still evaluated on the chart bar close

So you can have a stack that is reading live-forming higher-timeframe values while alerts still wait for the chart bar to close before firing.

That is one more reason to test timing in replay before you rely on the alerts.

What changes when you move across timeframes

Moving from one chart timeframe to another can change:

• whether the default ladder is still legal
• how often the higher-timeframe slots update
• how quickly the blend looks responsive
• how much weight a slower slot seems to carry visually

Do not assume a stack that felt stable on one chart timeframe deserves the same trust on another without a fresh check.

A replay routine that makes the timing tradeoff visible

Use a 1m chart if possible so the default 5 / 15 / 60 ladder stays valid.

1. Load the indicator with defaults.
2. Keep On Bar Close? on.
3. Find a stretch where the 15 or 60 minute slot is near a visible turn.
4. Step forward in replay and watch how slowly or cleanly that slot updates.
5. Restart the same area and switch On Bar Close? off.
6. Step through the same bars again.
7. Compare how much sooner the higher-timeframe slot moves and how much more it can change before the requested bar finishes.

What you should leave with:

• confirmed mode is steadier and later
• forming-bar mode is earlier and less settled
• the whole stack moves with that choice

If that difference is still hard to see, keep replaying it. The timing boundary is too important to leave as a vague impression.

A simple way to keep timing honest

If the stack is new, use this sequence:

1. build the slot ladder on a legal chart
2. leave On Bar Close? on
3. learn how slot disagreement and blend behavior feel in confirmed mode
4. only then test live-forming timing
5. if you keep live-forming timing, verify it again after any change in chart timeframe or slot ladder

That sequence is not about caution theater. It is about making sure the faster mode is a choice you understand, not a switch you forgot you touched.

Common timing mistakes

"I only changed one fast setting."

If the setting was On Bar Close?, you changed the whole stack.

"The chart looks clean in hindsight, so that must be how it behaved live."

That depends on timing mode. Check replay before you trust the memory.

"If alerts wait for close, the slot values must be confirmed too."

Not necessarily. Alert timing and requested-timeframe timing are related here, but not identical.

What to remember when timing starts to blur

Treat On Bar Close? as a whole-stack trust choice: on is steadier and slower, off is earlier and less final.

> Visual placeholder: Replay comparison showing the same 1m sequence twice, with On Bar Close? on in one example and off in the other, plus callouts for which slot values are already settled and which are still forming.