Limitations and Trust Boundaries

This is the honest-limits page. It is ordered by damage potential. If you only read the first two sections, you will leave with the two costliest misreads this trim produces on the page named. Every section below is a real way the tool can be misused by a capable reader without the tool malfunctioning, and every section is here because the reader-facing consequence is material, not because the page needs padding.

The posture of this page: the tool is configurable, the tool is legible, and the tool is honest about what it reports. None of those properties make it self-correcting. A reader using it without knowing the traps below can run a clean configuration that is quietly producing the wrong read. Those are the cases this page exists to prevent.

1. Alignment mistaken for breadth — the costliest misread on this trim

Three enabled slots on three timeframes of the same chart instrument can all lean the same way, and the alignment alerts will say so. The temptation is to read that agreement as breadth — three independent observations converging on the same conclusion. It is not.

Three timeframes of a single symbol share evidence. A move on the fast slot cascades into the slower slots by construction; the same underlying price path is what every slot is reading, just at different cadences. Alignment is a "cadences agreeing" read, not a "witnesses agreeing" read. On a trending instrument, alignment holds for extended runs and the alignment alerts re-fire on every confirmed chart bar. On a choppy instrument, alignment fires rarely. In both cases the alignment is reading cadence coverage, not independent agreement.

In Base, with three slots each carrying one-third of the alignment tally, the cost of a mis-specified slot is larger per slot than it would be on a ten-slot trim. One identical slot among three means a third of your "agreement" is a duplicate; on a ten-slot trim the same identical slot is a tenth. The math is unforgiving in this direction. If you run three slots with the same source, the same RSI length, the same MA family, and the same smoothing pair — differing only by timeframe — you have built a one-measurement-at-three-cadences configuration, and alignment on that configuration is almost always a trend-persistence detector wearing a consensus label.

Differentiation reduces this but does not eliminate it. A fast/anchor/patient differentiated stack (see Workflows) is a more informative configuration, and alignment on it is a stronger claim than alignment on an identical-settings stack. It is still not three independent observations. The math does not produce independence from a single-symbol source.

The usable framing: treat alignment as a reason to look, not as a reason to commit. Alignment surfaces a cadence-level concurrence; the reason you look is to examine whether the chart, the structure, and your own context agree with what the pane is showing.

A quick mental test for when alignment is misleading you. Before you read into an alignment alert, ask: what would have to be true on the chart for this alignment not to hold right now? If the honest answer is "a sharp reversal on the fastest timeframe within the last few bars," you are reading a trend-persistence condition, not a breadth condition. If the honest answer is "genuinely different behavior on each of the three timeframes," and your slots are actually differentiated enough for that to be visible, alignment is doing some work. Running the question before you commit is cheap. Skipping it is how the costliest read on this trim takes root.

2. Textbook-RSI habit transferred without adjustment

Every reader on this trim arrives with RSI habits. Most of those habits are useful. One of them — the reflexive 70-as-sell / 30-as-buy read — transfers onto this pane in a way that misreads what the pane is showing.

On a textbook RSI, the 70 and 30 levels are reading conventions drawn from the raw RSI. On this pane, the slot line you see is the raw RSI smoothed by one MA pass, and the signal line is that smoothed RSI smoothed a second time. The 70 value on a slot line is not the same economic event as the 70 value on a raw RSI; it is the event filtered through the smoothing choices you set. The reference zones are still at 30 and 70 because those reading conventions are still useful as context, but the tool does not fire on them and the smoothing between the raw RSI and the plotted line changes the meaning of reaching them.

More importantly, the slot color comes from the RSI-vs-signal comparison, not from the RSI-vs-midline comparison. A habit that reads slot color as "above 50 = bullish, below 50 = bearish" is ignoring the comparison the tool uses and substituting a comparison the tool does not run in the color. The Visuals and Logic page is dedicated to installing the correction; this page names the transfer trap explicitly so a reader who skips that page still has it in hand.

