For the Geeks

This page explains the shape of the pipeline — enough for a reader to reason about why the pane does what it does, and enough to distinguish it honestly from plain single-timeframe stoch, classical slow stoch, and a stoch-RSI-style rescaling.

It does not publish formulas. It does not publish pseudocode. It does not publish library internals, default parameters beyond what the input panel already exposes, or the exact variable-level wiring of any stage. That boundary is deliberate and the last section explains why it lives where it lives. If you are here looking for a recipe to reproduce the tool, this page will not hand one to you. If you are here to understand it well enough to trust it, this is the page that does that.

The shape, in ordered stages

Reading the pipeline left to right, per slot and then across slots:

Stage 1 — Raw %K in the slot's timeframe context

For each enabled slot, the instrument computes the classical stochastic transform inside that slot's timeframe context. The transform takes three inputs over the slot's K Length lookback: a close term (the slot's Source:), a high term, and a low term. The high and low come from the slot's request.security resolution — a 5m slot sees 5m highs and lows, a 60m slot sees 60m highs and lows — independently of Source:. Only the close term is user-swappable.

The result of Stage 1 is raw %K: a bounded 0..100 series reporting where the slot's close-term series sits inside the high/low range over the lookback.

Tradeoff worth naming. The decision to compute the stochastic transform inside each slot's native timeframe context (rather than on the chart's timeframe and then resampling) is what makes a slot's reading actually representative of its timeframe. A 60m slot on a 1m chart is reading 60m highs and 60m lows, not 1m highs and lows averaged over 60 minutes. That fidelity is the reason the MTF blend has something coherent to blend in Stage 3.

Stage 2 — Two smoothing passes per slot, with clamps

Raw %K passes through a first MA — the slot's K Type: family at the slot's K Smoothing: length — to produce the slot's K line. The K line passes through a second MA — D Type: family, D Length: length — to produce the slot's D line. Each output is defensively clamped into 0..100.

During warm-up, each MA produces na until it has enough bars. The indicator falls back to the previous stage's value in that case — raw %K acts as the K line while K's smoothing is na; K acts as the D line while D's smoothing is na — so the slot stays visible during warm-up. That fallback is warm-up behavior only and snaps back to the real pipeline once both MAs have filled.

Tradeoff worth naming. The two passes compound. A short K smoothing plus a long D smoothing gives you a K line that can move around its own D more readily than a slower K pass would. Both are valid. Neither is correct in the abstract. The family choice is the tuning surface in this tier — Base imports the Lite MA library, which currently routes SMA, EMA, RMA, WMA, VWMA, and SWMA. The wider Pro-family set and its inside-family knobs are not part of this Base source.

Clamp note. The clamps are a final bound, not the reason the pane is bounded. Stochastic is bounded 0..100 by construction, and the current Lite MA families are averaging methods that should normally inherit that bound. The clamp's job is defensive: even if a future library change or numerical edge case tries to draw outside the pane, the displayed output stays inside 0..100.

Stage 3 — Weighted blend across slots

For each bar, the blend layer collects the K values from enabled slots that have non-na K and non-zero weight. It forms a weighted average — each contributing slot's K times its weight, summed, divided by the total contributing weight. The same operation runs in parallel for the D values. Both blended series are defensively clamped into 0..100.

A few properties that follow from this shape:

• The weights do not have to sum to 100. The blend normalizes.

• A slot with weight 0 is excluded from the blend.

• A slot whose K is currently na (still warming up) is excluded from the blend for that bar.

• If no slot is contributing on a bar, the blend is na on that bar. The blend plots nothing on that bar and neither blend alert can fire.

Tradeoff worth naming. Averaging bounded stoch values across different timeframes is a coherent operation because stoch is unit-less and bounded by construction. There is no price-scale term to reconcile — a 5m stoch and a 60m stoch both sit in 0..100 with the same meaning. That is why the blend can be built honestly. It is also why the blend is easy to mishandle when the slot configurations are near-duplicates of each other — near-duplicate slots produce near-duplicate evidence, and averaging near-duplicate evidence is one measurement in three costumes.

Stage 4 — Optional master smoothing

If Enable Master Smoothing is on, one more MA pass runs on the blend before display. The output is re-clamped into 0..100. The per-slot K and D lines are untouched. The per-slot alerts are untouched.

What changes: the blended K and blended D visuals become calmer. The two blend-based alerts (Blended Stoch Is Bullish, Blended Stoch Is Bearish) fire later than they would on the unsmoothed blend, because they now evaluate a lagged series.

Tradeoff worth naming. The master pass is a lag-add in exchange for visual calm. It is not a correction, a noise remover in any meaningful sense, or a confidence amplifier. If the blend looks choppy, master smoothing hides the chop at the cost of adding lag to the blend alerts — and the choppiness usually has its source on one of the slot configurations, where it can be addressed directly.

A note about what the master pass consumes: in the current source, master smoothing runs on the raw weighted blend values, then the smoothed result is clamped back into 0..100. The user-visible consequence is still the one that matters most: when enabled, the master pass produces a smoother, later version of the blend, and the blend-based alerts evaluate on that smoothed version.

Stage 5 — Display layer

At the display layer, the pane draws three slot K lines, a blended K, a blended D, and a tinted fill between the blended pair. Colors are determined by K-vs-D relationships — per-slot for the slot lines, per-blend for the blended pair. The reference lines at 0, 100, 50, and the user-configurable 80 and 20 are drawn but drive no logic. Two hidden plots (display.none) expose bullish and bearish slot counts for alert message templates.

