Nexus deep diveResearch frameworkCompanion to the case study
The controls a sceptical reviewer would ask for, the published research behind each one, and what runs today.
A backtest is only as good as the controls around it. Nexus applies the controls that published work on backtest overfitting, validation and trading costs recommends, and enforces them in code rather than by convention. Each one is graded against the code, so you can see what runs and what does not. A quant brings a model as one component, and the framework supplies the rest.
Grades read on 2026-10-15 from the implemented-methods checklist, refreshed that day. The other 31 catalogued items are switched off by default, planned or not built.
The Nexus overview shows research under controls as five steps. Here is each one: what Nexus does, the research it rests on, and whether it runs today.
Before any data is read
Every trial is booked in an append-only register before the first market-data read. The research pipeline's stages, batch calibration, strategy-builder long tests and promotion each check the booking again, so a run that was never booked, or is larger than its booking, is refused. Bookings made after the fact still count. The number of trials in a family sets the bar in step 5.
One exception is open. Re-pricing a live book at newly measured costs creates a re-costed copy without a booking. Whether that copy counts as a new trial is awaiting a ruling.
ResearchTry enough variants and the best one looks good by luck alone: the expected best Sharpe ratio of N strategies with no edge rises with N. Bailey, Borwein, López de Prado and Zhu (2014); Bailey and López de Prado (2014).
At those four entry points. Re-pricing a book at new costs does not book a trial yet.
Spec, code, data, operator
A counted run needs a one-shot authorisation that binds the specification's hash, the code commit, the data IDs, a review document and the operator's own sentence. It is root-owned, so no agent can write it.
WhyThis is governance rather than statistics. It makes the trial counted in step 1 the one that actually ran.
For every counted run except exploratory sweeps.
Out of sample, with leakage removed
The out-of-sample record a calibration reports comes from walk-forward analysis. Parameters are chosen on a training block and tested on the block that follows. The window then rolls forward, and the test blocks are chained into one record. Walk-forward efficiency, the out-of-sample score over the in-sample score, is reported for every run.
One limit: the parameters a calibration stores for later use are not chosen by this train-then-test loop. They come from a separate rolling ranking that scores fixed configurations on its test blocks, with a correction for the number tried, and the walk-forward search starts from that winner.
Training rows whose outcome overlaps the test block are purged, and one trading session is embargoed at the boundary. Both are counted in sessions, so weekends and holidays are handled. A fold left too thin is refused, not relaxed.
ResearchWalk-forward analysis and its efficiency ratio: Pardo (1992, 2008). Purging and embargo: López de Prado (2018), chapter 7.
On every batch calibration, as the reported record; the stored parameters come from the separate ranking. The efficiency gate fails only a negative ratio; Pardo's 0.5 rule of thumb is not a gate.
Spent once, never refunded
On the newer research path, a fixed three-year slice, September 2023 to August 2026, is sealed. A read through the governed route needs a break-seal token. The token spends one of two looks shared across the path's campaigns before the first sealed read, with no refund if the run then fails. A read without a token is logged and warned about, not blocked. A sealed result must clear a one-trial bar: a probabilistic Sharpe ratio above 95 % and a minimum Sharpe ratio.
ResearchProbabilistic Sharpe ratio: Bailey and López de Prado (2012). A hold-out stops being out of sample once a result has been tuned against it, so each look is spent, not borrowed.
No look has been spent yet. A read without a token warns rather than refuses. On the trend path the latest stretch of history is held back as a reference score, but it is not sealed.
Written before the result
Each campaign writes its accept rule before any result exists, and closes on that rule. The survivor rule for a selected candidate is the exact familywise 5 % test, assuming independent strategies with normally distributed Sharpe ratios. Its out-of-sample Sharpe ratio must clear the 95th percentile of the best of N strategies with no edge, where N is the counted family from step 1, so more trials raise the bar. Three reversion campaigns closed negative on their rules in September 2026, with the sealed years left unread.
ResearchFamilywise error control: Bonferroni, in Šidák's (1967) exact form. Why a new result needs a t-statistic nearer 3 than 2: Harvey, Liu and Zhu (2016).
At the research pipeline's survivor gate. No pipeline run has used it yet.
Some failures do not show up as a bad result. They show up as a good one. These checks run before code reaches production, not after a result looks suspicious.
Statistically powered tests feed the full search random-walk prices, which have no edge to find, and assert that the best result scores about zero. They run in CI and in the pre-deploy gate, and a non-zero score breaks the build. Look-ahead adds edge that a correction for the number of trials cannot remove, so it needs a guard of its own.
Dedicated tests check that no future data reaches a signal, and that delaying a fill manufactures no edge on random prices.
A dataset that fails its quality checks or has gone stale is refused at the start of a test and again at promotion. A nightly replay that hits a failed upstream fetch publishes nothing, and the next night retries.
In the strategy report every Sharpe ratio sits beside its standard error and the bars and years behind it, so a short record cannot pass as a strong one (Lo 2002).
Cost is where most backtests flatter themselves. Nexus charges what the broker charges, refuses to guess, and says where it still approximates.
Books that trade pay each leg's measured broker spread, half on each side, and overnight funding by asset class. A leg with no usable measurement is refused by name and never priced at a default.
The broker's minimum trade size for each market is checked when a book is frozen and again before promotion, so a book that cannot be placed at its design capital does not reach the trader.
On the newer research path, cost is resolved by year and by time of day. Older years are estimates: a per-year spread census from a market-data vendor is converted to the broker's terms by a ratio measured today, and a market with no broker measurement of its own is marked as estimated. A year with no census is never given a modern default. The cost tables are pinned by content hash, re-checked on every build, and every test also runs at 1.5 times cost. This path is separate from how trading books and the calibration search are priced.
On the target-position engine that runs panel strategies, a position is opened or added to only if its forecast clears its own uncertainty plus a round-trip cost reserve. Trend books and the calibration search do not apply this hurdle.
Small changes in the target position are held inside a band, so the book does not pay to chase noise. Under proportional costs the optimal policy has exactly such a no-trade region (Constantinides 1986; Davis and Norman 1990). Nexus sets the band's width; it does not derive it.
Each trading book reports, nightly, the multiple of its cost that would erase its edge.
Where it still approximatesTrading books charge today's measured spread across their whole history, and their report flags it. The calibration search charges a flat cost per trade; measured per-leg costs apply to the books that trade. On the newer research path, older years' costs are estimates scaled by today's broker ratio.
A result that survives selection is then watched. Every active book is replayed each night and judged by rules written before it started.
A strategy is a document of named slots, and your model fills the forecast slot. Bringing a model in is integration work through the strategy builder's extension points. It runs on an engine that already exists, under every control on this page.
Score the strategy on the one declared window for its clock. Warm-up history is loaded but never scored, and every look is logged before any data is read.
Change a stored strategy's settings within versioned, bounded menus, and save it under a name that is never reused.
Submit the document. The trial is booked in the register first. The job then queues with an at-most runtime and memory quote, and runs to a report.
What you can see is part of what gets counted.
The same sections whichever engine ran.
For a quantKeep the model in one component and the framework handles the rest: clean data, sizing, costs, counted trials and honest statistics. The two ways in, a forecast for a trend book or for a cross-sectional panel, are in the case study.
Each control is graded against the code, and the grade is shown here. Naming what is not built yet is part of the method.
Sources, read 2026-10-15: the research service's implemented-methods checklist, refreshed that day by an audit of its code as of 14 October with an adversarial re-check of every change of grade; its method catalogue and verified references; and an audit of the strategy builder for the interface section.
Every work cited on this page.
I can set up these research controls, or the parts you are missing, around your strategy or your model.