For the Geeks

A note before the mechanics.

This page exists because two parts of Axiom MA work in ways that deserve an honest mental-model explanation — not a summary, not a reimplementation guide. A careful reader is entitled to know why the confirmed-bar higher-timeframe read is shaped the way it is, and how the weighted blend decides its trend colour. Both questions reasonably carry weight when the rest of your process is on the line.

This is not a pseudocode walkthrough. You will not find a reproducible Pine pattern here, and you will not find the variable names or the offset values that make the implementation possible. Axiom ships adaptable, customisable tools — not publishable recipes. What you will find is enough of the mechanism to raise your trust in the tool without handing the implementation detail to someone who would ship it elsewhere.

If that framing is acceptable, the two mechanics below are the ones that matter.

Mechanic A — the bar-close-gated higher-timeframe read

The problem this mechanic solves

A naive multi-timeframe moving average has two honest failure modes in Pine:

• It can peek into the future under some lookahead postures. Concretely: at a given chart bar, a poorly configured higher-timeframe request can return a value that will only actually be known after the HTF bar closes. On historical bars this looks impossibly clean; on live bars it has no way to exist.

• It can drift on the live higher-timeframe bar. Under the postures that avoid the future-peek, the HTF request returns the provisional value of the currently-forming HTF bar. That value is a legitimate reading of the live HTF state, but it is not stable — it can change multiple times before the HTF bar closes, and readers who mistake it for a closed-bar read are being set up for a surprise.

Either failure is the kind of thing that can make a tool look trustworthy in replay and then misbehave on the live chart. Axiom MA Base is explicitly written to avoid both under its shipped ON posture, and to disclose the live alternative honestly when you choose OFF.

What the mechanic does, at the level of mental model

The slot's MA and its trend state are evaluated in the slot's higher-timeframe context. The global On Bar Close? switch then selects between two outputs:

• Under ON, the slot returns the last confirmed higher-timeframe bar's MA value and its trend state. That is a stable reading — it will not change once the HTF bar it reports has closed.

• Under OFF, the slot returns the current (live) higher-timeframe bar's MA value and its trend state. That is a provisional reading — it is the real state of the live HTF bar right now, and it can move as the live HTF bar continues to form.

Under ON, the slot's value at a given chart bar is the last confirmed HTF value. Under OFF, the slot reports whatever the live HTF bar is showing in the moment, and that value can move until the HTF bar closes. Do not read OFF-mode historical/replay output as if it preserves every value the live HTF bar showed while it was forming.

Why the switch is global rather than per-slot in Base

This is the part that surprises readers coming from the CTX trim, so it is worth spending a paragraph on.

The CTX trim carries a On Bar Close? input per slot — ten of them, in fact. That surface is the right fit for a reader who wants to run some slots confirmed and others live. It comes with a cost: every slot is now a posture decision in addition to a timeframe / length / type decision, and the reader has to carry that matrix in their head whenever they tune the tool.

The Base trim ships one switch for all three slots on purpose. The narrower surface enforces a clearer mental model: under the shipped posture, every HTF line you see has already closed at its reported value. Under the alternative posture, every HTF line you see is live and drifting. You do not have to remember which slot is which. You flip once and the whole overlay takes one shape or the other.

That is a trim choice. It is cheaper to reason about and more expensive to tune. If your use case genuinely wants one slot live while the others are confirmed, Base is not the trim — CTX is.

User verification path for Mechanic A

One path, simple to run, that distinguishes the two postures visibly.

1. Open a 1-minute chart of a liquid regular-session symbol with Base defaults loaded.

2. With On Bar Close? ON, watch Slot 03's purple line across a 60-minute cycle. The line should hold flat through the full 60-minute bar and step forward when the 60-minute bar closes.

3. Flip On Bar Close? to OFF. Watch the next 60-minute bar. The line now drifts inside the 60-minute bar as new 1-minute ticks refine the live 60-minute candle. It can change colour inside the 60-minute bar and change back before the bar closes.

4. Watch Slots 01 and 02 during the same flip. Both slots also change posture — Slot 01's 5-minute cadence melts into drift inside each 5-minute bar, and Slot 02's 15-minute cadence does the same inside each 15-minute bar. This is the global scope of the switch, visible in real time.

5. Flip On Bar Close? back to ON. All three slots return to confirmed-bar steps.

If all three slots move together under the flip, the switch's global scope is behaving as this section describes. If only one slot's posture changed, something is wrong with the indicator build; please report it with the diagnostic information requested in Troubleshooting.

What this section deliberately does not publish

• The exact Pine request shape that implements the confirmed-value behaviour.

• The specific lookahead posture used around the request, and the specific offset applied inside the higher-timeframe expression.

• The function signatures of the per-slot and HTF-expression wrappers.

• The ordering of the MA computation and the trend comparison inside the HTF expression.

These are the load-bearing implementation details that make the pattern work. You do not need them to use the tool honestly; anyone who needs them for a competing product does not need them from us. The mechanism is named; the recipe is not.

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

The problem this mechanic solves

A user-configurable composite line has to declare its rule. If it does not, the line is a black box with user-tunable knobs that change the box's output in ways the user cannot reason about. A reader who cannot explain why the composite moves cannot use the composite with confidence, and cannot recognise when the composite is telling them something the component slots are not.

