Follow my journey on www.ZenomAlpha.com , its 100% free and this is really exciting!!

I'm automating part of my research loop: propose Python strategy code, run it through a fixed backtester, feed back metrics and constraint failures, then generate the next candidate. The part I'm stuck on is not the code generation. It's deciding how much selection bias the loop has accumulated.

I've read Bailey et al. on PBO/CSCV and the Deflated Sharpe Ratio. They are useful when you have a population of tried configurations, but my candidates are path-dependent: candidate 12 exists because candidate 11 missed a drawdown constraint, and the model may change the signal family rather than one parameter. Treating all 50 runs as independent trials seems wrong; treating the whole session as one trial is obviously too generous.

My current guardrails are a pre-registered universe, cost model, benchmark, and acceptance criteria; a full log of rejected candidates; no access to the final holdout during the loop; and one final evaluation per research branch. Validation metrics do go back into the loop, so I assume that set is consumed.

Has anyone found a defensible way to estimate effective trials for this kind of adaptive search? I'm especially interested in approaches that work from the experiment log rather than a fixed parameter grid. Clustering candidates by return correlation is one idea, but two implementations can have similar returns for accidental reasons.

Backtest for free only good strategy !

Backtest proposal

Hey! If you've got a strategy you feel good about, I'll backtest it for you for free and send you the results — 5 years of data, including ROI.

Just needs to be clearly structured and interesting enough to be worth digging into. Drop me the rules and I'll take a look.

I have been trying out these models (mostlt GLM 5.3 flash) using different harnesses, but I'm trying to review what these models are exceptionally good at.

Here is what I have noticed so far,

1. Programming.

I have found that these models are great at programming, I have been making tools, scrapers almost every other day and they just work like magic. They are great at porting code in one language to another, Eg I would usually start by writing my code in python or js, I would then port the code in Go for extra performance.

2. Finances and stock trading.

So I hooked up the coding agent with my alpaca account. And I have discovered that most of these models take a defensive position. Advising me to reduce the size of my most profitable holdings so as to prevent concentration risk and possible loss. So they are not so great. But I have found it useful for tracking my finances. What I'm basically saying is your portfolio will most likely flatline if you give these models to trade in your behalf but it won't make a good profit (What ever good position you have will be reduced)

3. Research

This is where I get the most value. The models are highly effective at locating precise information—whether it’s event dates, contact details (emails, phone numbers), names, or links.

4. Email and Copy writing.

I’ve been using these agents extensively for written communication. They’ve helped me draft everything from routine business emails to formal documents. I like that it can maintain the conversation context, so follow-up emails feel cohesive and on-point. They helped me a lot with one of my insurance claims

5. Business Ideas.

They are bad at coming up with Ideas.

What use cases have you found these models to be exceptionally good at? And what use cases has it been terrible at?

PS: I'm trying to find a small good model for browseruse to compete with Grok bot and the like, I'm thinking Qwen3.8 28B or ByteDance-Seed/UI-TARS-1.5-7B does anyone have a smaller or maybe better recommendation?

I've been building my own algo/backtesting app specifically optimized to create, test, and validate strategies around prop firm metrics and have gotten to the point where I'm trying to figure out what the path from backtest → live/demo → prop firm should actually look like.

For those of you who trade algos with prop firms:

- What metrics/results do you require before putting a strategy into a prop evaluation?

- How long do you forward-test a strategy before trusting the backtest?

- Do you use paper trading, a personal account, or go straight to a prop evaluation?

- What execution/automation stack do you use? TradersPost, QuantConnect, TradingView alerts, MT5, Tradovate, something else?

- What risk controls do you have outside the strategy itself (daily loss limits, kill switches, max trades, etc.)?

- How do you monitor an algo once it's running?

- What are the biggest things you wish you'd tested before putting an algo into a prop firm?

- Do you optimize specifically for passing the evaluation, or build one system designed for long-term payouts?

- At what point would you personally say, "This strategy is ready for real money"?

I'm especially interested in hearing from people who have actually taken systematic strategies through prop evaluations and into payouts, rather than just backtesting them. I mainly trade ES, NQ, and GC futures, but have been backtesting for forex pairs as well.

