We are Student One Causal Networks. We have built an exhaustive statistical enumeration engine that runs full parameter-space searches across technical indicators, timeframes, and asset classes. The output is not a signal or a strategy recommendation — it is a structured dataset of statistically validated configurations. A neutral compute layer, not an opinion. The current build is functional for human users. What we are doing now is making it natively consumable by AI agents — proper tool definitions, OpenAPI spec, machine-readable outputs, the full stack so an agent can invoke our engine mid-conversation and return a real computed answer instead of a guess. We are in advanced discussions with one of the top three AI companies in the world to integrate this infrastructure into their agent ecosystem. We cannot name them publicly at this stage, but we will share the full picture privately with anyone serious enough to reach out. We are looking for engineers who have worked with agent-tool protocols — MCP, function calling, GPT Actions, tool-use APIs, or anything that lets a model call external compute during inference. This is a founding-stage equity role. No salary. The kind of opportunity that either makes sense to you immediately or does not. Interns with relevant skills are also welcome to apply. studentone.tech Drop a comment or message directly. Tell us what you have built.

Every "new" indicator published on TradingView, every proprietary oscillator pitched by an algo vendor, every parameter twist on RSI or MACD is reinventing a problem signal processing solved in 1942. The Hilbert transform produces the analytic signal — a complex-valued representation of any real time series from which instantaneous amplitude, instantaneous phase, and instantaneous frequency can be read directly. Every oscillator and envelope you have ever used is a degraded special case of this construction.

The Analytic Signal: Definition

Given a real-valued price series x(t), the Hilbert transform H{x(t)} is the convolution of x(t) with 1/(πt). In the frequency domain it is a 90° phase shift applied to every positive-frequency component and a −90° shift to every negative-frequency component, with magnitudes unchanged.

The analytic signal is then:

z(t) = x(t) + i · H{x(t)}

From this single complex sequence you can read, at every bar:

Instantaneous amplitude A(t) = |z(t)| = √(x² + H{x}²) — the envelope of the signal, equivalent to an idealised Bollinger band centre. Instantaneous phase φ(t) = atan2(H{x(t)}, x(t)) — where the price sits in its current cycle, in radians. Instantaneous frequency f(t) = (1/2π) · dφ/dt — the dominant cycle period at this exact bar, no fixed lookback. Three derived quantities. From one transform. With no free parameters.

Why New Indicators Do Not Add Information

Information content in a real-valued signal is fully captured by z(t) = x + iH{x}. Any derived indicator is a measurable function of z(t) — therefore by the data processing inequality, no indicator computed from x(t) can contain more information about future x(t+k) than the analytic signal already contains. New indicators can only:

Re-project the same information onto a more readable axis (legitimate, but not new). Discard information via lossy compression like fixed-window smoothing (most published indicators). Hallucinate information by combining the signal with unrelated inputs and claiming the result is "the signal" (overfitting dressed as innovation). This is not an aesthetic preference. It is Shannon. The marginal value of "indicator number 4,001" is zero unless it surfaces a projection of z(t) that no existing indicator surfaces — which has not happened in any peer-reviewed DSP publication for decades.

What "Apply It Properly" Means

The Hilbert transform is versatile because the three quantities it produces — amplitude, phase, frequency — span the descriptive space of any narrowband signal. Applying it properly means:

1. Pre-filter to enforce narrowband

The analytic signal's phase and frequency are only physically meaningful when the input is narrowband. Wide-band price series produce phase that wraps chaotically. Apply a band-pass filter — Butterworth, Chebyshev, or Ehlers' SuperSmoother — tuned to the cycle range you are studying (e.g. 8–48 bars for swing structure). The Hilbert output of the filtered series is then interpretable.

1. Use instantaneous frequency to set adaptive lookbacks

The biggest source of overfitting in indicator design is the fixed lookback. RSI(14) assumes a 14-bar cycle is canonical; it is not. The Hilbert f(t) tells you the dominant period at this bar. Every downstream indicator parameter — moving average length, oscillator threshold, regime boundary — can be expressed as a multiple of 1/f(t) instead of a constant.

