Export fidelity

By Mahé Chadeffaud, founder of Stochastly

Export checks compare generated files with the backtest on supported strategies and named reference paths. They also state which targets were executed and which were inspected without running. The scope excludes arbitrary graphs and untested strategy behaviour.

A file that compiles can still compute something else

Your backtest runs one graph. The export writes that graph in another language, and the platform on the other side ships its own indicator library. When a definition there differs from the engine's, the exported file compiles, runs, and prints entries at bars your backtest did not select.

The static product registry marks Python and C++ as executed, Pine Script, MQL5 and FASTEXPR as inspected without platform execution, and Rust as not measured. Separate native checks do not update this registry dynamically. These proof levels remain separate from complete-strategy parity.

The actual C++ export states what was replayed and the scope of the fidelity measurement. This is not a claim about live execution.

Each platform's own definition, transcribed and replayed

For the three targets with no local interpreter, the measurement replays the documented semantics of the language. ta.rsi and ta.atr use Wilder's moving average, where the engine uses a simple mean. ta.ema seeds on the mean of the first length bars, where the engine starts from the first bar. Each transcription carries its source in the code, since a transcription without one is a guess wearing the clothes of a measurement.

What comes out is a property of the formula. It carries no information about how the file behaves at a broker, and a zero would carry the same limit: it would mean the formula written into the file matches the engine. For that reason the two executed targets are reported apart from the three transcribed ones.

draws        1000 synthetic price paths
bars         3000 per draw
denominator  union of bars either side triggered
interval     Wilson, 95 %
registry     app/tests/_derive_cibles_registre.json

The same percentage, twice, covering two facts

Figure 2. Warm-up and persistent drift can produce the same headline rate. The left example concentrates disagreements at the start while indicator values converge; the file skips that warm-up before evaluating a signal. In the right example, disagreements continue to the final bar because the formulas remain different.

A rate on its own hides the shape. Disagreements concentrated in the first eighth of the series come from values that have not finished converging. The exported file carries a computed number of bars to skip before any decision, and that number is derived from the expression tree, so a nested indicator gets the longer warm-up its depth requires.

Disagreements spread to the last bar are a second fact with the same percentage attached. There the formula stays different for the export, and no warm-up removes the gap. The distribution therefore ships next to the rate, so the two cases cannot be read as the same result.

Current checks by target

Pine Script, MQL5 and FASTEXPR are inspected without running in their destination platforms. TradingView can apply its own intrabar fills and tick rounding, while timeout and session-close orders fill on the following bar. MetaTrader uses terminal history and broker fills, and its EMA warm-up can differ. FASTEXPR exports a continuous score, not a complete trading strategy. These checks are weaker than execution.

The static product registry currently marks Rust as not measured. A separate native guard can compile and execute generated Rust files, but its result is not inferred by the exporter. Required graph behaviour left behind still makes an export non-exact.

The Rust file carries its own target proof and limitations; a reference measurement leaves destination-platform execution unverified.