For the Geeks

This page exists to raise trust, not to hand anyone the ability to reimplement the tool. You will not find Pine patterns here, no wrapper signatures, no offset constants, no pseudocode, no formulas, no thresholds, no keywords that make a particular request behave a particular way. If you are reverse-engineering the indicator, you will leave this page disappointed. That disappointment is the page working as intended.

What you will find is the mental model behind three mechanics that are not obvious from the inputs dialog, plus one candor note on a source-code artefact that a careful reader will otherwise stumble on and misinterpret. Each mechanic closes with a verification drill a reader can run in a minute on their own chart. The point of the drill is to make sure you never have to take a description on faith — if the manual is claiming something about how this tool computes, the tool should be demonstrating it under a test you can run yourself. That is the trust contract.

The three mechanics:

• A. The confirmed-value higher-timeframe request used by every slot.

• B. The cross-symbol scaling used when a slot has an Optional Ticker:.

• C. The weighted blend and the majority-vote rule that resolves its trend colour.

The candor note concerns the dead SLOT_SCALE_MODE_TT tooltip — a tooltip constant the source declares that the shipped build does not actually expose as an input.

A — The confirmed-value HTF request

The problem this mechanic solves

A naive higher-timeframe MA on a low-timeframe chart is easy to compute. It is also easy to get wrong. The two subtle failures look similar on a chart in replay and diverge on live money.

• Peeking at future data. Under some request configurations, the HTF value drawn on a low-timeframe bar can have been computed using data from a bar that, at that bar's real-world timestamp, had not happened yet. This is the "it knew the future" failure.

• Drifting on the live bar. Under other request configurations, the HTF value drawn on the current low-timeframe bar is the live HTF value — correct at the moment but free to change as the HTF bar continues forming. Replay shows the final value; live trading shows the walk.

Axiom MA CTX sits on this problem explicitly. Every slot carries an On Bar Close? switch. ON returns the last confirmed value of the slot's higher timeframe — a value that will not redraw. OFF returns the live HTF value — correct now, free to redraw until HTF close. The slot's posture is yours to set, and the tool is honest about which posture it is running under.

What the mechanic does in plain language

Under ON, the slot's line draws using the slot's MA from the last fully closed HTF bar, delivered to the chart without peeking at future data. The line does not move between HTF closes. At each HTF close the line steps.

Under OFF, the slot's line draws using the slot's MA from the current, still-forming HTF bar. The line can move continuously as the chart advances, because the HTF bar is still accumulating the data the MA depends on. When the HTF bar closes, whatever the live read was at that moment becomes the final value, and the next HTF bar's live read begins.

The cost is symmetric. ON buys honesty with up to one HTF bar of latency. OFF buys reactivity with repaint exposure to the live HTF bar.

Main tradeoff versus a simpler approach

A simpler approach — one call to the market function asking for the HTF MA, nothing else — can silently pick either posture depending on how it is configured, and a reader who does not know the request's exact configuration cannot tell which one they are getting. The approach in Axiom MA CTX spends a little code to make the two postures explicit, user-selectable, and verifiable. The gain is that the reader knows what posture they are running under. The cost is that they have to make a choice.

What you can verify on your own chart

The drill from Quick Start and MTF & Repainting is the verification drill. Load the three defaults on a 1-minute chart. Flip Slot 01's On Bar Close? between ON and OFF, watching one full 5-minute cycle each time. Under ON the line steps at the 5-minute close and is still between closes. Under OFF the line drifts inside each 5-minute bar. That is the whole thing. If you can see that behaviour, you have verified the mechanic.

B — Cross-symbol scaling

The problem this mechanic solves

A cross-symbol MA is useful context. Drawing an MA of BTC on an SPX chart can tell a trader something about how the smoothed shape of one aligns with the other. Drawing the same MA at BTC's native price range plots it off-chart or at an unreadable corner of the pane. Drawing it at chart price gives you a visible reference you can interpret at a glance.

