For the Geeks

This page exists for the reader who has read the rest of the pack and still wants to know why three specific mechanics are shaped the way they are. It is a trust-deepener, not a reverse-engineering guide. Nothing below is required to use Axiom DC CTX correctly — the configuration pages carry that job. What is here is a mental model for the parts of the tool where a careful reader is most likely to want more than a feature description.

Three mechanics get the treatment:

• The per-slot HTF posture that On Bar Close? switches between.

• The cross-symbol scaling that makes Optional Ticker: produce channels in chart price space.

• The weighted blend and the majority-weight basis-trend vote that the blended channel runs on.

For each, the page explains the user trust problem the mechanic solves, the shape of the mechanic at a mental-model level, the main tradeoff, and a path you can use to verify the mechanic behaves the way it is described. What the page does not do is publish source code, function signatures, or cloneable sequencing around the mechanic. Those remain in the script, deliberately.

Mechanic A — The confirmed-HTF posture

The trust problem

When a lower-timeframe chart displays a higher-timeframe value, there is an unavoidable question: which version of the HTF value is being shown? Three reasonable answers exist, and they have different honesty costs:

• The current HTF value, live. Updates as the HTF bar forms. Can change until the HTF bar closes. Responsive in the live moment, but historical or reloaded bars should not be treated as proof of what was available live.

• The confirmed previous HTF value. The value from the HTF bar that has already closed. Stable between HTF closes. Lags by one HTF bar. What you see on historical bars is exactly what you would have seen in real time at those moments.

• The current HTF value without a prior-bar reference. With a naive lookahead_on call and no offset, past bars can show the closed value of an HTF bar whose close had not yet occurred when those chart bars printed. That is reading the future on historical bars — the source of the repainting problem Axiom was built in response to.

The third option is dishonest when it is used as backtest or historical proof: old bars can show a cleaner picture than you could have seen live. That is what made the original Axiom backtest produce 300% returns that did not survive live trading. The lesson, hard-earned, is that a backtest has to show what the chart would have shown at the time, not what the chart shows now.

Axiom DC CTX gives you a per-slot switch between a confirmed-history posture and a live/current posture. On Bar Close? = ON is the confirmed previous HTF posture. On Bar Close? = OFF is the live/current HTF posture, useful for the forming bar but not trustworthy as historical proof after reload.

The mechanic, in mental-model terms

When a slot requests its Donchian read at a higher timeframe, the request is made with one of two compositions:

• Under ON, the request is shaped so that on every chart bar inside the current HTF bar, the value returned is the HTF value from the previous HTF bar — the one whose close has already occurred. That value is invariant across the chart bars inside the current HTF bar. When the HTF bar closes, a new "previous" comes into play, and the slot's value steps.

• Under OFF, the request is shaped so that on every chart bar, the value returned is the current HTF value at the evaluation moment — including the live, not-yet-closed HTF bar. That value can change as new chart bars close and push the HTF high or low.

The request is shaped per slot, not globally. You can hold Slot 01 under OFF for intrabar responsiveness and Slot 03 under ON for confirmed context on the same chart. The script evaluates each slot's request under its own posture.

The main tradeoff

Versus a hypothetical tool with only the live posture, ON gives you faithful historical bars — a replay or backtest shows the same lines you would have seen live — in exchange for one HTF bar of latency.

Versus a hypothetical tool with only the confirmed posture, OFF gives you intrabar responsiveness to developing HTF action in exchange for drift between HTF closes and for historical/reloaded bars that are not a faithful live record.

This is the line to keep clean: ON can be used for historical proof; OFF can be used for the live developing read. Treating OFF history as if it carried ON's historical contract is where the lie creeps back in.

Verification path

Enable a single slot on a 5-minute timeframe on a 1-minute chart with On Bar Close? = ON. Watch a full 5-minute window. The slot's upper, lower, and basis hold constant until the 5-minute bar closes, then step.

Flip the slot to OFF. Watch another 5-minute window. The slot's lines drift as each 1-minute bar closes and moves the live 5-minute extremes around. At the 5-minute close, the lines settle to whatever the confirmed 5-minute values ended up being.

If you replay the chart or scroll back to a prior session, ON shows you exactly what you would have seen live at those prior moments. OFF is useful for watching the current HTF line drift, but old/reloaded OFF bars are not proof of what the chart knew live.

What is protected

The specific request composition — the offset applied inside the HTF expression, the tuple shape returned, the lookahead_on parameter usage, and the wrapper function that selects between current and previous values — is implementation detail. The manual describes the two postures and their consequences in plain words; the code that produces them stays in the script.

Mechanic B — Cross-symbol scaling

