Tier 6 · Master · Module 6.2
Design and document a complete original trading system
The capstone brief — design an original trading system in your chosen specialisation and document it to a professional standard, from thesis and rules to risk, testing evidence, and operating procedures.
Lesson 1 of 3 · 5 min read
The capstone brings everything together. You'll design a complete trading system — your own, in your chosen specialisation — and document it so thoroughly that another trader could run it exactly as you would. This document becomes the basis for your live trial and your final presentation. It's also the most valuable thing you'll produce in the whole course: a written, tested, professional-grade trading business plan for one strategy.
What you'll learn
- What "original" means for a capstone system
- The ten sections of a complete system document
- The evidence your document needs from testing
- Operating procedures: running the system day to day
- How the capstone is assessed
1. What "original" means
Original doesn't mean inventing a new indicator. It means your system: a specific combination of market, timeframe, logic, filters, risk, and execution that you designed, can explain, and have tested yourself. Using well-known concepts (trend structure, ATR stops, session filters) is expected — what matters is that the whole system is coherent, specified, and evidenced.
2. The system document
Build it in ten sections:
| # | Section | Contents |
|---|---|---|
| 1 | Summary | One paragraph: what the system trades, how, and why it should work |
| 2 | Thesis | The market behaviour it exploits and the reasoning behind it |
| 3 | Universe and timing | Markets, timeframes, sessions |
| 4 | Rules | Regime filter, setup, trigger, entry, stop, targets, management — unambiguous (see Entry, stop, and target rules) |
| 5 | Risk | Risk per trade, per theme, total open risk, daily/weekly limits, drawdown tiers |
| 6 | Costs and execution | Spreads, commissions, swaps, slippage assumptions; order types |
| 7 | Evidence | In-sample, out-of-sample, and forward-test results (section 3 below) |
| 8 | Operating procedures | Daily, weekly, and monthly routines; what to do if something breaks |
| 9 | Failure conditions | When the system should be reduced, paused, or retired |
| 10 | Version history | Every change, with date and reason |
3. Evidence requirements
Your document should include:
- Backtest: at least 100 trades, costs included, with win rate, average win and loss in R, expectancy, profit factor, maximum drawdown, and longest losing streak (see Manual backtesting on TradingView)
- Robustness: out-of-sample results with rules frozen; parameter-stability check if the system has tunable parameters (see Quant / Systematic Trading)
- Forward test: demo results over a meaningful sample, compared with the backtest (see Forward-testing on demo)
- Honest limitations: conditions where the system underperformed and why
Worked example: an evidence summary table
(Illustrative.)
| Metric | Backtest (in-sample) | Out-of-sample | Forward test |
|---|---|---|---|
| Trades | 164 | 71 | 58 |
| Win rate | 41% | 39% | 38% |
| Avg win / loss (R) | +2.3 / −1.0 | +2.2 / −1.0 | +2.1 / −1.05 |
| Expectancy | +0.35R | +0.25R | +0.15R |
| Max drawdown | −9R | −8R | −7R |
The edge shrinks at each stage — a normal, honest pattern. The document should explain why (costs, fewer ideal conditions, execution) and whether the remaining edge justifies a live trial.
4. Operating procedures
Describe exactly how the system is run:
- Daily: pre-session checks, when signals are evaluated, how orders are placed, logging
- Weekly: review of results against benchmarks, event map for the coming week
- Monthly: performance report (see Record-keeping, tax basics, performance reporting)
- Incidents: platform outage, missed signal, wrong order size — what to do in each case
5. How the capstone is assessed
Your capstone is judged on:
- Clarity — is every rule unambiguous?
- Coherence — does the thesis match the rules and the markets chosen?
- Risk — are limits complete and conservative?
- Evidence — is testing honest, sufficient, and cost-inclusive?
- Self-awareness — are limitations and failure conditions clearly stated?
Profitability alone is not the goal. A modest, honestly tested system with clear rules and sound risk management is a stronger capstone than an impressive-looking backtest with weak evidence.
Common beginner mistakes
- Vague rules that need judgement to apply.
- Evidence without costs, or only an in-sample backtest.
- Missing failure conditions.
- Changing the system without updating the version history.
- Hiding weaknesses instead of documenting them.
Key terms
| Term | Meaning |
|---|---|
| Capstone | A final project demonstrating mastery of the course |
| System document | A complete written specification of a trading system |
| Evidence summary | Test results across in-sample, out-of-sample, and forward stages |
| Operating procedures | Routines and incident responses for running the system |
| Failure condition | A pre-set trigger to reduce, pause, or retire a system |
Practice
- Create your system document with all ten section headings.
- Complete sections 1–6.
- Gather and summarise your evidence in section 7, using the table format above.
- Write sections 8–10, then run the stranger test with a trading peer.
Quick recap
- Your capstone system is yours: a coherent, specified, tested design.
- Document it in ten sections, from summary to version history.
- Include honest evidence across in-sample, out-of-sample, and forward testing.
- Define operating procedures and failure conditions.
- Clarity, coherence, risk, evidence, and self-awareness matter more than headline profit.
Educational content only — not financial advice. Trading involves substantial risk of loss. Practise on a demo account before risking real money.