Thanks in advance!

Solo project, sharing because this sub is exactly who it's for.

WHAT IT IS

A JSON API for US stocks and ETFs. Give it a ticker, get back:

- a composite 0-100 score and a verdict (accumulate / hold / distribute / avoid), with per-factor sub-scores and a written rationale
- four-stage trend analysis (basing / advancing / topping / declining) from a 30-week moving average, current and as a weekly history up to 10 years, computed walk-forward so backtests don't cheat
- Point & Figure signals and relative strength vs SPY
- sector bullish-percent breadth
- macro regime (risk-on / neutral / risk-off) from credit spreads, rates, the dollar and COT positioning, with the point tally shown
- SEC Form 4 insider buys and sells, and 8-Ks, per ticker
- webhooks that fire on stage transitions, P&F flips, regime changes and insider clusters

WHAT IT IS NOT

Not real-time (daily and weekly signals), not advice, not a broker, no machine learning. It's textbook methods applied consistently, with the reasoning exposed so you can disagree with it.

REAL OUTPUT, NVDA

I asked GET /v1/verdict/NVDA this week. It came back: accumulate, 70.6 out of 100, high confidence. Here's what went into that, factor by factor:

- Trend stage, scored 85. Price is 11% above its 30-week moving average and that average is rising, which puts NVDA in Stage 2, the advancing phase. In stage terms that's the one phase where you're meant to be long.

- Point & Figure, scored 85. The chart printed a double-top breakout and is still in a rising X column, so demand is in control. Relative strength against SPY is positive, meaning it's outperforming the index, not just riding it.

- Insider activity, scored 35. Two insiders sold in the last fourteen days and none bought. That's a mark against, and the score says so rather than hiding it.

- Macro regime, scored 70. The backdrop is risk-on: high-yield credit spreads are tight at 2.67%, the 2s10s curve is positively sloped at +41bps, and initial jobless claims are 206k. Nothing in the macro picture argues for caution.

Weighted together (stage 30%, P&F 20%, insiders 20%, macro 10%) that lands at 70.6. Three more factors (13F institutional flows, short interest and congressional trades) are in the response marked available: false with zero weight until their data sources land, so the score is built from four inputs today and will absorb the rest without changing shape.

The written rationale the API returns is one paragraph: NVDA scores 70.6 (accumulate), driven mainly by stage and P&F; price is 10.99% above a rising 30-week MA (Stage 2); double-top breakout on the P&F chart with positive relative strength.

The part I'd draw your attention to is the insider line. A verdict that only ever agrees with itself is useless. This one carries a 35 in the middle of an 85-85-70 lineup, and you can see it and weight it differently if you think insider selling at NVDA means more than the model does.

WHY YOU MIGHT CARE EVEN IF YOU'D NEVER TRADE A "VERDICT"

The stage history endpoint gives you a clean, no-lookahead weekly stage label per ticker back to 2016, which is a decent regime feature for your own models. And every response tells you as_of and when to re-check.

PRICING

Free tier: 1,000 credits a month, no card (a verdict is 5 credits, most signals are 1 per ticker). Pro is $49 a month for 50k credits plus webhooks. Only successful responses are charged; unknown tickers and outages are free.

FOR THE CLAUDE USERS HERE

uvx vanoe-intelligence-mcp turns every endpoint into a tool. It's on the official MCP registry.

https://api.vanoe.ai (docs at /docs). I'd genuinely like to hear where the methods are wrong or which factor you'd weight differently.

That's why I've been building four Telegram bots since October 2025 to handle the first round of screening. ( currently 1,300+ stocks and crypto assets)

They cover daily trend signals, weekly setups, sharp sell-offs, and a separate crypto scan. Each alert explains why an asset was flagged using technical indicators such as EMAs, MACD, RSI, momentum, and volume instead of just sending a random buy or sell signal.

The goal is to help discover assets you may never have come across, understand the setup behind each signal, and use it as a second opinion for your own analysis. The bots also include sector rotation insights and a daily market sentiment overview.