1. Use instantaneous phase for trigger placement

"Cross zero," "cross the signal line," "exit oversold" are all phase events at fixed phase angles. The analytic signal lets you place triggers at exact phase angles (e.g. φ = π/2 for cycle peak) instead of approximating them through indicator crossovers that lag by half a cycle.

1. Use envelope A(t) for volatility-normalised position sizing inputs

The envelope is the cleanest available estimate of local amplitude. Replacing ATR or standard deviation with A(t) from a band-pass-filtered series removes the rectangular-window bias of rolling statistics.

The Practical Workflow

Decide the cycle band you care about (intraday: 4–24 bars; swing: 16–96 bars; positional: 80–400 bars). Apply a zero-phase band-pass filter to the log-price series for that band. Compute the Hilbert transform of the filtered series. Read A(t), φ(t), f(t) at every bar. Express every downstream rule (entry, exit, sizing, regime) as a function of those three quantities — no fixed lookbacks anywhere. Enumerate across the cycle band (not across indicator parameters), and let the survival gates pick the bands that carry edge on this asset. This is a complete signal-discovery pipeline. There is no room in it for "a new indicator." There is only the analytic signal and the choice of band.

Why This Is Not Widely Done

Two reasons. First, retail charting platforms expose indicators as configurable boxes, not as DSP primitives — there is no "compute Hilbert transform" button in TradingView Pine Script v5, and implementing it from scratch requires understanding zero-phase filtering, edge effects, and complex arithmetic. Second, the academic DSP literature on price series (Ehlers, Hilbert-Huang Transform applications in finance, empirical mode decomposition) is treated as niche by retail communities because it produces fewer "tradeable signals per chart" — exactly because it removes the redundant projections that fill conventional charts with indicator noise.

Walk-forward is the default out-of-sample protocol in retail quant. It is also the most data-hungry, the most parameter-sensitive, and the easiest to abuse. Three alternatives — anchored expanding windows, purged K-fold, and combinatorial purged CV — cover the cases walk-forward handles badly.

True rolling walk-forward partitions the calendar into K equal-sized blocks. At step k you train on block k−1 and test on block k. The window moves forward; nothing accumulates. After K−1 steps you have K−1 disjoint test scores. You aggregate (median, mean, sign-flip rate) and call it the OOS performance.

This is not the only thing labelled "walk-forward" in the wild. Until recently, our own platform shipped an anchored expanding-window variant under the same name (the engine’s walk-forward gate v1.x). The anchored variant trains on everything up to time t, tests on the next block, then expands. v2.0.0 (April 2026) switched to true rolling because the two protocols answer different questions and conflating them was a methodological bug. Most TradingView/QuantConnect strategy testers also conflate them. Read the source, not the marketing.

Where Walk-Forward Fails

Walk-forward has three failure modes that are baked into its structure, not into a poor implementation.

1. The fold count is a researcher degree of freedom

K=4? K=6? K=10? Each gives a different OOS score. If the operator can re-run with a different K until the strategy survives, the OOS test is no longer out-of-sample — it is a hyperparameter the human optimised over. The honest fix is to commit to K before running the search, and the honest defence is to insist the platform records every choice. Most implementations don’t.

1. Each test fold is a single sample

A 6-fold walk-forward gives you 5 OOS test scores. Five points is enough to compute a median. It is not enough to compute a confidence interval, a sign-flip rate with any precision, or a meaningful sample variance. The "test" is structurally underpowered for any short calendar.

1. Information bleeds across the boundary

If a trade opens in fold k−1 and closes in fold k, the test fold contains an event whose entry timing was visible during training. This is classical CV leakage and it is silent: the framework does not warn you. Cleaning it requires a purge step (drop train events whose exit_day falls inside the test window) and an embargo step (drop train events near the test boundary even if they don’t span it). Most retail walk-forward implementations skip both. Our engine’s walk-forward gate exposes a purge_overlapping_events flag that defaults off for backwards compatibility — turn it on.

