Alpha Lab
A local research workstation for honest alpha research
Alpha Lab is Kacper Saks's local research workstation for building algorithmic strategies and searching for alpha signals, with integrity checks built into the tool: point-in-time data, a hash-chained trial ledger, sealed holdouts and overfitting statistics. Phases F0–F3 are complete; there are no results on real returns yet.
Key points
- Every number computed against returns is written to a hash-chained trial ledger before it can be read
- Engine: 16 years of NQ 1-minute bars in 0.83 s (warm process); matches all 47 golden checks vs X-Quant v2
- Look-ahead test on all 110 signal operators: 0 mismatches; all 6 deliberately broken versions rejected
- Integrity statistics mutation-tested: 3,081 of 3,146 mutants killed (97.93% against a 90% threshold)
What it is
Alpha Lab is a local research workstation for building algorithmic strategies and searching for alpha signals. Its thesis: the internal research platforms of large firms share a common core, and that core can be built on one laptop. It does not generate strategies. The researcher forms the hypothesis and makes every choice; the tool computes, shows every diagnostic and guards that the result is true. Kacper started it on 29 September 2026, a few hours after X-Quant's last commit. It kept X-Quant's barrier against self-deception but not its attempts: none of X-Quant's 2,976 attempts were imported. The repository is private.
Principles
The principles guard against look-ahead, uncounted attempts, reused holdout data and ignored costs. A holdout window opens only after pre-registration, once, with a permanent ledger entry. That one-time opening is procedural, and the documentation says so: the service detects and refuses a second exam, but whoever holds the key could still decrypt outside the service. Seals are optional; on day one, Kacper decided to start without them and keep all data available.
- Point in time: a decision at time t sees only data available by t
- Ledger before number: results against returns are logged before they can be read
- Every attempt counts, and the count feeds the Deflated Sharpe ratio
- Tamper-evident ledger: a hash chain and an anchor file expose rewrites and rollbacks
- Net of costs by default; the gross view is never the default
- Raw data is read-only; faulty files are quarantined, never deleted
Architecture
Every access path (web UI, SQL console, notebook SDK and CLI) goes through one data-service process, the only writer to the DuckDB catalog and the only place that logs attempts. Seven layers talk one way, from data to presentation; the UI never computes a result itself. Storage is Parquet, Arrow, DuckDB and lazy Polars: at F0, 1.04 billion rows (16 GB of Parquet) were normalised, with checksums matching for all 127,227 raw files. The vectorised numba engine is built; an event-driven engine on NautilusTrader is planned for F5, and both must produce identical trade lists on reference strategies. The API and web UI are served on 127.0.0.1 only.
- Signal DSL: 110 operators on numba kernels, plus Alpha158 and Alpha360
- Statistics: PSR/DSR, CSCV PBO, White's Reality Check, Hansen's SPA, FDR control
- Walk-forward with purge and embargo; a stability map picks a plateau, not a peak
- Every result carries an 8-tile credibility card and a “too good” badge
How it is built and checked
The build runs in phases, each with written completion criteria; in the F2 and F3 fix rounds, every fix began with a failing test. Mutation testing has two tiers: curated named mutants, which CI must kill 100% of, and mutmut over the integrity statistics, where F3 killed 3,081 of 3,146 mutants (97.93% against a 90% threshold) and triaged all 65 survivors. After F0, F1 and F3, separate AI agents reviewed the code and sceptic agents tried to refute each finding: adversarial checking by AI, not an external or human audit. F3 closed with 8,712 Python tests passed (one more failed only inside the test sandbox) and 92.09% line coverage.
- F0, foundation and data service: merged 30 Sep 2026, all 4 criteria met
- F1, engine and first screens: merged 1 Oct 2026, criteria 1–2 met, criterion 3 only partly checkable
- F2, signal lab: merged 2 Oct 2026, all 3 criteria met
- F2.1, US equity and ETF data (inserted step): merged 4 Oct 2026
- F3, research integrity and optimisation: merged 11 Oct 2026, all 3 criteria met, CI green
Known limits
One target was missed: 1,000 variants in under 3 minutes, met on a synthetic daily series (disk writes not timed) but not on NQ 1-minute data, where it measured about 4.2 minutes per 1,000; the F3 report records it as not met. Starting the trial ledger from zero has a cost too. A Deflated Sharpe ratio is only as honest as its attempt count, and much of the same history was already searched by X-Quant, so any result on that history should be read with this in mind. Results on data arriving after 29 September 2026 carry no such caveat, which is why forward tests are planned.
Status and what's next
As of 11 October 2026, phases F0–F3 and the inserted F2.1 step are complete. Next is F5, execution: the event-driven engine on NautilusTrader in a container, with limit, stop and bracket orders, partial fills and 1-second data, followed by another AI-agent review. F5 is done when both engines give identical trade lists on market-order reference strategies and limit orders report an execution gap. Then come F4 (equities and cross-sections), F4K (crypto), F6 (machine learning and mass search with an enforced trial budget) and F7 (portfolio, forward test and reports). A broker and paper-trading stage is a separate, later decision.
Record
- Status
- In development
- Stage
- In development, phases F0–F3 complete
- Sector
- Quantitative Research Tooling
- As of
Key figures
- Python tests passed (F3)
- 8712
- Mutants killed (integrity stats)
- 97.93%
- Engine, warm: 16 yrs of NQ 1-min bars
- 0.83 s
- Billion rows normalised (F0)
- 1.04
Topics
Quantitative Research, Backtesting, Research Integrity, Mutation Testing, Python
Further reading
Questions about this project?
Contact the founders