Reproducibility on Mulham Fetna

Every number we publish is machine-verified. Here's the machinery

contact@mulhamfetna.com (Mulham Fetna) — Mon, 07 Sep 2026 00:00:00 +0000

The hardest problem in trading research isn’t statistics — it’s that the researcher grades their own homework. You choose what to try, what costs to assume, when to stop, and what to show. After three and a half months of running a research programme under that temptation, we’re convinced the only defense that holds is mechanical: make it impossible to publish a number that doesn’t re-derive from evidence.

This post describes the system we built and now run everything through. The full methodology paper is at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7428478; the code is public.

A claim is an object, not a sentence
#

In our repository, a published number isn’t prose — it’s a registered object with required fields: the statement with its numbers inline; the evidence files that produced it (committed to git — a claim whose evidence isn’t version-controlled is rejected structurally); an executable re-derivation compared to the published value within an explicit tolerance; three independent verifications that must fail for different reasons, one of which is a falsifier — a test built so that a specific way of being wrong would trip it; and a mandatory declared blind spot, because “verified, with no stated limitation” is itself a defect.

Our track record can't cheat. Here's how we froze it

contact@mulhamfetna.com (Mulham Fetna) — Mon, 07 Sep 2026 00:00:00 +0000

Every trading track record you’ve ever seen asks you to trust its author about one thing: that the rules weren’t adjusted along the way. Strategies quietly swapped after a bad month, windows chosen after the fact, losers left out of the tally. You can’t audit any of it, so the record is worth exactly as much as the author’s word.

For the final act of this project, we built a track record where the author’s word doesn’t matter.

Out-of-sample by construction
#

On 2026-08-31 we signed a protocol — a public document in the repository — that froze everything an author could later fudge:

The universe: exactly 9 of our 54 configurations, admitted by five pre-registered criteria applied to the forward books (the selection beat a random-set control — claim LIVE-ALLOWLIST-FROZEN). Not one slot was hand-picked.
The parameters: the deployed set, pinned by cryptographic hash into the signed document. The replay tooling refuses to run if the universe file differs by one byte from the signed hash.
The rules: one contract always, the engine’s stated fill conventions, mechanical kill rules, and a “never-list” (no manual overrides, no window cherry-picking, no pausing to wait out a drawdown) — violations void the record’s claims from that point, by the protocol’s own text.

flowchart LR
    P["✍️ signed protocol
2026-08-31, public in the repo"] --> U["THE UNIVERSE
9 of 54 configurations,
admitted by five pre-registered
criteria (beat a random-set control)"]
    P --> PAR["THE PARAMETERS
pinned by cryptographic hash —
replay refuses to run on a
one-byte difference"]
    P --> RU["THE RULES
1 contract · stated fills ·
mechanical kills · never-list
(violations void the record)"]

Because the parameters and universe were published before any future data existed, every recorded window is out-of-sample by construction. When new data arrives, it is first audited against the previous delivery for retroactive changes (a repaint check), then replayed with the frozen set. The result becomes a new claim in the machine-verified ledger — a losing window under exactly the same rules and prominence as a winning one. The protocol says so in writing: a negative outcome is a publishable result of the protocol, not a failure of it. No verdict is allowed before a pre-registered power threshold; interim windows are descriptive only.

What 16 years of data and 3.5 months of honest testing taught us about trading strategies

contact@mulhamfetna.com (Mulham Fetna) — Mon, 07 Sep 2026 00:00:00 +0000

This is the story of a research project my team at BeInMedia ran from May to September 2026: a systematic attempt to find out what actually survives in futures trading once you stop fooling yourself. We built the machinery, paid for the answers, and published everything — including the failures. The code, the evidence, and every number below are public and machine-verifiable: github.com/mulhamfetna/trading-strategy-finder.

Here is the whole arc, honestly told.

flowchart LR
    A["May 2026
machinery built:
backtest engine · optimizer ·
claims ledger"] --> B["Jun–Aug 2026
the studies:
economic-calendar sweep ·
225-cell ORB grid ·
forward test of our own fleet"]
    B --> C["Aug 31, 2026
track record frozen
under a signed protocol"]
    C --> D["Sep 2026
two preprints filed ·
everything published,
including the failures"]

The rule that shaped everything
#

Backtests lie — not because the math is wrong, but because the person running them chooses what to try, what costs to assume, and what to show you. Our defense was structural: every study was pre-registered before it ran (design, thresholds, controls frozen in writing first), every negative result had to prove it had the statistical power to see an effect, every positive had to beat a dumb control, and every published number lives in a machine-verified claims ledger — re-derived from committed evidence files by our CI on every change, 79 claims and counting. If a number in this series doesn’t re-derive, our own build fails.

Reproducibility on Mulham Fetna

Every number we publish is machine-verified. Here's the machinery

A claim is an object, not a sentence #

Our track record can't cheat. Here's how we froze it

Out-of-sample by construction #

What 16 years of data and 3.5 months of honest testing taught us about trading strategies

The rule that shaped everything #

A claim is an object, not a sentence
#

Out-of-sample by construction
#

The rule that shaped everything
#