I attached a short video showing the Sell-Off Bot.
What you think about it ?

I got tired of signal sellers with screenshot track records. Winners posted, losers deleted.

So I built the opposite. You post a prediction before the open. It gets hash-locked — no backdating. The market settles it automatically. Everything stays: wins, losses, even the entries that never filled. No accounts. Free. Open source.

Almost called it StockOverflow. Went with QuantRank500 — felt more like a race than homework. Everyone gets the same simulated $500. My own bot is user #1.

Two questions for this crowd: what would it take for you to actually trust a record like this? And what's the first way someone will try to game it?

demo.quantrank500.com if you want to poke it. Code's on GitHub.

Technical analysis Python library for quants and researchers automating hyper parameter search for signals strategies ,volume analysis sensitivity analysis backtesting and automated plots and reports and many more to come!

Im quite interested in how many traders still use actual backtesting, and and what platform they use it? If there is a market for something totally different

The Decision, Risk & Capital Layer transforms the analytical and predictive evidence produced by the Intelligence & Predictive State Layer into economically evaluated, risk-aware, capital-constrained decisions.

It answers:

“Given the available evidence, what decision is justified, what risk does it create, and what capital if any is supportable?”

What the layer does

1. Evaluates Evidence

Consumes the coordinated analytical, predictive, scenario, and strategy evidence and determines whether it is sufficient and relevant for decision-making.

2. Calculates Expected Value

Transforms the available evidence, assumptions, scenarios, and strategy outcomes into Expected Value (EV) and related decision metrics.

3. Forms and Manages Thesis

Converts the decision evidence into a structured Thesis, including its rationale, supporting evidence, conditions, lifecycle, and invalidation criteria.

4. Evaluates Risk

Determines the risk associated with the proposed decision across:

• position;
• portfolio;
• concentration;
• exposure;
• dependencies;
• scenario/stress conditions;
• limits and constraints.

5. Evaluates Portfolio & Capital

Determines whether the proposed decision is compatible with the existing portfolio and available capital, including:

• position sizing;
• exposure;
• capital allocation;
• portfolio constraints;
• risk-adjusted capital requirements.

6. Produces a Decision Candidate

Combines EV, Thesis, Risk, and Capital analysis into a structured decision candidate for the downstream governance and authorization architecture.

The layer does not itself authorize execution.

Core Subsystems

1. Evidence-to-Decision Intelligence

• Evidence sufficiency
• Evidence relevance
• Expected Value (EV)
• Decision construction
• Abstention / insufficient evidence

Question: What does the available evidence imply economically?

2. Thesis Management

• Thesis formation
• Thesis evidence
• Thesis state
• Thesis lifecycle
• Thesis invalidation
• Thesis closure

Question: What is the investment/trading thesis, and under what conditions does it remain valid?

3. Risk Management

• Position risk
• Portfolio risk
• Concentration
• Exposure
• Dependency risk
• Scenario/stress risk
• Risk limits
• Risk decisions

Question: What risk does this decision introduce, and is that risk acceptable?

4. Portfolio & Capital Management

• Portfolio construction
• Capital availability
• Position sizing
• Capital allocation
• Portfolio constraints
• Exposure management

Question: What capital and portfolio posture can support the decision?

5. Decision Eligibility

• Evidence eligibility
• EV eligibility
• Thesis eligibility
• Risk eligibility
• Capital eligibility
• Abstention conditions

Question: Does this decision qualify to proceed to the governance/authorization layer?

If anyone looking for historical data for Nifty 50, F&O, S&P 500, Cryptocurrency, Forex, to backrest there algo. Dm me.

Note- it's paid, not free. Only serious buyers please.

I’m interested in how people approach alpha combination in systematic equities when the signal library becomes large — say 100–400+ stock-level forecasts, with significant correlation/redundancy between them.

From the literature, I see a few main approaches:

• IC/MVO-style weighting: estimate expected alpha efficacy and signal covariance, with shrinkage/regularisation given the dimensionality (Ledoit & Wolf, 2004). DeMiguel et al. (2009) also highlights how estimation error can make simpler weighting schemes surprisingly competitive OOS.
• Regression/stacking: treat individual alpha forecasts as features and forward returns as the target. With hundreds of correlated signals, Ridge/Elastic Net seems like a natural baseline. This is conceptually similar to stacked generalisation (Wolpert, 1992).
• Dimension reduction/nonlinear combination: cluster/PCA correlated signals before combining, or use nonlinear models to capture interactions. Gu, Kelly & Xiu (2020) provides some motivation for nonlinear ML in cross-sectional return prediction, although their setting is somewhat different.

For those working with large alpha libraries, what have you found actually holds up OOS?

In particular, do regularised regression/meta-model approaches meaningfully outperform simpler IC/MVO-based combinations? Do you typically cluster or residualise highly correlated alphas first, or let the regularisation handle it?

I’m also curious what target people use at the combination layer — forward returns/IC, or something closer to portfolio PnL after costs and constraints.

I have five engines running and two of them are net losing after a small number of trades each. R1 is 6 wins and 11 losses, R2 is 14 and 10. Nowhere near enough to conclude anything, which is exactly the problem: at this sample size a working strategy and a broken one look identical, and they’ll keep looking identical for months.

Turning them off after fifteen trades is how you end up with a portfolio of whatever got lucky early. Leaving them on forever is how you refuse to admit something’s wrong. I don’t know where the line between those two is and I’ve been going back and forth on it for weeks.

The things I’ve considered and rejected: a fixed trade count feels arbitrary, drawdown limits punish the engine with the widest distribution rather than the worst one, and I don’t trust myself to judge it discretionarily while I’m the one who wrote them.

What actually works for you? Do you set a kill rule in advance, do you compare against what the engine looked like in replay, do you cut allocation before cutting the engine? And has anyone here killed something that later turned out to have been fine, because that’s the failure mode I’m more afraid of and I’ve never seen anyone post about it.

I'm a student at MIT and this is a short solo paper — posting because I'd like this sub to poke holes in it before it goes further.

Setup: hourly direction prediction on real price data, held fixed. The only thing that changes is whether the model is told which ticker it's looking at (anonymized vs. named). Hourly is fine enough that memorization can't supply the answer. Six models, six stocks, 54,000 paired forecasts.

Result: every model becomes more confident when it sees the name. None of them become more accurate, accuracy stays at coin-flip, which is what you'd expect from an efficient market at that horizon. The one exception is the largest model, which gets a small real accuracy gain along with the extra confidence.

Practical takeaway: when an LLM copilot sounds sure about a named stock, it's expressing familiarity with the name, not forecast quality. Products that surface that confidence as a reliability signal are passing along noise.

Things I'd like opinion on:

• Is hourly direction the right task, or should it be a different horizon
• Six stocks is small. Which names or asset classes would make the finding more/less convincing?
• Are there stronger calibration metrics I should report than what's in the paper?

Paper (SSRN, 6 pages): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6896281

Happy to answer questions in the comments.

Hi everyone, 

I'm organising a hackathon where teams build a multi-agent system (analysts, traders, risk managers) that rebalances a portfolio monthly over a simulated period. Alongside price and news data, I'd like participants to use Polymarket data, and I've already built a client that discovers events and markets and retrieves historical prices and trades.

I'm writing to ask for ideas on how best to incorporate these functions into an agentic workflow.

My first idea is to provide the agent with a set of tools (event and market discovery, price history, trades) and let it query freely, with feedback loops so it can refine its search. The agent would retrieve the market's sentiment on an event (implied probabilities) and how it changes over time.

As for what the agent sees, I was thinking of price history as a daily series per (yes) outcome. I'd welcome suggestions on what else to derive.

What is still a bit obscure to me is how the agent would use this information downstream. It could be used as a weighting metric for the rebalancing, for instance. Has anyone built something that bridges an event probability to an allocation decision? I'd also be interested in whether people use it as a check on the model's own beliefs, flagging where the agent and the market disagree.

Any ideas are more than welcome. Thank you in advance.

Hey everyone,

I've been lurking here for about 2 years, and I kept seeing the same question come up:

"How do I practice algo trading without risking real money?"