Axiom MA Base chooses the simplest honest rule in two parts: a weight-normalised average for the composite's value, and a weight-majority vote for the composite's trend colour. Both halves are disclosable in plain words, both halves can be verified on your own chart, and neither half depends on any detail you cannot see in the inputs dialog.

What the mechanic does, at the level of mental model

The blended value. For each enabled slot with a non-zero Blended Weight:, take the product of that slot's current MA value and that slot's weight, and accumulate both the product and the weight. At the end, divide the accumulated product by the accumulated weight. The result is the weighted average of the contributing slots' values when the contributing setup has usable positive total weight. If the blend is enabled with no usable positive voting-weight setup, the current source can leave the blend at its default 0/down state; that is a configuration problem, not a read.

Two properties fall out:

• Proportionality. With positive contributing weights, (20, 20, 60) and (1, 1, 3) produce the same blended value, because the divisor normalises across whatever the weights sum to. There is no hidden requirement that the weights sum to 100.

• Silent exclusion on weight zero. A slot with Blended Weight: of zero is skipped entirely by the accumulator. Its value does not enter the sum and its weight does not enter the divisor. The slot's line can still be on the chart and the slot's per-slot alerts can still fire; the slot is simply silent in the blend.

The blended trend colour. Accumulate the weight of up-voting slots separately from the weight of down-voting slots, across the same set of contributing slots. If the up-weight is greater than or equal to the down-weight, the blend reports uptrend. Otherwise it reports downtrend. That decides the line's colour (lime or red) and the blended-trend alerts' direction.

Three properties to hold in your head:

• The colour is a vote, not a slope. A flat blended line can read lime or red because the line's slope is not part of the decision. The decision is entirely about which side has more voting weight.

• Ties go to uptrend. Because the comparison on the up-weight side is >=, a tie — up-weight exactly equal to down-weight — resolves as uptrend. This is an asymmetry and is disclosed on purpose.

• Heavy weight can outvote count. Two slots voting down with small weights can be outvoted by one slot voting up with a heavy weight. The rule has no safeguard against that; the safeguard is the reader's weight choice.

Why this rule rather than a fancier one

You could imagine a blend that penalises disagreement, that weights by recent performance, that uses a median instead of an average, or that switches averaging mode based on volatility. Each of those is a legitimate design choice in some contexts. They also share a property you will not find here: their outputs cannot be reconstructed from the inputs visible in the dialog.

An arithmetic weight-normalised average with a weight-majority trend vote is the simplest rule that gives the reader something configurable, composable, and honest. It does not do any more than the reader is asking for. It also does not do any less — the rule does resolve disagreement, it does reflect user-chosen weights, and it does declare its tie-break. That combination is the design target.

User verification path for Mechanic B

The blend's rule is verifiable on your own chart in three quick moves.

1. Weight-normalised average. Set two slots to the same TimeFrame: and Length: but different Type: values. Set the third slot's Blended Weight: to 0. Watch the blended line. It should sit cleanly between the two contributing slots' values — and if you set their weights equal, the blend should sit at the midpoint of the two slot values.

2. Proportionality of weights. Keep the same two contributing slots. Change both contributing weights together — say, from 33.3 / 33.3 to 10 / 10. The blend should not move. Now change the ratio — 10 / 30 instead of 10 / 10. The blend should shift toward the slot with the higher weight.

3. Tie-break. Configure your three slots such that one is up, one is down, and the third is silent (either disabled or weight-zero). Set the remaining two weights equal. The blend's colour should be lime (tie resolves to uptrend). Nudge one slot's weight a hair higher than the other in either direction and confirm the blend flips to follow the majority.

The three moves above establish the rule is doing what this section says it is doing. They also demonstrate that the rule is the rule — nothing else is modulating the line under the hood.

What this section deliberately does not publish

• The exact accumulator structure that implements the rule.

• The variable names used internally.

• The specific comparison-site keyword that determines the tie-break.

• The order of operations within the blend function.

Again: you do not need any of those to use the blend honestly, and the implementation detail stays protected on purpose.

A closing framing on the version surface

From the mechanics' point of view, the Base → CTX → STR progression is about matching surface area to the job. Base gives you three slots, one global repaint switch, and the blend rule documented above. CTX gives you ten slots, a per-slot repaint switch, cross-ticker reads, per-slot colour inputs, and a wider MA palette. STR sits after CTX where it exists: it keeps the stronger per-slot control pattern and spends extra processing on structure around the blended output, which is why STR carries fewer slots than CTX.

What changes across versions is not the core read; it is the attention cost and the kind of information the surface is built to carry. A CTX surface makes each slot a small configuration problem. A Base surface makes the whole overlay a single, cleaner problem. Both versions are the right tool for a specific kind of reader. A reader who wants the focused read should not pay the attention cost of CTX for features they will not use; a reader who genuinely needs the context-expansion features should not try to simulate them inside the Base version.

Choose the trim on purpose. That choice is itself a trust move — you are telling the tool how much surface area you want to hold in your head at once.

Where to go next

• MTF & Repainting — the reader-facing page for Mechanic A, framed around the switch itself rather than around the mechanism.

• Visuals & Logic — the reader-facing page for Mechanic B's colour rule, framed around what the rule looks like on the chart.

• Axiom MA Lite library manual — the deeper mechanics of the MA types Base's Type: dropdown exposes.

• Axiom MA CTX — the trim where the same mechanics live on a wider surface.