Alternative 1: Anchored Expanding Windows

The expanding-window protocol trains on all data from t0 to tk−1, tests on block k, then expands the training set to include block k and tests on block k+1. The training set grows; the test window slides.

This matches the question a real operator faces in production: "I have N years of data; how does my parameter estimate stabilise as N grows?" Walk-forward, with its fixed-size training window, throws away the oldest data at every step — which is wrong if the underlying process is stationary, and right only if you specifically believe regime turnover is faster than the training window.

When to prefer expanding-window over walk-forward:

Slow-moving signals. Macro overlays, weekly-bar mean reversion, seasonal patterns. The marginal value of an extra year of training data is real; throwing it away is malpractice. Short calendars. A 4-year history split into 6 walk-forward folds gives 8-month training windows. You can’t fit anything stable on 8 months of daily bars. The expanding window starts narrow but grows. Parameter-stability questions. If you want to prove "my optimal RSI period is stable across time," the expanding window’s monotonically-growing training set is the natural diagnostic. When walk-forward is correct and expanding-window is wrong:

Known non-stationarity. Crypto pre-2018 has nothing in common with crypto post-2022. Including it in the training set drags the parameter estimate toward a regime that no longer exists. Regime-conditional signals. A volatility-breakout strategy that only fires in high-VIX years should be tested on rolling windows that contain comparable VIX states, not on a training set diluted by years of low-VIX paint-drying. The takeaway is not "use one or the other." It is that the choice between rolling and anchored is a statement about your prior on stationarity, and you owe yourself an honest answer to that question before you pick the protocol.

Alternative 2: Purged K-Fold (López de Prado)

Walk-forward and expanding windows both impose a single chronological direction. The training set is always before the test set. This is the right constraint for a real trading system. It is also the wrong constraint for asking "is my signal robust across the calendar", because it gives you only K−1 looks and they are all in the same direction.

Purged K-fold cross-validation, formalised by Marcos López de Prado in Advances in Financial Machine Learning (2018, ch. 7), keeps the K-fold idea from classical ML but adds two corrections:

Purge. Drop training events whose [entry_day, exit_day] interval intersects the test fold. This eliminates the leak walk-forward also needs to fix. Embargo. Drop training events for a buffer of e days after the test fold ends. This handles the case where the test fold’s closing trades carry residual information into the next training window. You get K test scores instead of K−1, the test folds are interspersed throughout the calendar (not just the last K−1 blocks), and the protocol gives you a meaningfully larger sample than walk-forward at the same K. Our engine implements this as the purged_kfold gate with n_folds=5, embargo_pct=0.01 as defaults.

The cost: K-fold is not a forecasting protocol. Some test folds sit in the past relative to their training data. If your strategy depends on features that drift unidirectionally (e.g. average ticker liquidity has grown 20× over a decade), purged K-fold gives you robustness scores, not realistic forecasting scores. Use it as a complement to walk-forward, not a replacement.

Alternative 3: Combinatorial Purged Cross-Validation (CPCV)

Walk-forward gives K−1 OOS samples. Purged K-fold gives K. Combinatorial purged CV gives C(K, K/2) samples — enumerating every way to split K calendar blocks into a training half and a test half, with purge + embargo on every split.

For K=14 this is C(14, 7) = 3,432 distinct OOS evaluations of the same strategy. Each one is a legitimate purged train/test split. The aggregate gives you something walk-forward cannot: a distribution of OOS scores broad enough to detect selection-process overfitting at the strategy-search level. This is the basis of the Probability of Backtest Overfitting (PBO) test (Bailey, Borwein, López de Prado, Zhu 2017), implemented as the pbo gate in our engine.

CPCV answers a different question from walk-forward: not "did this strategy survive last year?" but "if I had searched a strategy space and reported the in-sample winner, how often would that winner have ranked below the median in a randomly-chosen test half?" If that probability is above 0.5, your search procedure is systematically overfitting and the specific winner you ship is statistically a fluke.

