A term plan for teaching quant research with a workspace
A twelve-week course structure that follows the eight-stage research journey, with assessment ideas for each stage.
An instructor teaching a term-length quantitative finance course faces a familiar tension: the syllabus wants to cover portfolio theory, machine learning, backtesting and validation in twelve weeks, but each topic taught in isolation produces students who can compute a Sharpe ratio on a problem set and still cannot say whether a strategy they built themselves is any good. The gap is not coverage. It is sequencing — students need to move through the same research journey a working analyst moves through, in the same order, so that each stage’s output becomes the next stage’s input, and each stage’s caveats stay attached to the work rather than getting forgotten between assignments.
This article lays out a twelve-week structure built around the eight-stage research journey — Universe, Explore, Data, Portfolio, Features, Models, Strategy & Backtest, Evidence — with a concrete deliverable and assessment idea for each stage. It assumes a workspace where every student works in their own isolated project, so a class of thirty produces thirty independent research trails rather than one shared spreadsheet everyone edits at once.
Why stage order matters more than topic order
A conventional syllabus often teaches portfolio optimisation before machine learning, or validation as a single lecture near the end rather than as a habit built in from week one. The eight-stage journey resists that ordering deliberately: Data preparation comes before Features, which comes before Models, which comes before Strategy & Backtest, because that is the order in which a mistake at an earlier stage silently breaks everything after it. A student who builds features before understanding what point-in-time alignment does to their dataset will produce a model whose provenanceProvenance The recorded origin of a dataset or result — its source, content hash, and the parameters used to produce it — that lets a number be traced back later. is compromised in a way that no amount of later validation can retroactively fix.
Teaching stages in this order, rather than by topic convenience, means a student cannot reach the modelling assignment without having already made — and been graded on — the upstream decisions the model depends on.
The twelve-week plan
| Week | Stage | Focus | Deliverable |
|---|---|---|---|
| 1 | Orientation + Universe | What quantitative research is, and why the universe choice is the first source of bias in every downstream number | A written universe selection memo: index chosen, date range, provider, and a stated survivorship-bias caveat |
| 2 | Universe (cont.) | Comparing index catalogues; coverage marked full, partial or composite | Revise the memo after the instructor questions one coverage assumption |
| 3 | Explore | Return, volatility, drawdown, distribution and correlation statistics before any model exists | An exploratory statistics report on the chosen universe, with at least one correlation finding stated and interpreted |
| 4 | Data | Calendar alignment, missing-value policy, outlier treatment, the chronological train/test split | A data-preparation log documenting every policy choice and the row counts removed at each step |
| 5 | Data (cont.) + Portfolio intro | Why a shuffled split leaks information; introducing mean-variance optimisation | A short written explanation, in the student’s own words, of why their split must remain chronological |
| 6 | Portfolio | Weighting methods, constraints, the efficient frontier | A portfolio construction assignment comparing at least two allocation methods (for example equal weight against minimum variance) on the same universe |
| 7 | Portfolio (cont.): scenario and stress | Applying a historical replay or hypothetical shock against the constructed portfolio | A stress-test memo: which scenario, what happened to the portfolio, and one honest statement of what the scenario does not capture |
| 8 | Features | Building and selecting predictive features as hypotheses about market structure | A feature-engineering notebook justifying each feature’s inclusion with a one-sentence hypothesis, not just a technical description |
| 9 | Models | Training a supervised model on the leakage-aware pipeline | A model-training report including the chronological split design and pipeline warnings, if any were raised |
| 10 | Models (cont.): validation and comparison | Walk-forward folds, the worst fold, ranking competing models honestly | A validation report showing the fold-by-fold breakdown and comparing at least two model families, sorted by a Deflated Sharpe RatioDeflated Sharpe ratio The Sharpe ratio adjusted for the number of configurations tried and for non-normal returns, so a result picked from many looks less impressive. rather than raw Sharpe |
| 11 | Strategy & Backtest | Turning model signals into rules; backtesting net of costs against buy-and-hold | A strategy specification and backtest comparing gross and net-of-cost performance |
| 12 | Evidence | Assembling the term’s work into one checkable report; presenting it | A final evidence pack following the eight-section structure, presented to the class or a review panel |
Weeks 5, 7 and 10 are deliberately built as continuations rather than new topics, because the most common failure mode in a compressed syllabus is treating each stage as a single lecture and moving on before the caveats have actually landed. Giving the split, the stress test and the validation step a second week each protects the parts of the course most prone to being rushed.
Assessment ideas that reward honesty over polish
A grading rubric built around this structure should reward the same things a working reviewer looks for, covered in more depth in /quantlab/practice/presenting-quant-work: whether the student can state what their own numbers mean, whether the validation avoided the standard mistakes, and whether the worst case was shown rather than hidden behind an average. Three concrete rubric ideas:
- Grade the limitations section as its own line item, worth a meaningful fraction of the final report grade, separate from the quality of the result itself. This removes the incentive to omit a weak point in order to protect the overall grade, and directly counters the tendency (see /quantlab/practice/writing-a-checkable-report) to bury limitations in a single vague sentence.
- Require the worst foldWorst fold The single lowest-performing fold in a walk-forward or cross-validated evaluation, the number that should headline a validated result, not the average., not just the mean, in any assignment involving walk-forward or cross-validated results, and grade its presence explicitly. A model comparison assignment that reports only mean accuracy across models should be marked down even if the mean numbers themselves are computed correctly.
- Penalise an unreported trial count. If an assignment allows students to try multiple feature sets or models before submitting one, ask for a short statement of how many configurations were tried in total, and grade whether the student understands that a result chosen from many attempts is a weaker claim than one from a single attempt. This is the classroom version of the trial-ledger discipline covered in /quantlab/practice/reproducible-research.
Reusing the term’s work as a capstone
The final week’s evidence pack should not be a new analysis — it should be the accumulated output of weeks 1 through 11, assembled into the fixed structure described in /quantlab/practice/writing-a-checkable-report: universe and data, absolute and benchmark-relative risk, portfolio construction, model, out-of-sample validation with the worst fold shown, strategy backtest, and a specific limitations section. Structuring the capstone this way has a practical benefit beyond pedagogy: a student who has kept honest records at each of the preceding eleven weeks can assemble the final report largely by compiling what already exists, while a student who cut corners earlier in the term will find the gaps in their own work impossible to hide by week 12.
Isolating each student’s work
A course run this way works best when each student’s research lives in its own isolated project — its own universe, dataset, models, workflows and audit trail — rather than a shared class workspace everyone edits. Isolation means a grading TA can open one student’s project and see only that student’s decisions, without another student’s universe selection or feature choices bleeding into the view. It also means a student who wants to revisit week 4’s data-preparation log while working on week 9’s model can do so without their own earlier work having been overwritten by anyone else in the class.
Role structures suited to a multi-seat deployment map naturally onto a classroom: an instructor or course administrator holding the broader management role, teaching assistants able to run and read across student projects for grading, and students working within their own project with the ability to build, run and report. Matching real course roles to a workspace’s role structure keeps grading access clean without giving every student administrative visibility into everyone else’s work.
What this plan does not try to do
Twelve weeks following this structure will not produce a student who can price an exotic option from first principles or derive a GARCH model’s asymptotic properties — that is a different course, likely a prerequisite to this one rather than a replacement for it. What this plan produces is a student who has been forced, at every one of the eight stages, to make an explicit decision, write it down, and carry its consequences into the next stage. That habit — decisions recorded, caveats attached, worst cases shown — is the actual skill a research-methods course is trying to teach, and it transfers to whatever specific model or market a student ends up working on after the term ends.