Julien Jeremy Rodrigue Gazagnaire / 个人资料

Traders, if you could add one feature to MT5 that doesn't exist today, what would it be? No limits. Indicators, risk management, visualization, execution, anything. If one idea gets traction, I’ll try to build it as a free tool.

If it looks too good to be true, it probably is.

Quant trading is built on patience, discipline and evidence—not fantasies.

Your first mission is not to win big. It is to survive long enough to build something real.

The reward is built, never promised.

External context can filter MT5 trades: macro news, regimes, gamma/GEX, political tweets and releases.

But more variables mean more ways to overfit. Each layer needs point-in-time data, OOS, walk-forward and ablation tests—or context can manufacture false backtest winners.

Why does quant research need to run continuously?

Because robustness is rare:

100% screened
3% validated in-sample
1% validated out-of-sample
0.8% deployed live
0.2% validated under live conditions

But surviving the pipeline today does not guarantee that an algorithm will retain its edge tomorrow.

Liquidity changes. Execution costs drift. Competition adapts. Market regimes evolve.

That is why research cannot stop after deployment.

A robust systematic process must continuously:

→ search for new candidates
→ monitor existing strategies
→ revalidate assumptions
→ detect edge deterioration
→ rotate or retire algorithms when the evidence changes

The objective is not to discover one permanent strategy.

It is to maintain a disciplined research pipeline capable of replacing deteriorating edges without lowering the validation standard.

Aggregated pipeline rates. Past performance does not guarantee future results.

# The Immutable Research Handoff: Turning Completed Runs into Verifiable Evidence

Quantitative research does not end when the last backtest finishes. It ends when another machine can receive the results, verify exactly what was received, import them once, and preserve a record of what happened.

That distinction matters whenever research is distributed across terminals or computers. One node may execute campaigns while another maintains the master research database. Between them sits a handoff that can fail in quiet ways: a campaign can still be changing while it is packaged, a retry can create duplicate imports, a partial archive can look complete, or a successful upload can stop before the master index is updated.

Recent Vanguard infrastructure work treats this handoff as a protocol rather than a file copy. Results wait behind a terminal-state gate, enter an immutable package, receive a content-derived identity, and move through explicit acknowledgements. The objective is not speed alone. It is evidence that survives retries, interruptions, and machine boundaries.

## Completion Must Be Proven Before Transfer

A running campaign is mutable. Its queue changes, logs grow, checkpoints move, and individual runs can still transition between states. Copying that directory while work continues creates a package with no single meaning. The archive may contain a queue captured at one moment and reports written a few seconds later.

The safe boundary is a terminal-state gate. Before packaging begins, every run must belong to an explicitly accepted terminal class: successful, invalid for a documented reason, permanently failed, timed out, rejected, or archived. “Most runs are finished” is not a transferable state.

This does not mean that only successful runs matter. Negative and failed outcomes are part of the research record. Excluding them would change the evidence and encourage survivorship bias. The package should describe the full campaign, including every terminal outcome, rather than presenting only the attractive subset.

In the current workflow, submission watchers remain in a waiting state while campaigns are non-terminal. They retry later instead of forcing an early transfer. Waiting is therefore not inactivity. It is the correct response to incomplete evidence.

## A Package Needs a Content Identity

A filename is a weak identity. It can be reused, copied incorrectly, or point to different bytes on two machines. A campaign identifier is also insufficient because the same campaign may be packaged at different moments.

The stronger approach is to derive a content key from a canonical manifest. For each included file, the manifest records its relative path, byte length, and cryptographic hash. The research periods are also included in the canonical representation. The resulting content key changes if the package contents or declared validation periods change.

This creates a useful property: identical evidence produces the same identity, while materially different evidence produces another. A submission identifier can combine the campaign identity with part of that content key, making retries recognizable without pretending that changed contents are the same submission.

The content key is not a performance score. It says nothing about whether the strategy is good. It proves something more basic and operationally essential: which exact evidence is being discussed.

## Staging Must Detect Mid-Copy Changes

Even after a terminal-state check, packaging should not assume that source files remain stable. Another process may still write a log, update a status file, or repair an artifact.

A defensible staging process builds a source manifest first, copies the files into a temporary directory, then independently hashes the staged copy. The two canonical manifests must match before the temporary directory is promoted to the final immutable stage.

If they differ, the correct result is not a best-effort archive. It is a rejected staging attempt with a precise “source changed during staging” reason. The operator can investigate or retry after the source stabilizes.

Temporary build directories also need disciplined handling. A leftover directory from an interrupted attempt should not be silently reused. Quarantining it preserves forensic value while preventing ambiguous partial state from entering the next package.

## Idempotence Makes Retries Safe

Distributed systems retry. Networks disconnect, receiving services restart, and acknowledgements can be lost after the receiver has already accepted the bytes. Treating every retry as a new submission creates duplicates and makes the master record dependent on network timing.