This is the test that catches what every other test misses: the multiple-testing problem applied to the strategy-selection step itself. It is also expensive (a 0.45× cost multiplier in our pricing model, vs 0.04× for walk-forward) which is why most retail platforms don’t ship it. We do.

If you test one trading signal at p < 0.05, you have a 5% chance of a false positive. If you test 100,000 signals at p < 0.05, you have a near-certainty of thousands of false positives. The Benjamini-Hochberg False Discovery Rate (FDR) procedure is the standard statistical correction for this — and almost no retail backtesting platform applies it.

The Multiple-Testing Problem

A p-value of 0.05 means: under the null hypothesis (no real edge), there is a 5% probability of observing a result this extreme by chance. Run the test once, that's a tolerable error rate. Run it 100,000 times, and you expect ~5,000 false positives even when nothing real is happening.

This is not a subtle effect. It is the dominant source of "discovered" strategies that fail in live trading. Every exhaustive parameter sweep that does not correct for multiple testing is producing a list dominated by noise survivors.

What FDR Controls

The False Discovery Rate is the expected proportion of false positives among all positive results. If you call 100 configurations "significant" with FDR controlled at 5%, you expect at most 5 of those to be false positives. The other 95 carry genuine statistical evidence.

FDR is the appropriate target for exploratory parameter sweeps — strictly tighter family-wise error rate controls (Bonferroni, Holm) become so conservative they reject nearly everything when the test count is large. FDR keeps statistical power while bounding false discoveries proportionally.

The Benjamini-Hochberg Procedure

The mechanics:

Run all m hypothesis tests, collect p-values Sort p-values ascending: p(1) ≤ p(2) ≤ ... ≤ p(m) For each rank k, compute the BH threshold: k × α / m Find the largest k such that p(k) ≤ k × α / m Reject the null for all tests with rank ≤ k The result: a calibrated set of "discovered" configurations where the expected false-positive proportion is bounded by α.

What This Looks Like in Practice

Suppose you run an exhaustive RSI sweep — periods 2 to 14,000, oversold/overbought thresholds in 1-point increments. That's roughly 14,000 × 100 × 100 = 140 million configurations. Without FDR, even at p < 0.01, you would expect 1.4 million false positives. With BH-FDR at α = 0.05, the procedure dynamically computes a much tighter per-test threshold so that the expected fraction of false positives among called survivors stays at 5%.

In typical sweeps, the BH-corrected threshold ends up at p < 1e-7 or tighter. The number of "significant" configurations drops from millions to dozens or hundreds — and those that remain carry real statistical evidence, not noise.

Why Platforms Skip This

Retail backtesting platforms skip FDR correction for three reasons:

Marketing — "we found 1.4 million profitable configurations" sells better than "we found 47 statistically defensible configurations" Workflow — single-pass optimizers produce one "best" configuration, not a corrected family of survivors, so there is no list to correct Methodological awareness — many platform developers come from software engineering backgrounds, not biostatistics, where FDR has been standard practice for two decades The result: every "AI-discovered strategy" or "optimized indicator preset" you encounter on a retail platform was found without multiple-testing correction. The statistical claim is empty.

Romano-Wolf and Other Alternatives

For very high-dimensional parameter spaces with strong dependence structure (where individual tests are not independent), the Romano-Wolf bootstrap procedure provides tighter family-wise error control while accounting for cross-test correlation. Student One supports both BH-FDR and Romano-Wolf gates, with BH as the default and Romano-Wolf available when the configuration space exhibits high correlation (e.g., consecutive periods of the same indicator).

How Student One Applies FDR

Every exhaustive sweep runs through the FDR gate automatically. The output is two lists: configurations called significant after BH correction, and configurations rejected by the procedure. The output metadata documents:

Total tests performed (m) Target FDR level (α) The actual corrected p-value threshold Per-configuration raw p-value and BH-adjusted q-value Citation: Benjamini, Y. and Hochberg, Y. (1995), "Controlling the False Discovery Rate" This is the structure expected by institutional research workflows and academic peer review.

Try at dojo.studentone.tech