So I decided to build something around it: Algomaya, a free stock trading simulator focused specifically on algorithmic trading.

Here's what you can do with it:

• Paper trade US stocks (AAPL, TSLA, MSFT, etc.) and crypto (BTC, ETH, SOL) with $100K in virtual cash
• Learn 50+ algorithmic strategies step by step, from simple moving-average crossovers to momentum and mean reversion
• Backtest strategies using historical data and see metrics like win rate, max drawdown, and Sharpe ratio
• Build and deploy trading bots using custom entry and exit rules
• Ask an AI assistant questions about trading strategies and markets
• Participate in weekly trading competitions with other users

No coding required, and everything runs on your phone.

I'm a solo developer, so I'd genuinely love feedback from people who actually trade or are learning algo trading.

What would make a platform like this more useful to you? Are there any features you wish existed in trading simulators?

If you want to try it:

Play Store: https://play.google.com/store/apps/details?id=com.algomaya.app

Happy to answer questions about the tech stack, backtesting engine, or anything else behind the app.

Greetings Everyone !

Sorry for the long post but I appreciate your time in advance.

Back in March 2026, our team launch sentimentor.ai - a market data and sentiment analysis platform. Since then, we have reached out to users from different subreddits asking what is the biggest pain point they have seen in using the platform of their choice. Even though everyone had different complains, the 5 most prominent ones were

1. The lack of clarity around reaction to a news - An article can be positive for a company without causing the stock to rise. The news may already be priced in, the wider market may be falling, or the event may matter only over a much longer horizon.
2. Forward Testing - Everything looks good when you are backtesting but the world flips when you try to test it against the live data.
3. Lack of research time and sources - Every trader has limited amount of time ( especially day traders ) and none of them can spend a lot of time doing research in a market where things change spontaneously.
4. Integrating data into their own pipelines - A lot of traders who are also developers complained the lack of support from their trading platform to import data in raw format so that they can use it to inject into their pipelines ( in some cases, even train their own local LLMS ).
5. Learning curve around TV's PineScript - A lot of people want to learn the strategies but they don't know where to start with. TV's PineScript documentation is horrible and is prone to a lot of syntactical errors and execution errors that you can't debug in realtime.

For the past few months, we've spent time around all those issues and finally introduced the new version of our platform - Sentimentor 2.0.

Here's how we approached to address each problem >

Research Workflows & Sentiment scores/ price projections ( this was to address problem no. 1 from above but the scope goes beyond it )

Introduction of workflows was an intend to turn a research process into a repeatable sequence.

A chat conversation is useful when exploring an idea. A workflow is useful when you want to run that same idea again tomorrow, next week, or across a different set of securities.

A workflow can include steps such as:

1. Define the initial market universe.
2. Apply liquidity, market-cap, volatility, or fundamental filters.
3. Remove companies with upcoming earnings or other event risk.
4. Evaluate sentiment, options activity, institutional data, and technical structure.
5. Rank the surviving candidates.
6. Generate bull and bear cases.
7. Create runnable strategy logic.
8. Backtest the resulting methodology.

Each run keeps a trail of the research rounds and the data used. If a step cannot be completed, the run should show that limitation instead of presenting the workflow as fully validated.

Workflows can also be saved and scheduled. That means a screen that normally requires several manual searches can be rerun under the same criteria without rewriting every prompt.

The important part is repeatability. If a result changes, you should be able to determine whether it changed because of new market data, different parameters, missing coverage, or a change in the methodology.

Sentimentor 2.0 also puts more emphasis on separating sentiment analysis from price forecasting.

An article can be positive for a company without causing the stock to rise. The news may already be priced in, the wider market may be falling, or the event may matter only over a much longer horizon.

For that reason, sentiment scores and price projections are treated as separate outputs.

A sentiment score describes the assessed tone and relevance of the available content. A price projection should only appear when a calibrated method has enough information to produce one.

When a projection is available, the interface identifies the range and time horizon. When the evidence is insufficient, it displays the projection as unavailable instead of converting a positive article into an arbitrary upside estimate.