Alerts are declared as state conditions — K above D or K below D — gated by barstate.isconfirmed on the chart bar. The gating is on the chart bar, not the slot's higher-timeframe bar. Transition alerts, threshold alerts on the reference lines, divergence alerts, alignment-transition alerts, and saturation alerts are all absent by design.

Stage 6 — The bar-close gate

The global On Bar Close? switch determines which bar's slot values are returned by the slot's request.security call. On true, the slot returns the previous higher-timeframe bar's clamped values — confirmed, stable across chart bars inside the higher-timeframe bar. On false, the slot returns the live higher-timeframe bar's clamped values — revising until the higher-timeframe bar closes.

The request.security call uses lookahead = barmerge.lookahead_on. The [1] previous-bar selection on ON is what makes the read non-repainting; the lookahead mode cooperates with that selection. On Base this is a single global choice. Per-slot control of the gate is a CTX feature.

Comparison table — what this pane is and is not

Two distinctions worth calling out explicitly because they are easy to miss.

This pane is not a stoch-RSI. The stoch-RSI applies a stochastic transform to an RSI series. This pane applies a stochastic transform to price (or the user's Source:). Different inner values, different pipelines. The 0..100 range you see at the top of both looks similar, and the similarity stops there.

This pane is not a plain single-timeframe stoch. It is a classical slow-stoch K/D cascade per slot, stacked across three timeframes, with a weighted blend on top. The slow-stoch shape is familiar. The stacking and blending is the new work.

Reader-side verification protocol

Four checks you can run on your own chart to verify the pipeline is doing what this page says it does. None of them requires internal access.

1. Lengthen a single slot's K smoothing. Load defaults. Set slot 01's K Smoothing: to 10 (SMA 10). Expected: slot 01's K line visibly calms without affecting slots 02 or 03, and without affecting blend lines except insofar as the slot is contributing to the blend. If slot 01 calms but slots 02 and 03 are also affected, something is not isolated per-slot — that would be a bug. It is not one.

2. Zero a slot's weight. Load defaults. Set slot 02's Blended Weight: to 0. Expected: slot 02 still plots. Slot 02's per-slot alerts still fire. Slot 02 still counts in the alignment tally. The blend shifts to reflect only slots 01 and 03. If slot 02 stops plotting or stops alerting, something is wired wrong — it is not.

3. Toggle the bar-close switch. Load defaults on a 1m chart. With On Bar Close? = true, slot 03 holds flat across chart bars inside a 60m bar. Switch to false, and slot 03 drifts inside the next open 60m bar. At the 60m close, slot 03's value in the false run matches the true run's next value. If it does not, something is off.

4. Enable master smoothing. Load defaults on a trending session. Enable master smoothing with a visible length (EMA 5 is plenty). Expected: the blend's flip timing shifts later compared to the unsmoothed run, and the per-slot lines are untouched. If the per-slot lines move, that is not what master smoothing is supposed to do — it is not what it does.

Each check is falsifiable. If you run one and the behavior does not match the description, the issue is configuration on your side, or a genuine bug worth reporting. Rare but worth the word.

Why the boundary lives where it lives

This page names the shape of the pipeline. It does not publish:

• Formulas for the stochastic transform or for any MA family.

• Pseudocode or code shapes that would let a third party rebuild the pipeline end to end.

• Numeric constants for the clamps beyond the reader-visible 0 and 100 rails.

• Library-internal parameter defaults or family-specific internals beyond what the input panel already exposes.

• Internal helper names and call ordering that are not needed to reason about the pane from the chart.

• Any ordering of internal helper calls not already surfaced by the public input panel.

This is not secrecy for its own sake. The reasoning is simple. A reader who needs to trust the pane needs the pipeline's shape — its ordered stages, its tradeoffs, and its boundary cases. A reader who needs to rebuild the pane needs its exact wiring. Those are different audiences with different needs, and this page is written for the first one. The shape of the pipeline is what lets you reason about its behavior; the exact wiring is an engineering artifact. Making that artifact public would primarily benefit a third party trying to replicate the tool without doing the engineering work behind it, and it would not meaningfully improve a reader's ability to use the pane well.

There is a second reason, quieter but real: any line of explanation that claims to describe exactly how the code works risks becoming a liability the first time the code changes. A description of the pipeline's shape — "two smoothing passes per slot, weighted blend across slots, optional master pass, defensive clamps at each stage, bar-close gate" — is stable across implementation details. A description of exact internal wiring would have to be re-written every time the implementation was tuned, and any reader relying on the outdated version would be working from a map that no longer matched the territory. The boundary here protects you from that drift as much as it protects anything else.

The promise this page makes to you is: enough explanation to trust the pane's behavior, framed in mental-model language, with a verification protocol you can run yourself. What the page will not do is hand over a recipe.

If something on this page does not line up with your own observation of the pane, write up the discrepancy and pass it along. Verifications that surface real behavior — and real bugs — are the kind of feedback the pack is built to take seriously, and they are more useful to us than a hundred messages saying the documentation looked fine.

Cross-references

• Input-level material for every stage: Settings.

• The bar-close switch as its own teaching surface: MTF and Repainting.

• The misread-prevention surface that depends on understanding the pipeline shape: Limitations and Trust Boundaries.