The usable framing: you already use RSI. Base does not re-teach it. The single correction is that color comes from RSI vs signal; 30 and 70 are reference zones; the midline is a zone boundary, not the color trigger. With that correction in place, your RSI experience transfers cleanly.

3. Color neglected, value read alone

A close cousin of the habit-transfer trap. A reader who scans only the value of the slot line and ignores whether it is full-tone or faded is reading half the information the pane provides. The slot color carries the directional read; the value carries intensity. Using only one of the two throws away the directional frame the second smoothing pass is there to give.

Symptom of this trap: you find yourself surprised by the blend moving in a direction the slot values do not seem to support. The slot values might be stable in one value band while the slot colors have been flipping back and forth. The blend is averaging the slot RSIs; the slot colors are tracking the RSI-vs-signal comparison on each slot. Those two surfaces can move at different rates, and a color-only read or a value-only read misses one of them.

Correction: read the color first, then the value. Practice until the order is automatic.

4. Weight-zero slot treated as disabled

A slot with its blend weight set to zero is excluded from the blend. It is not excluded from anything else. It still computes, still plots (unless Hide Plot is on), still feeds its own per-slot alerts, and still counts toward the alignment tally.

The specific misread: a reader wants to run a two-voter blend, zeros the third slot's weight, and assumes the slot is out of the picture. Then the alignment alerts fire in a way the reader cannot explain from the visible two voters, or the per-slot alert on the zero-weight slot starts arriving and the reader cannot find where it came from. Both symptoms are the slot being enabled, operating, and announcing itself from a weight-zero configuration.

Correction: Enable is the power switch; weight is the blend-share knob. If you want a slot fully out of every downstream surface — no blend contribution, no per-slot alerts, no alignment counting — Enable the slot off. If you want a slot visible and alerting but not pulling the blend, weight zero is the right configuration and the consequences (alignment counting, per-slot alerts) are the price of that setup.

5. Hide Plot treated as disabled

The symmetric trap to weight-zero. Hide Plot hides the slot's line on the pane. It does not stop the slot from computing, from contributing to the blend at its current weight, or from firing per-slot alerts.

The specific misread: a reader hides a slot's plot for visual cleanliness, forgets the slot is still running, and later tries to explain blend motion using only the two visible slots. The hidden slot is pulling the blend at its weight, and the blend's motion reflects three slots even though the reader is looking at two.

Correction: Hide Plot is a visibility-only control. If you want the slot fully deactivated, use Enable. If you want it quiet on the pane but contributing to the blend and alerting, Hide Plot is correct, and you need to remember it is there.

6. Master smoothing read as a correctness upgrade

Master smoothing runs an additional MA pass on the blended pair before plotting. The visual effect is a calmer blend. The functional effect is lag — the blend's color transitions happen later, the blend-based alerts fire later on state changes, and long master lengths on top of long per-slot signal smoothing can flatten the blended pair right through a regime shift that the raw slots still show clearly.

Master smoothing is not a remedy for noisy slot evidence. A noisy blend is an average of noisy slot RSIs; the noise lives on the slots. Smoothing the average hides the noise without changing what the slots are doing. If the slots are jumping because the instrument is active, master smoothing gives you a calmer-looking composite that is less responsive to the instrument you are actually trading.

The most common version of this trap: a reader enables master smoothing because the blend looks choppy, then treats a newly firing blend-based alert as "late confirmation" of an earlier move. The alert is not late or early in any meaningful sense; it is reading a slower series and firing when that slower series crosses. The reader is acting on a smoothed surface while reasoning about the unsmoothed one.

Correction: leave master smoothing off by default. Enable it only when you specifically want a calmer visual composite and have explicitly decided not to act on blend-based alerts until the slower surface confirms. Keep the slot lines visible in that configuration so the unsmoothed evidence remains on the pane.

7. On Bar Close? = false run as "real-time improvement"