Idempotence changes the meaning of a retry. If the submission identifier and artifact hash are already known, the receiver can report that the operation is idempotent instead of importing the same results again. If the identifier is known but the bytes differ, the receiver should reject the conflict.

This is why the immutable archive is reused rather than rebuilt for every attempt. Rebuilding could change metadata or compression output and weaken identity. Reusing the verified artifact keeps the retry attached to the same evidence.

Idempotence is not merely a convenience for operators. It is a data-integrity control. It allows aggressive recovery behavior without multiplying records.

## “Uploaded” Is Not the Final State

A transport request can succeed while downstream work remains incomplete. The receiver may have stored the archive but not verified its hash. It may have verified the bytes but not imported the master database. It may have imported the records but not refreshed the research index or archived the source package.

For that reason, the handoff uses staged acknowledgements rather than one generic success flag. The meaningful states are receipt, hash verification, master import, index update, and archival. Each answers a different question.

This makes recovery precise. A retry after receipt should not repeat a completed master import. A failure after master import should resume at the missing index or archive stage. Operators can see where evidence stopped moving instead of interpreting a single green or red light.

## Research Authority Must Travel with the Evidence

The package also validates its research periods against an authority configuration. The declared in-sample period must match an approved profile, out-of-sample periods must exist, and overlap between in-sample and out-of-sample ranges must be rejected.

This protects against a subtle failure: technically valid files carrying an invalid experimental design. Hashes can prove that bytes did not change, but only policy checks can prove that the declared research split follows the authorized protocol.

The handoff therefore combines two forms of integrity. Cryptographic integrity protects the artifact. Research integrity protects the meaning of the artifact.

## Keep Research Transport Separate from Live Trading

The current campaign chain records that its work is research-only and that live MT5 was not touched. That boundary deserves to be explicit in every automation layer.

Moving research results between machines should never require changing live positions, orders, Expert Advisors, or risk settings. A transfer watcher needs read access to completed research artifacts and write access to its staging and receipt areas. It does not need authority over live trading.

Narrow authority reduces the impact of mistakes. It also makes the evidence easier to trust because the process responsible for packaging results cannot silently alter the live environment it is meant to study.

## Conclusion

The last completed run is not the end of a research campaign. The end is a verifiable state transition: every run is terminal, the full record is staged consistently, the package receives a content identity, the artifact hash is verified, retries are idempotent, and downstream acknowledgements prove that the master record was updated.

This infrastructure does not make a trading strategy profitable. It makes the research record harder to corrupt, duplicate, or misunderstand. That is a quieter advantage, but it is foundational. Before performance can become evidence, the evidence must arrive intact.

## SEO Summary

An evidence-first guide to immutable, idempotent research-result handoffs using terminal-state gates, canonical manifests, cryptographic hashes, staged acknowledgements, and strict separation from live MT5 trading.

**Slug:** `the-immutable-research-handoff`

**Keywords:** quantitative research infrastructure, idempotent submission, immutable artifacts, cryptographic hashing, out-of-sample validation, MT5 research, distributed systems, research integrity

# From Performance to Evidence: What a Trading System Must Demonstrate Before It Becomes Credible

A compelling result is not yet evidence. In quantitative research, this distinction sounds obvious in theory, but it quickly becomes uncomfortable in practice. A smooth equity curve, a favorable ratio, or a profitable sequence of trades invites a conclusion. Yet none of these elements tells us whether the method survives a different period, whether the test can be reproduced, whether real execution matches the model, or whether the control mechanisms behave as claimed.

Credibility does not come from an isolated number. It comes from a chain of evidence: the origin of the result, the selection rule, data separation, independent validation, software controls, artifact traceability, and clearly acknowledged limitations. This is less spectacular than a performance promise, but far more useful.

## Selection Is Not Validation

When many variants are tested, some will almost inevitably look excellent. That does not mean they contain a durable edge. Their apparent quality may reflect chance, excessive adaptation to the research period, or a parameter combination favored by the peculiarities of the sample.

A rigorous process must make its selection rule explicit. In recent Vanguard work, thirty variants were selected from two separate research campaigns. The documented rule was to retain the best profitable variant from each family, require at least thirty trades, and rank candidates using a profit-to-drawdown relationship. This rule does not prove that the selected variants will continue to work. It does, however, make it possible to understand exactly why they were chosen.

That nuance matters. Selection answers: “Which candidates deserve an additional test?” Validation answers a different question: “What remains of their behavior when the test conditions change?” Confusing the two means presenting discovery as confirmation.

## Out-of-Sample Must Remain Truly Out-of-Sample

An out-of-sample test has value only when its period has not been used, directly or indirectly, to adjust the strategy. Moving a date in a report is not enough. The research space and the verification space must remain operationally separate.

