# Thales — an outside financial read **Reviewer's note.** This is a deep read of `~/Documents/GitHub/thales` at commit `82e802e` (2026-09-09): 35,337 lines of source across 784 commits, plus roughly 750 KB of research and audit prose. I read the strategy, the backtest engine, the cost and capacity models, the CPCV harness, the execution and safety layers, the sleeve configs, and the live state files. I ran no code and changed nothing. I am assessing this the way I would assess a small fund's research stack: not "is the code good" but **does the evidence support putting money behind it, and does the process deserve trust.** --- ## 1. The verdict in one paragraph Thales does not have a demonstrated edge, and — unusually, and to its enormous credit — **Thales knows this and says so in its own documentation.** The system has repeatedly caught itself flattering its own results, corrected the numbers downward each time, and eventually rewrote its charter so that returns are explicitly *not* the objective. That is the correct conclusion from the evidence and it is a conclusion almost nobody reaches voluntarily. The apparatus is genuinely first-rate — better than most of what I have seen inside institutions with paid quant staff. But the apparatus is now sophisticated enough to hide a small number of specific problems, and I found five worth acting on. The most serious is not a modelling error. It is that the front door of the repository still advertises validation numbers that the project itself retired four months ago. --- ## 2. What the system is A long-only US equity momentum strategy — 12-2 momentum plus a smoothness filter, top 50 names from the Russell 1000, HRP-weighted, half-Kelly sized, wrapped in a 12% VIX-scaled volatility target with a 20% drawdown kill-switch. It paper-trades on Alpaca on a weekday cron. Around it sits a platform hosting three sleeves: `momentum` (the only one whose evidence can lead to real money), `meanrev` (a deliberately falsified strategy trading live as a placebo arm), and `vrp` (defined-risk SPY put credit spreads). Live paper account: funded at $10,000 on 2026-03-20, currently $13,740. --- ## 3. On the central question: is there edge? No — and the internal record is unambiguous once you read past the README. **The validation numbers.** Current CPCV, post the 2026-08-01 stateful-purge fix: | Measure | Standard | Survivorship-free ("GOLDEN") | |---|---|---| | PBO | 62.5% | 62.5% | | Observed Sharpe | 0.780 | 0.524 | | IS–OOS correlation | −0.281 | −0.53 | | Deflated Sharpe | — | 0.611 | Read these carefully, because they are worse than they look at a glance. **PBO 62.5%** means the configuration that looked best in-sample underperformed the out-of-sample median in five of every eight trials. That is worse than a coin flip. The project notes it is "one quantum above the no-skill center," which is the honest framing — but the direction is wrong. **Negative IS–OOS correlation is the finding that matters most.** At −0.281 standard and −0.53 survivorship-free, the backtest's ranking of configurations is *anti-predictive*. This is not "we can't tell which config is best." It is "the ones that looked best were systematically the worst." That is the textbook signature of a search that has fit noise. To their credit they null-calibrated this (the C2 work showed no-skill books produce median |corr| of 0.443, so −0.281 sits inside the no-skill band) — which is exactly right and rarely done. But "inside the no-skill band" is not evidence of skill; it is the absence of evidence against no-skill. **DSR 0.611** is a probability, not a Sharpe. It says there is a 61% chance the true Sharpe clears the multiple-testing-adjusted hurdle. The conventional bar is 95%. This is a coin weighted slightly better than fair, measured after the project's own count of trials. **The timing-luck sweep is the single most important number in the repository, and it lives in a caveat.** Across the eight possible monthly-rebalance start days, the same signal produces mean Sharpe 0.09, median −0.11, range [−0.32, 0.80], with five of eight schedules negative. The headline 0.795 is **rank 1 of 8** — the best draw. The project states this plainly and refuses to re-select the schedule (correctly, as that would be data mining). But I want to be blunter than the caveat is: *if an arbitrary calendar choice moves your Sharpe from −0.32 to +0.80, you have measured the calendar, not the strategy.* Everything downstream of that — the HRP weighting, the Kelly sizing, the VIX scaling — is being tuned on a signal whose sign is not established. **The live evidence agrees.** Since the clean-clock restart on 2026-06-11, live Sharpe is **−1.33** over 61 trading days. The +37% headline on the paper account is almost entirely pre-restart and beta-contaminated; the project says so itself. None of this is a criticism of the work. It is the correct answer, arrived at honestly, about a factor that has been publicly known since Jegadeesh–Titman in 1993 and arbitraged for thirty years. The surprising outcome would have been the other one. --- ## 4. What is genuinely excellent I want to be specific, because generic praise is worthless and this deserves better. **The stateful-estimator purge floor.** `MomentumStrategy.min_required_purge` widens the CPCV purge to cover the Kelly ledger's 24-month rolling pool, because the backtest runs contiguously through interior test blocks carrying that state — so a training date can be *sized* using test-block returns even when its features are clean. Measured at ΔΔcorr −0.312 against a pre-registered 0.15 bar. I have never seen this catch made in a production system. Nearly every CPCV implementation in the wild purges features and leaves stateful estimators leaking. **Null-calibrating the overfitting metric.** Running no-skill books through the PBO harness to learn what PBO and IS–OOS correlation look like under the null is a level of rigor most shops skip entirely. It converts "PBO 62.5% is bad" into "PBO 62.5% is one quantum above the no-skill center" — which is a different and more useful statement. **`meanrev` as a live pre-registered placebo arm.** A strategy falsified by its own battery (survivorship-free PBO 87.5%), trading live anyway, with a covenant pinned before its first order that no outcome can ever promote it — and `go-live-gate` mechanically refusing it. This gives a *calibrated reference* for how good a dead strategy's forward curve can look over a short window. It is the best single idea in the repository and I would steal it. **Pre-committing to the interpretation, not just the threshold.** The December gate interpretation memo pins in advance that the Sharpe criterion is underpowered (P(pass | SR≈0.65) ≈ 12% at 126 days), that a NOT-PASS is the modal outcome and weak evidence, and that December is an operational-competence gate rather than alpha proof. Pre-registering a threshold is table stakes; pre-registering *how you will read the result* closes the last door on gate-shopping. **Documenting the formula's own error history.** The DSR docstring records that the formula was wrong twice, how, and what conclusions it contaminated — including that every prior "DSR = 0, no provable edge" verdict was partly a units artifact. Most codebases silently fix and move on. **The fail-closed safety layer** at the single `execute_orders` chokepoint, treating the broker as source of truth and independent of strategy and construction, so a sizing bug cannot route around it. This is correct design and correctly placed. The 2026-08-01 panel line quoted in NORTHSTAR — *"the apparatus is stronger than the strategy — the right way around"* — is accurate. --- ## 5. Findings ### F1 — The README advertises retired numbers. *Severity: critical (trust).* `README.md` states: **"CPCV PBO 50%, mean OOS Sharpe 0.624, IS-OOS correlation +0.02, 15/15 positive OOS paths."** Every one of those figures has been superseded. The current record is PBO 62.5%, IS–OOS correlation −0.281 (standard) and −0.53 (survivorship-free). `CLAUDE.md` explicitly labels the `+0.02` correlation as "the historical no-op value" measured while `daily_turnover_cap` was silently inert, and warns that all PBO figures recorded before 2026-05-30 ran on a leaky harness and should be read as roughly 25pp optimistic. `README.md` was last modified **2026-05-25** — five days before the leak fix that made the numbers harsher. And `tests/test_docs_consistency.py` line 500 explicitly exempts `README.md` from coverage. So: the one document a stranger reads first is the one document the pinning machinery does not guard, and it states the pre-correction numbers in the project's own voice. NORTHSTAR §3 names C0 — *never spend trust* — as the constraint that outranks every gauge, and lists "no post-hoc edit to frozen text, no silent scope change." A stale front door is the same failure by omission rather than commission. This is the highest-severity item in the repository and it is a ten-minute fix. ### F2 — Two risk systems are pulling against each other, and a constant is deciding. *Severity: high.* From today's live snapshot: `gross_leverage: 0.2943`, `vol_scalar: 2.688`, against `max_leverage: 3.0`. Working backwards: the half-Kelly composite is sizing the book to roughly **11% gross**. The VIX-scaled volatility targeter is then multiplying by 2.69 to reach 29%. The scalar has been sitting near its 3.0 ceiling. These two systems are answering different questions and disagreeing. Kelly says *the estimated edge is tiny, so size tiny*. The vol targeter says *realized volatility is below 12%, so lever up*. Both are behaving correctly in isolation. But when the scalar pins against `max_leverage`, the actual position size of the portfolio is being set by **an arbitrary configuration constant**, not by either risk model. The `leverage_cap_basis` note shows the team has seen the mechanism (C1, 2026-08-01). I would go further: this is not a cap that occasionally binds, it is the binding constraint in the current regime. There is also a deeper issue. Half-Kelly requires an edge *estimate you believe*. With DSR at 0.611 the edge is statistically indistinguishable from zero, and Kelly applied to a zero edge sizes to zero. The 11% gross is not information about how much edge there is; it is the noise in the edge estimator. Sizing on it, then levering the result 2.7×, compounds an estimation error rather than managing a risk. ### F3 — The book has collapsed below its minimum viable size. *Severity: high.* From the current target weights against $13,740 of equity: - 50 target names, 29.3% gross - **Median target position: $61.65** - 26% of positions under $20; 48% under $50; 70% under $100 - Smallest: MRNA at **$1.82**; SNDK at $4.14 (0.0026 shares at $1,566/share) And the live book holds **67 positions against a 50-name target** — turnover-cap residue that has not been cleared. A $1.82 position cannot influence the P&L of a $13,740 account under any market outcome. It can, however, pay a bid-ask crossing every time it is touched. Roughly a quarter of the book is in positions that are pure cost with no capacity to contribute. The nominal breadth is 50; the effective breadth is perhaps 15. There is a `capacity.py` that studies the *ceiling* — at what AUM does the flat-10bps assumption break. The binding constraint here is the **floor**, and I did not find a study of it. For this strategy the floor is roughly where the smallest target position clears a few hundred dollars: call it $150K–$250K of equity for 50 names at full gross, and considerably more at 29% gross. Below that, the strategy being validated and the strategy being traded are different objects — which is precisely the failure mode `execution-fidelity-gap` was written to prevent, reappearing through a different door. ### F4 — The OOS monitor's verdict flipped to "OK" while live Sharpe was −1.33. *Severity: medium-high.* `oos_monitor.py` sets `MIN_OOS_DAYS = 60` with the comment: *"Below this the Sharpe CI is so wide the test has no power; declaring OK or DEGRADED would be theatre."* The verdict history: ``` 2026-09-01 INSUFFICIENT_DATA n=56 live_sharpe −1.70 2026-09-09 OK n=61 live_sharpe −1.33 ``` Nothing about the evidence improved. The sample crossed an integer threshold, and the label changed from an honest statement of ignorance to a word that reads as reassurance. The monitor's own design principles include *"do not false-reassure."* The mechanism is defensible — "OK" means the live metric has not fallen below the in-sample bootstrap CI lower bound, and at n=61 that bound is very wide. But the project's own interpretation memo puts the power at ~12% even at 126 days. At 61 days it is far lower. A verdict vocabulary that offers only OK / DEGRADED / INSUFFICIENT_DATA cannot express "we now have enough data to compute a number, and that number is uninformative." I would add a fourth state, or keep INSUFFICIENT_DATA until the test has the power the memo says it needs. ### F5 — The benchmark is SPY, and for this strategy that is the wrong question. *Severity: medium.* `metrics.py` computes beta, Jensen's alpha, information ratio and capture ratios against a benchmark, and the configured benchmark is SPY. The SHIP gate is composed entirely of Sharpe, PBO, IS–OOS correlation, and survivorship-free confirmation. No gate anywhere requires the strategy to beat a *momentum* benchmark. For a 12-2 momentum book on the Russell 1000, "does it beat SPY, beta-adjusted" is a question with a thirty-year published answer that has nothing to do with whether this implementation is worth running. The decision-relevant question is: **does it beat MTUM** — an ETF that harvests the same factor, at 0.15%, with no operational burden, no cron, no reconciliation, and no leak risk. Right now the project could clear every gate it has written and still be strictly dominated by a one-line ETF purchase, and nothing in the harness would say so. This is the one place where I think the rigor is pointed slightly off-axis. Everything is aimed at *is this real?* Almost nothing is aimed at *is this better than the free version?* --- ## 6. Two structural observations **The fleet is one bet.** Two long-equity books and a short SPY put spread are all short the same left tail. The 2026-08-01 amendment to `fleet.yaml` identifies this precisely, refuses diversification credit until crash coherence is actually observed, allocates as if correlation is 1.0, and pre-commits that daily P&L correlation is *not* evidence because a $1-wide spread marking in cents produces arithmetic noise. That reasoning is correct and I have nothing to add — I flag it only so it is not mistaken for diversification by a future reader. **The VRP sleeve is the only one that can produce a surprise.** Momentum and meanrev fail slowly and legibly. A short put spread fails discontinuously. The defined-risk structure, the 2% strike-based budget, and the safety gate's independent recomputation of worst case are the right controls, and the sizing is genuinely small. But it is worth being explicit that this is the one sleeve where a single gap can produce a loss that the equity curve gave no warning about — which is exactly the "short-vol Sharpe illusion" the fleet amendment names. --- ## 7. What I would do Ranked by value per unit of effort. 1. **Update the README today, and put it under the docs-consistency pin.** Quote the current numbers with the timing-luck spread beside them, as CLAUDE.md already does. This costs ten minutes and it is the only finding here that touches C0. 2. **Write down the minimum viable equity for the strategy, and pin it as a gate.** Something of the form: *no sleeve trades a target book whose median position is below $X*. Then either fund the paper account to a size where the validated strategy and the traded strategy are the same object, or cut the name count until they are. Running 50 names on $13,740 is testing an execution stack, not a strategy. 3. **Add MTUM (or a long-only momentum index) as a second benchmark, and add "beats the passive factor proxy net of costs" to the SHIP gate.** If the answer is no — which it may well be — that is a *cheap permanent no*, exactly the A3-pattern win NORTHSTAR §1 counts as an asset. 4. **Resolve the Kelly-vs-vol-target conflict explicitly.** Not by moving `max_leverage`, which would be tuning the symptom. Decide which system owns sizing when they disagree, write down why, and pin it. The current answer — whichever hits its cap first — is not a decision anyone made. 5. **Give the OOS monitor a fourth verdict** for "computable but underpowered," or raise `MIN_OOS_DAYS` to where the interpretation memo says the test has power. Do this before December, so it is not a change made while looking at the gate result. 6. **Leave the strategy alone.** The temptation with an apparatus this good is to keep searching the same panel for the alpha that is not there. NORTHSTAR §2 already forbids this in writing, and it is right. The large-cap price-and-fundamental space is exhausted on this data; more search spends trial budget to manufacture noise. --- ## 8. Closing The most valuable thing here is not the momentum strategy — it does not appear to work, the record says so plainly, and the charter has already stopped pretending otherwise. The valuable thing is a research apparatus that has caught its own leak four separate times, published each correction downward, null-calibrated its own overfitting metric, and runs a known-dead strategy live specifically to keep itself honest about short windows. That is rarer than alpha and considerably harder to build. The findings above are the price of that sophistication: the machinery is now good enough that the remaining problems hide in the places the machinery does not look. Four of the five are in the seams — the unguarded README, the constant that ends up doing the sizing, the account too small for the strategy it runs, the verdict label that changes without the evidence changing. The fifth, the benchmark, is a question the apparatus was never pointed at. Fix the README first. Everything else can take its time. --- *Assessment of `~/Documents/GitHub/thales` @ `82e802e`, 2026-09-09. No code was executed and no files in that repository were modified. Not investment advice.*