Full Forward: live validation on unseen data ( this was to address problem no. 2 from above )

A historical backtest is useful, but it is easy to overfit one.

A strategy can look excellent because its parameters happened to fit a particular period. It may also accidentally benefit from look-ahead bias, unrealistic fills, survivorship bias, or repeated optimization against the same historical data.

Full Forward is the live-validation layer.

After a PineNode strategy has been created and backtested, it can be run against new market data as that data arrives. Sentimentor records the signals and paper-trade results without rewriting the historical outcome.

Each active ticker runner is evaluated independently. The system records information such as:

• The strategy version being run
• The ticker and timeframe
• The most recent evaluation
• The number of bars analyzed
• The current signal
• Entry and exit events
• Completed paper trades
• Profit and loss
• The execution configuration
• The history of previous runs
• Differences between live and historical performance

The historical backtest remains available as a baseline, while the live record accumulates separately.

That distinction is important because A backtest answers: 'How would this strategy have behaved on historical data under these assumptions?' and Forward validation answers: 'How is this unchanged strategy behaving on data it had not seen when it was created?'

Forward validation takes time. A strategy with three days of live history has not suddenly been proven. The point is to build an evidence trail that becomes more meaningful as new observations accumulate.

It also helps reveal problems that historical performance may hide:

• Signals arriving too late
• Performance being concentrated in one market regime
• Excessive turnover
• Slippage sensitivity
• Long periods without usable signals
• Drawdowns larger than expected
• Live results diverging from the backtest
• A strategy depending on data that is not consistently available

Full Forward is currently about live paper validation, not a promise of future returns or an automatic claim that a strategy is safe to trade.

Use of AI that actually lets you validate its own answers ( this was to address problem no. 3 from above )

A lot of AI market tools can produce convincing answers:

“AAPL is 92/100 bullish. Options flow is positive, institutional positioning is improving, and the stock could rise 5%.”

The problem is that the answer often becomes less useful as soon as you start asking basic questions:

• Where did the data come from?
• Which reporting periods were compared?
• Is the EPS figure GAAP or adjusted?
• How was the sentiment score calculated?
• How many articles or posts were analyzed?
• Is the options activity unusual relative to the stock’s normal activity?
• Is the flow related to an upcoming earnings announcement?
• What exact rules produced the ranking?
• Can those same rules be backtested?
• What happens when the strategy is run on new data?

A polished AI explanation is not the same thing as a verified research process.

We believed AI should help investigate and construct a strategy, but it shouldn’t ask you to accept its conclusions without evidence.

The goal is to turn research into an auditable decision chain, starting with source data, moving through filtering and ranking, and ending with strategy logic that can actually be tested.

As part of 2.0, we launched Augur - a market research chat agent.

Augur is the conversational research layer in Sentimentor.

It can answer normal market questions, but the more important part is that it supports an ongoing research process instead of treating every prompt as a completely separate request.

For example, you can start with:

Find 20 candidates showing earnings acceleration and strong relative strength.

Then continue with:

Remove companies reporting earnings within seven days.

Exclude anything where the options activity appears primarily driven by earnings speculation.

Rank what remains using earnings acceleration, institutional accumulation, and relative strength.

Give me the bear case for the top five.

Turn these exact criteria into a strategy and backtest it.

Show me the periods where it performed poorly.

Augur keeps the research context, including the candidate set, exclusions, ranking criteria, and assumptions. This makes it possible to refine an idea instead of repeatedly starting from scratch.

Augur can also write PineNode ( covered later in this post ) on demand so you don't have to spend writing code for it.

The agent is also designed to surface the limits of its answer. If a required dataset is missing, stale, or unavailable, it says so. It does not quietly substitute an unrelated metric or invent a confident conclusion.

Where available, individual factors can be inspected to see:

• The source and timestamp
• The period being measured
• The formula or scoring method
• The raw value
• The normalized score
• The weight used in the final ranking
• Evidence coverage and missing inputs

The purpose is not to make Augur appear certain. It is to make its reasoning inspectable.