The trust problem

A Donchian channel on one symbol, overlaid directly on a chart of another symbol, will usually land off the chart entirely. SPY trades near 400 while QQQ trades near 340, and a 20-bar Donchian on QQQ read at 340 is simply not near the 400 axis you are reading SPY on. The raw overlay is useless as a visual.

Several responses are possible:

• Do not offer cross-symbol overlays. Clean, but denies a reader who wants to see a related market's range on the chart axis.

• Rescale with a volatility-aware transform. Align the two symbols' ranges by a volatility metric. Sounds sophisticated; in practice, introduces a lot of modeling choices, is easy to get subtly wrong, and can look authoritative while smuggling in opinions. Would require its own mental model to read, defeating the goal.

• Rescale with a single point-in-time price ratio. Multiply the alternate symbol's channel by chart_close / other_close at the slot's timeframe. Legible. Cheap. Obviously not a causal transform. The reader can understand what the scaling does in one sentence.

Axiom DC CTX chooses the third. The cross-ticker channel is a scaled sketch, not a predictive overlay. The scaling is legible by design.

The mechanic, in mental-model terms

When a slot has Optional Ticker: set to an alternate symbol:

1. The slot requests the Donchian channel — upper, lower, basis — on the alternate symbol at the slot's timeframe, under the slot's On Bar Close? posture.

2. The slot also requests the chart symbol's close at the slot's timeframe under the same posture, and the alternate symbol's close at the slot's timeframe under the same posture.

3. A scaling ratio is computed: chart_symbol_close_at_htf / alternate_symbol_close_at_htf. Under ON, these closes are the previous confirmed HTF closes. Under OFF, they are the live HTF closes.

4. The alternate symbol's upper, lower, and basis are multiplied by that ratio. The results are plotted on the chart.

The mental model: the alternate symbol's channel is being resized into the chart symbol's price space, using a single price-level ratio at the slot's timeframe. The relative shape of the channel (how wide it is relative to its midpoint, where the basis sits inside the bounds) is preserved. The absolute position on the chart is made legible by the ratio.

What the scaling does not do:

• It does not transform for volatility differences. If QQQ's 20-bar range is, proportionally, narrower than SPY's 20-bar range, the scaled QQQ channel will look narrower on the SPY chart — because it is, proportionally, narrower — and that is usually the reading you want.

• It does not align sessions. If one symbol has an overnight session the other does not, the ratio inside the non-overlapping window is computed from whatever data is available, which can be stale or asynchronous on one side.

• It does not claim causation. A QQQ-scaled channel sitting above the SPY range does not mean SPY is about to catch up. It means QQQ's range at that timeframe, fit onto SPY's price axis by the current close ratio, sits there.

The main tradeoff

Versus a volatility-aware transform: the single-ratio scaling is obviously simple, which is a feature. A reader can explain what the line means in one sentence. A volatility transform would be more ambitious, would introduce its own modeling choices, and would still not be predictive. This is the honest simple thing rather than the dishonest clever thing.

Versus no cross-symbol overlay at all: one slot of context on a related market is cheap, visible, and useful to readers who want to see where another symbol's range sits without flipping charts. The tradeoff is that a reader who over-trusts the overlay can read causation into it. The manual addresses that directly — see Limitations & Trust Boundaries for the explicit "scaled, not predictive" framing.

Verification path

On a SPY chart, enable a slot with Optional Ticker: = QQQ, TimeFrame: = the chart timeframe, and On Bar Close? = ON. Leave Blended Weight: at 0.

Toggle Optional Ticker: between empty and QQQ:

• With it empty, the slot's channel should match a native Donchian on SPY at the slot's length — same midpoint as the chart price, same width as a stock 20-bar Donchian on SPY.

• With it QQQ, the channel should land in SPY's price space (not at raw QQQ prices), with a shape reminiscent of QQQ's 20-bar range at that timeframe.

To sanity-check the ratio: pull up QQQ and SPY on separate charts, look at the closes of the last confirmed HTF bar, compute SPY_close / QQQ_close. Multiply QQQ's 20-bar high from that same confirmed context by that ratio. The result should match the upper line of your scaled slot on SPY. (Working with ON means you are using confirmed prior-bar values; doing the same sanity check under OFF uses live/current values.)

What is protected

The function signature of the scale computation, the specific lookahead_on usage inside the scale request, the guards against na and zero denominators, and the wrapping code that interacts with the slot's repaint posture are implementation detail. The manual describes the ratio in plain words and names the session and regime failure modes; the code stays in the script.

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

The trust problem