The question is how to project it. A full volatility-adjusted transform would be more ambitious and still not predictive. A currency translation would require knowing the exchange rate at the relevant moment, which on asynchronous symbols is already stale. A single close-ratio multiplication is the legible choice: take the alternate symbol's MA, multiply by the ratio of chart close to alternate close at the slot's HTF, and the line lands in chart price space.

What the mechanic does in plain language

When a slot has an Optional Ticker: set, the tool requests the MA on the alternate symbol at the slot's timeframe. It also requests the closes of both the chart symbol and the alternate symbol at the slot's timeframe, under the slot's On Bar Close? posture. When the ratio of those two closes is available, it becomes the scale factor. The alternate symbol's MA is multiplied by that factor, and the product is plotted. If the ratio cannot be computed, the current build can leave the requested MA effectively unscaled.

What the product represents is the alternate symbol's smoothed shape, expressed in chart price units at the current ratio between the two symbols' HTF closes. The shape is the alternate symbol's. The placement is an artifact of the ratio.

Main tradeoff versus a simpler approach

A one-ratio scale is visually anchored to the chart and easy to explain. It is also unforgiving of session mismatch, regime divergence, and unavailable scale data. If the alternate symbol's session is closed, the scale ratio can be stale. If the two symbols' volatility regimes have drifted apart, the scaled line can sit visibly far from chart price even though the underlying shape is perfectly valid. If the ratio cannot be computed, the line can look raw rather than translated into chart price space. These are not leading reads; they are the known costs of a single-factor rescaling path. The alternative — a heavier statistical transform — would be less legible, more computationally expensive, and would still not make the line predictive.

What the mechanic does not claim

It does not claim the alternate symbol leads the chart symbol. It does not claim the alternate symbol's direction will pull chart price in the same direction. It does not claim the scaled MA's distance from price is a momentum read. It is a rescaling that places an alternate shape on the chart when the scale ratio is available.

What you can verify on your own chart

Enable a slot with Optional Ticker: empty. Set Type:, Length:, Source: to match any standard MA you already run on the chart symbol. The slot's line should overlay that standard MA modulo any one-bar offset from the slot's repaint posture.

Now set Optional Ticker: to a close relative of the chart symbol — SPY on a QQQ chart, for example. The slot's line now tracks SPY's smoothed shape and, when scaling is available, lands in QQQ's price space. Compare the line's shape against SPY's native chart; they should rhyme. Compare against QQQ's price; they should not be expected to align.

C — The weighted blend and the majority-vote trend

The problem this mechanic solves

A composite line must declare its rule to be worth reading. "Some combination of the enabled slots" is not a rule; it is a vague promise. Axiom MA CTX declares both the rule for the composite's value and the rule for its direction.

What the mechanic does in plain language

For the value. Every enabled slot whose Blended Weight: is non-zero contributes. The blended value at each chart bar is the sum of each contributing slot's current MA multiplied by that slot's weight, divided by the sum of the contributing weights. Weight-normalized averaging. Slots whose weight is zero are not in the sum, whether their plot is visible or not. Slots whose Enable is off are not in the sum. Slots whose plot is hidden but whose weight is non-zero are in the sum. A weighted slot that lacks a usable value is not treated as a clean abstention, so sparse or unstable data should be muted or disabled before it is allowed to steer the blend.

For the direction. For every enabled contributing slot, the slot's trend state (up or down, driven by the slot's own Trend Length comparison on the slot's timeframe under the slot's own repaint posture) is read. The tool tallies the weight across up-voting slots and the weight across down-voting slots. If up-weight is greater than or equal to down-weight, the blend registers as uptrend. Ties — including equal weights split evenly — register as uptrend.

That is the full rule. The blend is a weighted composite with a named, disclosable direction vote.

Main tradeoff versus a simpler approach