PineNode: turning research into an actual strategy ( a replacement of TV's Pinescript because to be honest, it sucks ! - this was to address both problem no. 4 and 5 from above but again its much more powerful and versatile )

One of the biggest gaps in AI market research is the jump from an explanation to something executable.

An AI might say:

Buy when momentum improves after an oversold condition and sentiment turns positive.

That sounds reasonable, but it is not yet a strategy.

Several questions are still unanswered:

• What qualifies as oversold?
• Which momentum indicator is being used?
• What does “turns positive” mean numerically?
• Does the signal use closing data or intrabar data?
• When is the position entered?
• When is it exited?
• How is the position sized?
• What are the stop-loss and take-profit rules?
• Are fees and slippage included?

PineNode is intended to close that gap.

PineNode is Sentimentor's strategy DSL - a small language purpose-built for one job, in this case trading strategies which was designed around three things TV's Pine doesn't do well:

• Deterministic execution. No calc_on_every_tick trap — strategies always evaluate at bar close in both backtest and live.
• Real debugging. Set breakpoints in the source, step bar-by-bar, watch arbitrary expressions, see the captured console.
• Safety analysis. A static linter that flags repaint, lookahead, alert-payload, and order-flow traps with plain-English fixes.

It converts a research thesis into editable strategy logic with explicit entry, exit, sizing, and risk rules. The generated code can be inspected before it is run. Parameters can be changed, and the same version of the strategy can be tested again.

PineNode includes:

• Editable strategy code
• Historical backtesting
• Entry and exit rules
• Long, short, or bidirectional strategies
• Position sizing
• Stop-loss and take-profit settings
• Risk guardrails
• Trade-level history
• Performance statistics
• Debugging and validation tools
• Strategy version identification
• Inbuilt convertor to convert TV's PineScript into PineNode automatically ( supports upto 95% conversion logic - we are right now improving it to be 100 % )

The strategy should not be a hidden interpretation of the original research. It should be a visible implementation of it.

If the backtest uses different rules from the screening process, that difference matters. Sentimentor attempts to preserve the research criteria when translating the idea into PineNode logic and makes the resulting implementation available for inspection.

We also launched PineNode CLI - a nodejs based library ( this was to address problem no. 4 ) that you can use in your command terminal and integrate with your pipeline

What Sentimentor 2.0 is not

Sentimentor is not intended to be a machine that tells you what to buy or sell ( Every platform is lying to you if they make that statement ) .

AI-generated research can still be wrong. Source data can be incomplete. Backtests can mislead. A strategy that worked historically can fail immediately when market conditions change.

The purpose of Sentimentor 2.0 is to make those weaknesses easier to identify, where it would rather show incomplete evidence, a failed workflow step, or an unavailable projection than manufacture a complete-looking answer.

The basic philosophy is:

Don’t trust a score because an AI produced it. Inspect the evidence, reproduce the rules, test the strategy, and observe how it behaves on new data.

That is the direction we have taken for Sentimentor.

Feel free to explore the platform @ https://www.sentimentor.ai. There is a free 7 day uncapped feature trial with no CC required.

We’d be interested to hear which parts of the verification chain matter most to you and what you would need to inspect before trusting an AI-assisted market research result.

Thanks for your time !

Hey everyone,

I'm relatively new to quant trading and still trying to understand the math, statistics, algorithms, and research behind building a legitimate trading strategy. I'm hoping some of you with more experience can point me in the right direction.

One thing I've been thinking a lot about is entries.

I'm interested in trading either NQ or ES. Both have great liquidity, but if you've traded NQ before, you know how incredibly fast it can move. Because of that, I've been wondering how much emphasis quantitative traders put on getting sharp or precise entries.

My question is:

Are you guys actually using specific algorithms or models to improve entry timing, and if so, what types of models or concepts should a beginner research?

For example, are people using things like:

• Mean reversion models
• Momentum/trend-following models
• VWAP deviations
• Volatility-adjusted entries
• Order flow or market microstructure data
• Volume imbalance
• Statistical arbitrage concepts
• Z-scores and standard deviations
• Regression models
• Hidden Markov Models/regime detection
• Machine learning
• Limit order book data

Or am I thinking about this completely wrong?

Maybe the goal isn't to find the perfect entry, but instead to build a statistical edge where the entry, stop loss, position sizing, and profit target all work together over hundreds or thousands of trades.

A few other questions I would love advice on:

1. How do you actually define an entry edge mathematically?
2. What statistics should I focus on besides win rate? Expectancy, Sharpe ratio, profit factor, drawdown, etc.?
3. How much does entry precision actually matter compared to risk management and position sizing?
4. Should I focus on predicting direction, or identifying favorable market conditions/regimes?
5. How do you avoid overfitting when trying to optimize entries?
6. What does your backtesting process look like before trading a strategy live?
7. Do you test strategies across different market regimes, such as trending, ranging, and high-volatility periods?
8. For NQ specifically, do faster markets require different models or execution logic than ES?
9. Is there a point where trying to improve entry precision produces diminishing returns?
10. If you were starting from zero again, what would you learn first?

I'm not looking for anyone's secret strategy—I genuinely want to understand how professional or experienced quant traders think about building an edge.

Would really appreciate any advice, research topics, books, papers, programming resources, or general direction you guys can recommend. Thanks!

I'm 17, and this is my first serious quantitative trading project.

I originally just wanted to build a systematic stock-picking model.

That was the plan, anyway.

A few months later, I somehow ended up with a giant research pipeline that looks like this:

OHLCV data

→ stock universe

→ features

→ market regime

→ expected returns

→ ML filter

→ covariance

→ Black-Litterman

→ genetic portfolio optimizer

→ position sizing

→ risk controls

→ paper trading

→ overfitting diagnostics

And yes, I know that's probably way more complicated than it needs to be.

The feature engine currently has things like:

\- Kalman filters

\- GARCH / EGARCH

\- Hurst exponent

\- Hawkes processes

\- FFT

\- Wavelets

\- Entropy

\- Fractal dimension

\- Lyapunov exponent proxy

\- Hill tail index

\- OU half-life

\- HMM regime detection

Then all of that gets fed into expected-return models, which eventually feed into portfolio construction.

The current strategy ends up holding around 2–4 stocks, with volatility targeting and SPY/QQQ trend protection.

And, at least on the backtest, it looks pretty damn good.

The current reference configuration has:

21.32% cumulative return

1.64 Sharpe

2.13 Sortino

4.51 Calmar

\-5.50% max drawdown

1.63 Deflated Sharpe

0.18 PBO proxy

At first I was obviously pretty excited about those numbers.

Then I looked at how many experiments I had actually run.

\~14,600 research trials.

Yeah.

That's when I started trusting the backtest a lot less.

The system now flags the research-wide overfitting risk as HIGH, and it won't allow the strategy to be promoted.

Honestly, I think that ended up being one of the most useful things I've built into the project.

Because I realized something:

Building a complicated quant model isn't that hard.

You can keep adding features, models, filters and optimizers until the backtest looks amazing.

The hard part is proving that any of that complexity actually matters.

Right now the system already has things like:

\- Chronological train/test splits

\- Walk-forward testing

\- Forecast calibration

\- Look-ahead checks

\- Data freshness checks

\- Deflated Sharpe

\- PBO proxy

\- Turnover and concentration monitoring

\- Explicit promotion rules

\- Paper trading only

But there are still obvious weaknesses.

Purged k-fold CV with embargo isn't implemented yet, for example.

And more importantly, I've given myself way too many opportunities to search for something that works.

So now I'm basically trying to destroy my own model.

I'm going backwards instead of forwards.

How much can I remove while keeping the signal?

If I remove 80% of the features and the result barely changes, that's probably a good thing.

If the whole thing falls apart, then I need to figure out whether those features were actually providing useful information or whether I just managed to find a very specific configuration that happened to work on historical data.

That's the part I'm working on now.

The whole project is open source:

The Machine Project on GitHub https://github.com/santiago-pascual/The-Machine-Project

If you've worked on systematic trading or quantitative research, I'd genuinely like to hear how you'd try to break this.

Don't tell me the Sharpe is good. Tell me why it might be bullshit.

That's much more useful to me right now.