A composite channel that combines multiple slots has to declare two rules: how its band values are combined, and how its direction is decided. A reader-configurable composite especially has to declare these rules, because without them the blended channel is an opaque authority — a line with no explainable rule behind it.

Three possible directions for how such a composite could behave:

• Hide the rule. Let the blend be a "smarter" composite whose exact composition is not published. Easy to sell; impossible to reason about. Hostile to a reader who wants to know what they are looking at.

• Use an obscure rule. A threshold-based heuristic, a median, a non-linear combiner. Can look sophisticated; is usually opaque in practice because it asks the reader to trust an arithmetic they cannot reproduce.

• Use the plainest rule that does the job. A weight-normalized average for the band values, a weight-majority vote for direction, and an explicit tie-break. Easy to explain. Easy to verify.

Axiom DC CTX uses the third. The rule is declared here and in Visuals & Logic.

The mechanic, in mental-model terms

Band values. The blended upper, lower, and basis are each a weight-normalized average of the contributing slots' corresponding values. Only slots that are enabled and have a non-zero weight contribute. A slot with weight zero contributes a zero to the numerator and nothing to the denominator. A disabled slot contributes nothing on either side. Hidden plots make no difference — hiding is visual only.

For enabled slots with non-zero weights:

• blended_upper = Σ (w_i · slot_upper_i) / Σ w_i

• blended_lower = Σ (w_i · slot_lower_i) / Σ w_i

• blended_basis = Σ (w_i · slot_basis_i) / Σ w_i

Basis-trend direction. The blended channel also reports a basis-trend state (rising or falling) that drives the blended basis-trend alerts. The rule is a weight-majority vote:

• Sum the weights of enabled slots whose basis is currently rising.

• Sum the weights of enabled slots whose basis is currently falling.

• If the rising sum is greater than the falling sum, the blended basis-trend is rising.

• If the falling sum is greater, the blended basis-trend is falling.

• If the two sums are equal, the blended basis-trend is rising. Ties resolve to uptrend by convention.

The tie-break is deterministic so the blended basis-trend state is always defined. It is not a market claim. It is a convention the script had to choose, and the manual names it in plain words so you are not reading an alert whose rule you do not know.

The main tradeoff

Versus a more elaborate composite: simpler, more legible, and easier to verify. Versus no composite at all: one line that carries the weighted composite of a stack you defined, with rules you can read off this page.

A reader who finds the weight-majority vote too blunt is not wrong — the vote treats a 51/49 weighted majority the same as a 99/1 weighted majority. That is a real limitation of a vote-based rule. The response is either to accept the bluntness as the price of a composite that can be reasoned about, or to read the individual slot trends and draw your own conclusion instead of the blended alert.

Verification path

Enable two slots at equal weights with different TimeFrame: values. Observe the blended basis line. Compute the arithmetic mean of the two slot basis values by hand — the blended basis should equal it exactly.

Change one slot's weight to double the other's. Observe the blended basis moving proportionally toward the heavier slot. Compute (2·b_heavy + 1·b_light) / 3 by hand and check against the chart.

For the tie-break: configure two equally-weighted slots with opposite basis-trend states (one rising, one falling). Attach a Blended DC Basis Is Uptrend alert and a Blended DC Basis Is Downtrend alert. Under the tie, only the uptrend alert will be live in the current state.

What is protected

The accumulator loop that walks the enabled slots and sums weight-value products, the array layout used inside the blend function, the nz(...) handling for early bars where slot values are not yet populated, and the code structure that implements the tie-break are implementation detail. The manual states the rule — weight-normalized averages, weight-majority vote, tie-to-uptrend — in plain words. The code stays in the script.

Protected details, stated once

For the sake of keeping the boundary explicit: this page does not publish the request.security wrapper pattern that implements Mechanic A, the scale-ratio function signature that implements Mechanic B, or the accumulator loop that implements Mechanic C. It also does not publish any formulas, thresholds, or pseudocode. The goal of this page is to deepen your trust in the three mechanics by describing what they do and why, in terms you can hold in your head and verify on a chart, without making the script reproducible. That line is drawn deliberately.

If you find yourself wanting more detail than this page provides, the right move is not to reverse-engineer — it is to run the verification drills above, extensively, until the mechanics feel familiar enough that further disclosure would not change your judgment.

What you should walk away from this page with is three things: a working sentence for each mechanic that you can say out loud, a verification drill per mechanic that you have run at least once on your own chart, and a named understanding of what each mechanic deliberately refuses to be (not forward-looking for Mechanic A, not predictive for Mechanic B, not opaque for Mechanic C). If any of those three is missing, the page has not yet done its job for you. Re-read the relevant section and run the drill again.