Understanding Fortuna — How the Whole Thing Works

1 · What is Fortuna Labs?

Fortuna Labs is an independent algorithmic-trading research lab. What it is, structurally, is a discipline machine: a system for proposing trading ideas, testing them honestly, and either deploying the survivors or killing them with a written record of why. Live capital is committed only after a strategy clears every gate in the pipeline.

The whole point of the system is to survive the most common failure mode in algorithmic trading: fooling yourself. Most people who try to build trading bots end up with a strategy that looks brilliant in historical data and loses money the moment it sees a real market. Fortuna's design is built around catching those self-deceptions before any real money is at risk.

2 · Why algorithmic trading at all?

Three reasons:

1. Markets have small, exploitable patterns — not predict-the-future patterns, but statistical edges in things like how prices behave around liquidity events, opening sessions, gap conditions. They're small (often a fraction of a percent per trade) but real, and humans can't trade them at the speed and consistency required.
2. Discipline beats discretion — a coded rule trades the same way at 3am as it does after a great morning coffee. A human doesn't.
3. You can test it before you risk anything — unlike discretionary trading, an algorithmic strategy can be back-tested against decades of historical data to estimate whether the edge is real.

The catch: back-tests lie. A strategy that looks great in a back-test can fail live for many reasons — overfitting to noise, lookahead bias (using information that wouldn't have been available at the time), unrealistic execution assumptions, regime change. The job of Fortuna's discipline is to filter the genuine edges from the false-positive ones before live capital is committed.

3 · The complete journey of a strategy

Every strategy in Fortuna travels through eight named stages. It can be killed at any stage, and most are. The stages live in the codebase as folder names with leading digits so they sort in order: _1-ideas, _2-hypothesis, and so on. Here's the visual:

Green-top = a stage where the discipline catches most failures. Yellow-top = paper trading (no real money). Most strategies die in stages 4–6.

What happens at each stage

4 · The single most important rule — Pre-Analysis Plans

Before any back-test or experiment runs, a written document is filed: a Pre-Analysis Plan (PAP). It lives in knowledge/preregs/ with a unique ID like PAP-20260426-01. The PAP must contain:

• The hypothesis — what specific claim we're testing.
• The universe — which instruments, which time period.
• Pre-registered metrics — what numbers will determine pass/fail.
• Pass conditions — what would need to be true for the strategy to be deployed.
• Kill conditions — what would need to be true for the strategy to be killed.
• Forbidden moves — explicit list of "things I'm not allowed to do after seeing the result", e.g. "no shifting the goalposts", "no adding features post-hoc".

Every test produces one of three pre-registered outcomes:

This pattern is borrowed from clinical trials and academic statistics, where pre-registration is the standard tool against the same self-deception problems. In algorithmic trading it's much rarer than it should be, and the absence of it is why so many "great back-tests" fail live.

5 · A worked example — MeasuredMove from idea to paper trading

Here's the full journey of a representative strategy: MeasuredMove_v1, edge ID E002. Every stage of the pipeline, with the actual artefacts produced along the way.

Total time from idea to dryrun: about a week of focused work. Total time before live capital, if it ever gets there: months. The whole rhythm is paced by deliberate skepticism, not by enthusiasm.

6 · How the fleet is structured

The "fleet" is the set of strategies the lab keeps in active rotation. Each one has an entry in state/fleet.yaml and is queryable via fortuna bot list. A strategy in the fleet sits at exactly one of three operating states:

The current contents of any of these three states is a snapshot — strategies move between them as they pass or fail their gates. The structure is durable: every active strategy is in exactly one of the operating stages, and every kill carries documentation. The membership changes; the discipline doesn't.

7 · How we know if a strategy actually works — metrics in plain English

Trading-strategy metrics have intimidating names but boil down to a few simple ideas.

Win rate

Percentage of trades that closed at a profit. By itself this means little — you can have a 90% win rate and lose money if your losers are bigger than your winners.

Profit factor

Total profit on winning trades divided by total loss on losing trades. Above 1.0 means winners outweigh losers. Above 1.5 is good. Above 3.0 is suspiciously good.

Sharpe ratio

How much extra return you get per unit of volatility. Higher is better. A Sharpe of 1.0 is decent, 2.0 is great, above 3.0 in back-tests is usually a sign of overfitting.

Maximum drawdown

The biggest peak-to-trough loss the strategy ever experienced. This matters for psychological tolerance and for capital sizing — if you can't stomach a 30% drawdown, you can't run a strategy with one.

PSR (Probabilistic Sharpe Ratio)

The probability that the strategy's true Sharpe is above zero, given the observed Sharpe and the sample size. PSR > 0.95 means we're 95% confident there's a real edge.

DSR (Deflated Sharpe Ratio)

PSR but adjusted for the fact that we ran many trials and picked the best. The more trials, the more we have to discount. K009 was killed because its DSR was essentially 0 despite a beautiful raw Sharpe.

PBO (Probability of Backtest Overfitting)

Statistical estimate of how likely the back-test result is just noise from running too many configurations. Below 50% = probably real; above 50% = probably fake.

Most of these come from the work of Marcos López de Prado in Advances in Financial Machine Learning (Wiley, 2018). Fortuna implements the canonical formulas with unit tests; full paper references are in section 14 below.

8 · What happens when a single trade fires

Here's the lifecycle of one trade, from signal to logged outcome:

Every trade — back-tested, paper, or live — ends up in the database with the same schema. This means we can ask questions across time: "in the last 6 months of LiquidityVacuum dryrun trades, how did the strategy perform in the volatile regime?" The answer comes from a single SQL query against the database, no special tooling needed.

9 · The three biggest traps — and how Fortuna defends

Most retail algorithmic trading dies for the same handful of reasons. Fortuna's discipline is built specifically around catching these.

10 · How findings stack — the knowledge system

Every meaningful outcome gets a permanent record. The system is intentionally simple: 6 folders under knowledge/, each containing append-only Markdown files with YAML frontmatter. Indices auto-rebuild via fortuna sync.

The whole knowledge base is plain text; everything is grep-able, git-able, and (where appropriate) syncable to an LLM-readable knowledge base for AI assistants to consult.

11 · The ML lab — a separate experiment

Sitting alongside the main strategy work is a more experimental layer: the ML lab. The question it tries to answer is: can machine-learning techniques improve any of our existing rule-based edges?

The lab runs ML PAPs the same way the main lab runs strategy PAPs: each one is a pre-registered hypothesis with explicit pass / kill / inconclusive thresholds, executed against historical trade data, and filed regardless of outcome. Typical ML PAP shapes look like:

• Regime gating — would skipping trades in certain market regimes improve a strategy's portfolio Sharpe?
• Regime sizing — would scaling stake by per-regime expected edge produce a better risk-adjusted return than uniform stake?
• Meta-labelling — could a secondary ML model filter the marginal trades of a primary rule, raising precision without losing too many entries?

12 · Why this approach (vs most retail algo trading)

Most people who try to build trading bots follow some version of this loop:

1. Have an idea.
2. Code it up.
3. Run a back-test.
4. Tweak parameters until the back-test looks good.
5. Deploy with real money.
6. Lose money.
7. Tweak the strategy in response to live losses.
8. Lose more money.
9. Quit.

Fortuna's loop looks different:

1. Have an idea.
2. Pass the three-question test, or kill the idea.
3. Write down the hypothesis and what would falsify it (the PAP).
4. Get clean data.
5. Code it up.
6. Back-test with lookahead-analysis.
7. Walk-forward / CPCV validate; compute DSR + PBO.
8. If pre-registered conditions met → dryrun; else file the kill with reasons.
9. 30 days of dryrun discipline.
10. Type GO LIVE if and only if the discipline says yes.
11. Monitor live; kill rules pull back automatically if drawdown limits are breached.

The first loop optimises for "ship something that works". The second optimises for "find out the truth, then ship only if the truth supports it". The second is much slower in the early days. The expectation is that it's much more durable in the long run, because it doesn't accumulate hidden self-deception.

13 · The human and the AI — division of labour

Modern research labs increasingly run on a partnership between human strategists and AI coding assistants. Fortuna is built around a clean version of that division:

• Human strategists decide what ideas to pursue, what to kill, when to deploy live capital, and what counts as evidence. Every irreversible action is reviewed before it happens.
• AI coding assistants handle execution: writing code, running back-tests, filing PAPs from templates, computing statistics, drafting findings, editing research pages. They cannot deploy live capital without explicit human confirmation.

The AI's job is to preserve the discipline — every PAP it files has the kill conditions filled in; every script it writes runs the lookahead linter; every result it reports cites the registry entry. The human's job is to make the decisions only a human can make: which ideas matter, when to stop a line of work, when to risk real money. This is the operational pattern Fortuna uses; the discipline framework itself is what makes the partnership safe.

14 · Sources & further reading

The discipline framework Fortuna runs on is not original — it borrows heavily from the academic and industry literature on quantitative finance, with particular debt to Marcos López de Prado's body of work. The substrate (PSR, DSR, PBO, CPCV, meta-labelling) is implemented per his published formulas.

Marcos López de Prado

• QuantResearch.org — his official site with most papers freely downloadable.
• Wikipedia entry — background and notable contributions.
• Advances in Financial Machine Learning (Wiley, 2018) — the canonical book. Source of the meta-labelling, CPCV, and most of the metrics framework Fortuna uses.
• Machine Learning for Asset Managers (Cambridge, 2020) — shorter follow-up; the "Seven Sins of Quantitative Investing" chapter is the in-house reference for what NOT to do.

Specific papers used in Fortuna's metric implementations

• Bailey & López de Prado (2012) — The Sharpe Ratio Efficient Frontier. Defines the Probabilistic Sharpe Ratio (PSR). SSRN.
• Bailey & López de Prado (2014) — The Deflated Sharpe Ratio. The selection-bias-adjusted PSR; this is the one that exposed K009. SSRN.
• Bailey, Borwein, López de Prado & Zhu (2015) — The Probability of Backtest Overfitting. The PBO via combinatorially symmetric cross-validation. SSRN.

Other foundations

• Politis & Romano (1994) — The Stationary Bootstrap. The bootstrap method used for confidence intervals on serially-correlated trade returns.
• Erb & Harvey (2013) — The Golden Dilemma. Background for the gold-silver mean-reversion hypothesis tested by Fortuna's metals research.
• Pre-registration as a discipline tool — the methodology is borrowed from clinical trials and the open-science movement, where it is the standard defense against post-hoc rationalisation. The Center for Open Science (cos.io/initiatives/prereg) maintains the canonical reference.