The quant workflow: idea → rules → test → validate → run

The previous lessons covered what quant traders do, what you bring from discretionary trading, and the number they are all trying to estimate. This lesson puts those pieces in order. Systematic trading follows a workflow with five stages. Each stage produces something specific, and each ends with a question that decides whether the idea moves on or stops.

The five stages

1. Idea

An idea is a specific belief about market behaviour that could be true or false. "Stocks that gap down on no news tend to recover part of the gap within a week" is an idea. "I want to trade momentum" is a direction, not yet an idea.

Output: a one-sentence hypothesis and a reason to believe it, such as an economic explanation, a behavioural one, or a pattern you have observed repeatedly.

Gate: can it be stated precisely enough to test, and is there a reason it might work other than "it looked good on a chart"?

2. Rules

The idea becomes a complete set of rules: what to trade, when to enter, when to exit, how much to risk, and what it costs. Nothing is left to judgement.

Output: a written specification, dated, before any test is run. Here is a template:

Name:          Pullback in an uptrend (v1)
Date written:  before any testing
Hypothesis:    Short pullbacks within an established uptrend tend to recover.
Universe:      Daily bars, liquid instruments only, defined list fixed in advance
Entry:         50-day average above 200-day average AND 2-period RSI below 10,
               enter at the next day's open
Exit:          Close above the 5-day average, or after 10 trading days
Stop:          2 x average true range below entry
Risk:          0.5% of the account per trade
Costs:         Spread and commission per trade, plus slippage on entry and exit
Reject if:     Expectancy after costs is not positive on out-of-sample data,
               or results depend on one narrow parameter choice

Gate: could someone else run these rules from the page and get the same trades?

3. Test

The rules run over historical data, bar by bar, recording every trade they would have taken. This is a backtest. It needs clean data, realistic costs, and strict care that each decision uses only information available at that moment. Using information from the future, even by accident, is called look-ahead bias; Module 01 shows the simplest version of it in a few lines of code.

Output: a trade list, an equity curve, expectancy after costs, maximum drawdown and other statistics.

Gate: is expectancy positive after costs, with a drawdown you could actually sit through?

4. Validate

A good test result is a claim, not a fact. Validation tries to break it. Does the result hold on data the rules were not designed on? Does it survive small changes to the parameters, or does it collapse if 50 becomes 45? How much of it could be luck? This is where overfitting is caught.

Output: an honest judgement of how much the test result can be trusted, and a realistic range for what to expect.

Gate: does the edge survive data it has never seen and reasonable variations of its rules?

5. Run

A validated system is run, first on paper or with very small size, then with the risk the specification allows. Running is active work: checking that live trades match what the rules should have done, comparing live results with the range validation suggested, and deciding in advance what would make you stop.

Output: live results, monitored and reviewed against expectations.

Gate: is the live system behaving within the range validation suggested? If not, is the difference noise, a problem with execution, or a sign the edge has changed?

The workflow is a filter

Most ideas do not make it through. Many fail at the test stage, and many of the survivors fail validation. That can feel discouraging, but it is the workflow doing its job. A rejected idea costs time; an untested one that reaches live trading costs money.

The workflow also loops. A failed validation often suggests a better question, which becomes a new idea. Live monitoring may show that costs are higher than assumed, which sends you back to the rules. Over time, the data handling, code and reports you build make each loop faster.

How the course follows the workflow

The eleven modules of this course map onto the five stages. Some modules serve more than one.

Module 01, next, gives you the basic tools: Python and pandas, used on price data. It is the foundation for testing, which is why it comes before the stages that rely on it.

Where the Lab fits

The SCUTA Quant Lab is planned as a place to run the exercises from each lesson without setting up anything locally. It is not open yet. Until it is, every exercise in this course can be done on your own computer with the setup from Module 01, and each lesson's Lab card describes the exercise in full.

Before you move on

You now have the whole map: what the work is, what you already bring, the number you are trying to estimate, and the order in which to do it. The rest of the course fills in each stage with practical tools, starting with code.