For years, my work with indicators had one clear intention: simplify the lives of discretionary traders. I wanted to build tools that removed noise, organized market structure, and gave people a clearer way to navigate volatility. Nothing more, nothing less.
But the deeper I went into the work — improving the logic, tightening the architecture, eliminating inconsistencies — something unexpected happened. Without realizing it, I began thinking like a quant. I started writing Pine Script the way a systematic trader approaches model design: enforcing causality, removing lookahead, worrying about determinism, stabilizing high-timeframe behavior, and ensuring that live signals and historical behavior aligned.
At some point, I looked at what I had built and realized:
I had wandered into the world of quantitative trading without ever intending to.
And then came the second realization, just as important as the first:
I don’t want to be a quant.
Not now. Maybe not ever.
1. It All Started With a Simple Goal: Build Better Tools for Humans
My first indicators had one purpose: give traders clarity.
- Mark structure cleanly
- Show shifts early
- Highlight impulses
- Establish bias
- Define sessions
- Provide reasonable SL/TP logic
In short: reduce cognitive load for people who sit in front of a chart.
But improving clarity often requires pushing deeper into the logic. You try to make structure detection more accurate. You eliminate ambiguous signals. You stabilize higher-timeframe context. You refine every conditional and edge case.
Bit by bit, my tools evolved from “clean visual helpers” into something much more technically demanding — and I didn’t notice the shift at first.
Every improvement pulled me closer to questions that belong to an entirely different discipline:
- Does this repaint?
- Does it calculate on closed bars only?
- Does this hold deterministically over time?
- Does this use forward-looking information?
- Would this be stable in execution if run automatically?
- Can this logic produce consistent backtests?
Those are not the questions of someone building discretionary indicators.
Those are the questions of someone unconsciously constructing quant infrastructure.
2. The Turning Point: Understanding Repainting the Way Quants Do
Eventually, I found myself studying repainting the way a quantitative modeler studies non-causal signals.
TradingView’s official documentation defines repainting as any recalculation where historical output changes because the script used:
- partial higher-timeframe data,
- intrabar estimates,
- forward-looking references,
- or any value that was not final at the time of decision.
According to their documentation:
“A script must calculate on the final state of a bar to be considered non-repainting. If it updates using intrabar data, its output may change once the bar closes.”
This line alone can change how you think about indicators.
Because once you truly understand it, you begin to see two fundamentally different worlds:
A) Indicators intended for humans
They work live.
They show evolving structure.
They react as the candle forms.
They are allowed to adapt intrabar.
B) Indicators intended for machines
They must never repaint.
They must use only closed data.
Their output must be deterministic.
Backtest = live execution, without discrepancy.
As I deepened the Framework, I unconsciously drifted toward the second category. My architecture started resembling the type of logic quants use to feed execution engines — not the tools discretionary traders use to interpret the market.
I was building systems for machines…
even though my goal had always been to build tools for humans.
3. The Moment of Clarity: Quant Trading Is Not the Life I Want
Eventually, I had to confront an uncomfortable reality:
If I continued down that path, I would end up maintaining a quant system — something that requires:
- servers
- monitoring
- historical pipelines
- execution logic
- risk engines
- slippage models
- liquidity constraints
- failover mechanisms
- statistical recalibration
- and systematic periodic optimization
That is a different world entirely.
And the truth is simple:
It is not the world I want to work in.
Being a quant is not just a trading style — it’s an entire career. It’s a commitment to data infrastructure, mathematical modeling, and constant systems engineering. It’s debugging execution environments at 3 AM because something broke on an AWS node.
I admire the discipline, but it’s not my path.
My interest is in helping traders — real people — understand the market better, trade more consistently, and reduce the emotional chaos that destroys results.
I do not want to build a server farm.
I do not want to oversee an algo pipeline.
I do not want to engineer a trading machine.
I want to build tools for traders, not tools for machines.
Recognizing this helped me redefine the Framework and set the direction for its future.
4. Why the Framework Now Exists in Two Versions
This reflection led to an architectural decision that shaped all future versions:
Version A — Live Trading (Public)
- Built for discretionary use
- Shows structure as it forms
- Uses partial information when needed
- Responds to intrabar changes
- Helps humans interpret markets
- Naturally includes repainting because it updates live
- Not suitable for historical backtesting
Version B — Automation/Backtesting (Private)
- Built for deterministic execution
- Uses closed-bar logic only
- Removes all repainting
- Designed for webhooks and systematic strategies
- Suitable for statistically valid backtests
- Not published publicly because it serves a very different audience
The public version is the one traders should use to make decisions.
The private version exists only for automation and research.
They solve different problems.
Neither can replace the other.
This distinction is essential, and it laid the foundation for the next major change in the Framework: removing the old backtesting panel entirely and replacing it with a new, honest, clearly defined analyzer.
5. Why We Removed the Old “Backtesting Panel”
Earlier versions included something called a “backtesting panel,” a table that attempted to summarize how the system “performed.” At the time, it seemed like a convenient way to give traders more insight.
But there was a fundamental problem:
Backtesting is not possible on a repainting, intrabar-reactive indicator.
The panel unintentionally suggested a level of historical accuracy that simply cannot exist on a tool that updates live.
According to TradingView’s repainting documentation, anything that uses:
- intrabar logic,
- partial higher-timeframe data,
- dynamically updating structure,
will display historical output that does not match what a machine would have seen live.
This means:
- You cannot derive valid win rates.
- You cannot compute true expectancy.
- You cannot reconstruct a strategy.
- You cannot treat results as causal or repeatable.
The old panel had to go.
Not because it was useless — but because it created a false expectation: the illusion of backtest certainty on a tool never designed for that purpose.
So we removed it.
And in its place, we built something far more honest.
6. The New Settings Performance Panel — What It Is and What It Is Not
The new panel, included in the latest Framework code, is explicitly labeled “Settings Performance Panel”.
This single line captures its purpose with total clarity.
It is not a backtest.
It is not meant to produce a statistically valid track record.
It is a configuration analyzer.
A structured way to evaluate how your settings behave between two dates.
The analyzer:
- spawns trades from the same boxes that appear live,
- uses your exact SL/TP configuration,
- enforces optional “one trade at a time” behavior,
- tracks resolved trades,
- records which TP or SL was hit first,
- computes net R, expectancy in R, and median time in trade,
- labels sample quality (Low / Mid / Strong),
- and shows a Wilson 95% confidence interval for win rate.
This gives you a realistic sense of:
- How aggressive your settings are
- How often trades tend to hit SL or TP
- How long trades usually last
- How many trades per week occur for the configuration
- Whether the SL/TP architecture aligns with the asset and timeframe
But it never pretends to be more than that.
It does not reconstruct intrabar states.
It does not claim to be a historical performance engine.
It does not simulate order-level execution.
It does not guarantee causality.
It does not suggest future results.
It is a diagnostic tool — nothing more.
This is the philosophical shift:
The Framework does not backtest discretionary tools.
The Framework analyzes settings, not strategies.
And that distinction is the foundation for honest engineering.
7. Why This Panel Fits the Framework’s Philosophy
Once I understood my real focus — building tools for traders, not machines — the design choices became obvious.
The Settings Performance Panel exists because:
- Discretionary traders need feedback on configuration.
- They do not need a pretend quant backtest.
- They do not require a causal strategy engine.
- They simply want to know whether their settings make sense.
The panel answers practical questions:
- “How does this SL/TP configuration behave on this asset?”
- “Am I trading too frequently or too rarely?”
- “Do trades resolve in minutes or days?”
- “Is TP1 too conservative or too far?”
- “Is my risk structure realistic for this timeframe?”
In that sense, the analyzer is a microscope, not a time machine.
It shows you how your configuration interacts with real market structure — the same structure you see live — without pretending to be a backtest.
This aligns perfectly with the purpose of the public Framework:
Help human traders make clearer decisions with tools designed for human intuition.
Not for server racks.
Not for execution engines.
Not for automated pipelines.
8. How This Reflection Shaped the Latest Framework Upgrades
This journey — drifting into quant territory and choosing to step back — shaped the newest version of the Framework directly.
Instead of doubling down on causality constraints and automation infrastructure, I shifted my attention back to clarity.
The latest upgrade includes:
- More stable high-timeframe bias
- Cleaner impulse detection
- More consistent CHoCH/BOS logic
- Sharper session boundaries
- Improved SL/TP derivation
- A more structured real-time BOS engine
- And the new Settings Performance Panel replacing the old backtest table
All these changes reinforce one mission:
Make discretionary trading clearer without pretending to automate it.
That’s the identity of the Framework now — and the identity it will continue to evolve under.
9. My Conclusion: This Was Never About Becoming a Quant
Falling into quant thinking taught me something important:
- how deterministic systems work,
- why repainting matters in automation but not in discretionary trading,
- why intrabar updates are essential for real-time interpretation,
- why automation demands a different architecture entirely,
- and why the two worlds cannot be merged within a single indicator.
But the most important lesson was personal:
Quant trading is not the life I want.
I like building tools for traders — tools that make reading the market easier, not tools that replace the trader. I like focusing on structure, clarity, psychology, execution, and decision-making — not debugging servers, optimizing fill engines, or architecting event-driven pipelines.
By choosing to stay in the discretionary world, I can keep building something meaningful:
A Framework that gives traders the clarity they need,
without pretending to be something it’s not.
That is the mission of Black Tie Report.