A simpler approach might read the direction off the blended line itself — compare the current blended value to the blended value N bars ago. This sounds more honest but carries a subtle trap: the blended line is a weighted average, and an average of disagreement can be nearly flat even when the underlying slots are strongly diverging. A slope-on-the-blend rule would frequently report "flat" or flip direction at small noise, without telling the reader that the flat was the result of cancellation.

A majority-weight vote trades slope-based rigour for interpretability. The direction is a function of what the slots voted, weighted by how much voice each slot was given. The reader can read the rule, run it in their head against the slot colours, and predict the blend's colour before looking at it.

What the rule does not claim

It does not claim the blended line is a better MA. It does not claim the blend "knows" something the slots do not. It does not claim agreement when the rule is really majority. A weight-heavy slot can drag the direction one way while the other slots vote the other. That is correct behaviour given the weights; it is also why the weights matter.

What you can verify on your own chart

Enable two slots with equal weight on the same timeframe, length, and type. The blended value should equal the simple average of the two. Change one weight to zero; the blend should snap to the other slot's value.

For the direction: pick three slots with equal weights. Arrange timeframes or lengths so two slots vote up and one votes down. The blended colour should read lime. Now redistribute weights so the down-voting slot carries more total weight than the two up-voters combined. The colour should flip to red.

Candor note — the dead SLOT_SCALE_MODE_TT tooltip

This is not a roadmap claim. This is a candour item — the kind of thing a manual has to name when the source and the shipped behaviour are slightly out of alignment, because the alternative is a reader hunting for a feature that does not exist and eventually deciding the tool is broken.

The source of Axiom MA CTX declares a tooltip constant named SLOT_SCALE_MODE_TT. Its text describes three cross-ticker scaling modes — "None," "Anchored To Chart," and "Dynamic To Chart." A careful reader opening the inputs dialog, or reading through the script, will see the tooltip and reasonably expect an input selector adjacent to the per-slot Optional Ticker: control offering the three modes.

That selector does not exist in the shipped build. No input.enum consumes the tooltip. Every cross-ticker slot runs through the single close-ratio scaling path described under mechanic B. There is no separate "None" mode that turns scaling off while keeping the alternate ticker active. There is no distinct "Anchored To Chart" behaviour. There is no distinct "Dynamic To Chart" behaviour. There is one scaling path, and it is the one the other pages of this pack document.

The manual names this so a reader who went looking for the modes and could not find them has a clean explanation that does not require inventing one under pressure. The tooltip is not a hidden feature the reader is failing to unlock. The build is not miscompiled. The installation is not broken. The tooltip describes intended behaviour the current build does not expose yet — and until it does, the manual's position is to say so rather than to paper over the gap.

If a later script revision wires the input.enum, the modes will be documented in that release's manual, with no promises made here about which modes will ship or how they will behave. If a later revision removes the tooltip constant, this note goes with it. Either way the manual and the script will agree on what the tool does, because the manual has no interest in promising anything the code does not do and no interest in hiding anything the code announces.

Why this page stops where it does

Everything above can be disclosed because it raises trust without handing anyone the pieces they would need to clone the implementation. The specific request patterns, the keyword that governs how the HTF request behaves, the exact bar offset separating confirmed from live, the function signatures, the accumulator structure, and the comparison site that implements the tie-break — none of those appear on this page on purpose. You do not need them to trust the tool. The reader who does need them is usually not trying to trust it at all.

That line is drawn deliberately and the reason matters. The same candour that names the dead tooltip above is what refuses to publish the request pattern. A manual that describes behaviour honestly and still declines to produce a source-level walkthrough is doing both halves of the same job — telling the reader what the tool does, and protecting the people who built it from the effort of rebuilding a commodity of their own work.

If something above leaves you wanting a deeper explanation of a specific MA family (ALMA, KAMA, FRAMA, Jurik, Laguerre, VAMA), that depth belongs in the Axiom MA Pro library's own manual at ../../libraries/axiom-ma-pro/README.md. The library is the one computing those MAs. This indicator calls into it and inherits whatever the library's manual promises about the type.