PatternRank: from research pipeline to published rankings
Published
PatternRank turns a Python research pipeline into a US equities ranking product. The engineering challenge was to make a ranking traceable from its input data through publication and, later, its measured outcome.
My role: Creator & Quant Engineer, covering the research workflow and the web product that exposes it. Core stack: Python, tree-based machine learning, Next.js, and Supabase.
Define what the system is evaluating
The main workflow ranks short-horizon momentum setups and measures their outcomes over seven days. Rankings refresh after the US market close, and completed outcomes remain available for review.
An early version labeled historical breakouts and trained models to recognize similar patterns. That was useful for exploration, but a model can appear successful by recognizing a move that is already obvious. I shifted the workflow toward labels for conditions before expansion, so the research question matched the point at which a ranking would actually be produced.
This made label design an engineering concern. A training example must have a clear information boundary: what was available at scoring time, and what only became known afterward. An impressive score is not useful evidence if that boundary is blurred.
Separate research computation from product delivery
The pipeline prepares the instrument universe, calculates indicators, generates features, scores candidates, and publishes structured rankings. Outcome updates happen after the measurement window has elapsed.
Market data and universe preparation
→ indicators and feature generation
→ model scoring and ranking
→ publish rankings to Supabase
→ measure outcomes after the 7-day window
The web application reads those outputs. Next.js provides the product surface, Clerk handles authentication, and Supabase holds product data. The interface includes current rankings, historical review, model context, and performance analysis.
This separation lets research produce a structured result that the product can present consistently. It also creates a responsibility at the boundary: the ranking's date, model, universe, and outcome window must retain their meaning when they move from research code into the interface.
The ML work uses tree-based models, including XGBoost, with calibration and feature-contribution analysis supporting review. Model choice is one part of the system; labels, inputs, universe construction, and evaluation determine what the resulting score can reasonably mean.
Make the research context visible
The product distinguishes 7D All Stocks from 7D ETB. ETB means
Easy-to-Borrow; that universe applies additional liquidity and borrowability
constraints. Keeping the universes separate prevents a filter difference from
being hidden behind one combined result.
The interface presents model type, confidence, ranking date, and completed outcome. Feature-contribution summaries give readers some explanation of the ranking while keeping exact feature transformations and label construction private. That is a deliberate tradeoff between inspectability and exposing the full research implementation.
The public sample ledger, captured in October 2026. Select the image to inspect the full-size interface.
Evaluate the process as well as the output
The validation questions that matter are specific: were features available at the time of the ranking, were prices adjusted consistently, and did the historical universe account for instruments that later disappeared? Evaluation also needs to distinguish a ranked price outcome from an executable trade.
I built the workflow around validation without future information and repeated measurement after publication. That does not make every possible source of bias disappear. Data coverage, universe selection, execution assumptions, and the chosen evaluation period still affect how results should be interpreted.
A seven-day price outcome is not a user's realized return. Position sizing, entry and exit timing, costs, and execution all change that result. The product therefore exposes research rankings and outcome context rather than choosing trades for a user.
For a meaningful comparison between model versions, I would want the evaluation period, universe, sample size, and assumptions alongside the figures. A headline return alone would obscure too much of the engineering and research process.
What shipped
The delivered workflow connects daily scoring, structured publication, and completed-outcome review in one product. The public sample ledger lets a reader inspect past rankings without signing up; the authenticated app provides the broader research interface.
What I would carry forward
The most useful decision was making outcome review part of the original product boundary. It forces a ranking to remain meaningful after the moment it is published, rather than disappearing when attention moves to the next result.
For future work, I would keep label design, temporal validation, and publication semantics close together. They are easy to split across research and application teams, but an inconsistency between them can make a technically correct system answer the wrong question.