In the current selection, the research period covers 2024 and 2025. Two independent windows are then used: 2023 and the available portion of 2026 through August 10. This structure observes a candidate both before and after the period used for selection. It guarantees nothing about the future, but it exposes several forms of fragility: dependence on a particular regime, a collapse in trade count, increased drawdown, or the disappearance of the apparent edge.

The objective is not to demand an out-of-sample result identical to the original one. Some degradation is normal. The useful question is whether that degradation remains compatible with the initial hypothesis. A system that survives only when the same conditions reappear is not robust; it is context-dependent.

## Evidence Must Be Traceable

A research chain becomes credible when a third party can travel backward from the final result to its components. Which campaign identifier produced the candidate? Which rule selected it? Which time interval was used? Which file records the decision? Which software version executed the test?

This traceability may appear administrative, but it prevents expensive errors. It avoids mixing campaigns, submitting the wrong artifact, overwriting an earlier result, or interpreting a provisional file as a final conclusion. It also makes it possible to resume an interrupted campaign while preserving the distinction between completed, ongoing, and pending work.

Campaign IDs, run IDs, and recorded periods do not improve a strategy. They make its claims verifiable. That difference is decisive: untraceable performance depends on trust, while traceable evidence can be audited.

## From the Laboratory to a Real Terminal

Statistical robustness is only one part of the problem. A MetaTrader tool must also demonstrate that it loads correctly, respects its functional boundaries, and does not turn unavailable information into a reassuring signal.

The recent validation of the Noetrix suite illustrates this second layer. All three products compiled without errors or warnings and were then checked on a real MT5 demo terminal. Lens and Sentinel were confirmed as tools with no trading capability. Guard retains protective functions, but its manual and reactive actions are disabled by default and protected by independent gates.

Real-terminal work also revealed corrections that do not appear in a backtest: handling an account with no positions, reporting missing history as unavailable rather than safe, controlling alert write frequency, reconstructing trades, and treating a disconnected terminal as critical. These details separate a visual demonstration from defensible software behavior.

## Declared Limitations Strengthen Credibility

Serious communication does not stop at what passed. It also states what remains to be demonstrated. For Noetrix, several tests remain intentionally open: protective actions on disposable demo positions, a reactive breach scenario, forced disconnection, very large account histories, multiple broker environments, and final MQL5 Market validation.

Publishing these limitations does not weaken the project. It prevents conclusions from exceeding the available evidence. A successful compilation does not prove multi-broker robustness. A demo-account test does not prove universal protection. Out-of-sample selection does not guarantee future performance. Every claim must remain proportional to the test that supports it.

## Building a Culture of Evidence

The best research infrastructure is not the one that produces the most results. It is the one that makes errors visible, preserves failures, separates stages, and prevents silent shortcuts. It should encourage five habits: document the rule before viewing the result, isolate validation data, preserve original artifacts, verify real software behavior, and publish limitations with the same precision as successes.

This discipline changes how a system is judged. Instead of asking only, “How much did it make in the test?”, we ask, “Which hypothesis was tested, under which conditions, with which safeguards, and what can we honestly conclude?”

Moving from performance to evidence is not a marketing step. It is the core of the engineering process. A strong metric attracts attention; a complete validation chain earns trust.

NOETRIX SYSTEMS: BUILDING A BETTER MT5 RISK AND AUTOMATION ECOSYSTEM

I am building Noetrix Systems as a long-term MetaTrader 5 engineering project focused on risk transparency, execution discipline and reliable automation.

The objective is not to create one isolated Expert Advisor. Noetrix is being developed as an evolving ecosystem of risk-management tools, portfolio analytics, terminal supervision and algorithmic trading systems.

The first public release is Noetrix Guard, a free account-risk and prop-firm management dashboard for MetaTrader 5.

From a single chart, Guard can monitor:

- Daily closed, floating and combined P/L
- Daily loss limits
- Max Loss with EOD Trailing
- Overall account drawdown
- Position and margin exposure
- Estimated monetary risk at stop
- Starting equity and target progress
- Locked protective actions such as Close, Reduce, Breakeven and Flatten

Guard does not provide trading signals and never opens speculative positions by itself. Its purpose is to make risk visible, rules understandable and protective actions deliberate.

It is built in native MQL5, without DLLs, external cloud services, telemetry or personal-data collection.

Noetrix Guard is available for free because I want it to become a practical tool shaped by real traders, not only by assumptions made during development.

The system is under continuous development, and constructive feedback is welcome. If you test it, please share:

- The prop-firm rules you would like to configure
- Metrics or controls that are missing
- Workflow or interface improvements
- Broker-specific situations or edge cases
- Features that would make the product more useful in daily trading

Every serious suggestion will be reviewed and may help shape future versions of Guard and the wider Noetrix ecosystem.

If you value transparent risk management, native MT5 engineering and products built around real user feedback, follow the development of Noetrix Systems and try Noetrix Guard on a demo account.

Systems. Risk. Precision. Continuous improvement.

已在MQL5.community注册