On Bar Close? = false returns the live higher-timeframe bar's values. A slot on a 60m timeframe will revise within the live 60m bar as the bar develops. The reading is earlier than the confirmed reading, at the cost of revising until the higher-timeframe bar closes. On historical bars, that same OFF mode is repaint-exposed because the completed higher-timeframe bar is already known, so do not use OFF-mode history as proof of live behavior.

The trap: treating the live reading as a faster, better version of the confirmed reading. It is not better; it is different. The revision means a slot's state can flip within a live higher-timeframe bar and flip back before the bar closes. An alert firing on a live-mode chart bar reports the slot's state at the chart-bar close, and that state was derived from a higher-timeframe bar that may still revise. That is the price of earlier reads.

Correction: keep On Bar Close? = true as your default. Switch to false only when you specifically want the earlier read and are willing to accept revision. MTF and Repainting walks the verification exercise that makes the tradeoff tangible.

8. Warm-up read as steady-state

During warm-up — the first bars after a fresh load or on a thin-history symbol — the raw RSI needs its lookback's worth of higher-timeframe bars, and the smoothing passes need their own history after that. Until raw RSI exists, a slot can be blank. Once raw RSI exists, the code falls back from unavailable MA outputs to earlier pipeline values, so the plotted slot can appear before the full smoothing cascade is mature. In the normal fallback path, the signal can temporarily equal the RSI value rather than giving you a mature RSI-vs-signal relationship.

The trap: loading the tool on a chart with thin history and taking the first few bars as "the indicator's read." You are reading fallback behavior.

Correction: give the slots enough history. On a 1m chart with the default 5/15/60 timeframes, the 60m slot needs the RSI lookback plus smoothing history in 60m bars. If your chart does not have that history on the symbol — for example, a newly listed symbol, or a symbol you have set to a session that doesn't provide enough 60m bars — that is a diagnostic about the chart's data, not the tool.

9. Same-timeframe collapse

The slot-timeframe rule does not force lower slot timeframes upward. If a slot timeframe is below the chart timeframe, the script raises a runtime error. Same-timeframe collapse happens when slots are intentionally set equal to the chart timeframe, or left blank so they inherit it. In that configuration, the slots still compute, but the cross-timeframe evidence the pane was built to surface disappears for those slots.

The most common version: a reader tries to recover from a timeframe error by clearing slot timeframes or setting several slots equal to the chart. The pane can start looking like one local RSI pipeline repeated in multiple colors, and the blend stops giving the multi-timeframe context the reader expected.

Correction: watch the chart's timeframe relative to the slot timeframes. If the pane suddenly looks uniform, check the chart's timeframe before you assume the tool is broken.

10. Blend-quiet-while-slots-disagree misread

A blend sitting near 50 while the slots are pulling apart is a weighted-average artifact, not a signal that the pane is saying nothing. The blend is averaging; the slots are where the disagreement is.

The trap: reading a quiet blend as "nothing happening," disengaging from the slot scan, and missing the underlying conflict the pane was surfacing.

Correction: when the blend is quiet, the slots are the page you turn to. The blend is never a shortcut past reading the slots.

A note on what "trust boundary" actually means here

None of the items above describe a bug. The tool is working the way it was written. Every trap in this list is a reading mistake a capable trader can make on a correctly-running indicator — which is exactly why they are worth naming. A bug is the tool's problem to fix. A misread is yours to prevent. This page is a list of preventable misreads, ordered by the size of the regret they produce when they are not prevented. If you read one item and think "that would never be me," the honest next move is to write the item on a sticky note and re-read it in three months. The ones that feel furthest from you are often the ones waiting for a tired session.

Where to go next

• The reading order that prevents most of the above from taking root — Visuals and Logic.

• The scenarios and their anti-pattern contrasts — Workflows.

• The alignment alert caveat planted alongside the alerts themselves — Alerts.

• Diagnosing a specific symptom — Troubleshooting.