What '119 methods' means, and what it doesn't

A number like “119 research methods” is easy to misread, and easy to overstate by accident even when nobody intends to. The most common misreading is to hear “119” and assume it describes machine learning models — as if the workspace offered 119 different algorithms to choose from when training a classifier. It does not, and stating it that way would overstate the machine learning surface by roughly three times.

What the 119 actually spans

The method catalogue counts the full quantitative research workflow, not one stage of it. It spans nineteen categories: data acquisition and point-in-time handling, integrity checks and bias detection, feature construction, hypothesis tests and time-series diagnostics, supervised and unsupervised learning, time-series and volatility models, sample splitting and cross-validation, multiple-testing corrections, simulation and transaction-cost analysis, risk measurement, option pricing and short-rate models, performance ratios, portfolio allocation, factor models and attribution, regime identification, scenario and stress testing, order scheduling, and evidence assembly.

Within that catalogue, only seventeen entries — across three of the nineteen categories — describe predictive-model families at all, and each of those describes a family, such as “gradient boosting” or “random forest,” rather than a specific selectable estimator. A catalogue entry named “gradient boosting” is one line in the method catalogue; the workspace’s ML Models page, separately, offers several distinct gradient boosting implementations a researcher can actually pick from and train.

What the 43 counts instead

The distinct, selectable machine learning models a researcher actually chooses between when training something in the workspace total 43: fourteen classification models, sixteen regression models, six clustering methods, four dimensionality-reduction methods, and three anomaly-detection methods. This is a different, narrower count than the 119, and the two should never be conflated or added together. The honest way to state both together, and the phrasing this workspace uses consistently, is:

119 research methods across the full workflow — from data quality checks and statistical tests to portfolio optimisation, options pricing and reporting — 72 of them checked against a published worked example, closed-form identity, or independent library. Within that, 43 machine learning models are available for supervised prediction, clustering, dimensionality reduction and anomaly detection.

Why 72, not 119

The second number worth understanding carefully is 72 — the count of methods checked against a validating reference case, out of the 119 catalogued. This number is deliberately not higher, and it should not be read as a shortfall to apologise for. Forty-seven methods in the catalogue currently report as unverified, meaning they run exactly as documented and produce output, but nothing outside the codebase has yet confirmed their arithmetic against a published source. That is a materially different, and more honest, claim than simply marking every implemented method as validated by default.

Validation status in the workspace is derived from a table of reference cases, not hand-set by a developer’s judgement. A method is marked validated only when at least one reference case exists behind it of a genuinely validating kind — a textbook worked example, a published paper’s result, a closed-form mathematical identity, a hand-worked calculation, a cross-check against an independently maintained library, or a regulator’s own published calculation. A method checked only against a self-written reference implementation earns no validation badge at all, because a self-referential check can confirm internal consistency but cannot catch a formula that is wrong and consistently applied throughout.

Where the unverified methods sit, and why

Not every unverified method is unverified for the same reason, and lumping them together would obscure more than it reveals. Some genuinely have no single right answer to check against — a clustering algorithm or a regime-switching model succeeds by recovering a known underlying structure, which is a different and larger kind of validation exercise than confirming a formula matches a published value. Some are data or transport operations rather than calculations at all, where correctness means point-in-time discipline rather than arithmetic accuracy, and that discipline is tested by dedicated leakage tests rather than by a reference case. Others are best validated against a third-party library that simply is not available in every deployment environment, and a handful need a data source — an options chain, an order book — that this workspace does not currently ingest at all.

Why this distinction matters more than it might seem to

A research tool that reported “119 validated methods” without this level of care would be making a claim it could not support, and a sceptical reader — a quant researcher checking whether a platform’s numbers are trustworthy, or a student learning to read a methods section critically — would be right to distrust every other number on the page once that one turned out to be inflated. The alternative, stating exactly what has been checked and what has not, costs something in how impressive the headline sounds. It is also the only version of the claim that survives being checked.

This is the same standard the workspace applies to a researcher’s own reported results: a number without its validation status attached is a number that has not yet earned the confidence a reader is being asked to place in it.