Forward observation asks how a fixed EA behaves on data that arrives after its test plan is frozen. It is useful only when the version, information available at each decision and review rules remain traceable. A profitable interval chosen after the event is not the same experiment.
Separate operational readiness, evidence completeness and performance evaluation. The first guide's reconciliation establishes what happened; this guide defines the protocol for observing it prospectively. Neither a clean ledger nor a completed schedule establishes profitability or permission to fund a live account.
1. Write the question before collecting results
State the behavior and environment being evaluated: signal timing, decision reproduction, request handling, execution differences or a precisely defined performance hypothesis. Name the comparison and the evidence needed to answer it. Do not substitute a rising balance for all these questions.
Record all earlier variants and selection attempts, including failed ones. A new forward period does not erase the model-selection history. Repeatedly tuning after viewing results makes those observations part of development. The overfitting guide explains why an attractive selected backtest needs more scrutiny.
2. Keep shadow, demo and live evidence distinct
Here, shadow means an observer that records decisions without sending orders. Demo means requests sent to a simulated broker account; live means actual funded-account execution. Document the mode explicitly rather than using the word forward as if it guaranteed real fills.
| Mode | What it can record | Main evidence limit |
|---|---|---|
| Shadow observer | Decisions and available inputs; no orders | No observed broker execution |
| Demo account | Decisions, simulated requests and broker records | Does not establish live fills or costs |
| Live account | Actual requests, broker records and account effects | Capital at risk; results remain uncertain |
This guide's invented example uses demo only. It supplies no live-allocation recommendation. Compare modes only after matching versions, data and time coverage, and keep their records separate. The demo-versus-live guide explains execution differences; a shadow observer cannot infer real fills from a Bid chart.
3. Freeze a manifest that identifies the experiment
Archive the EA binary/build and, when available, source revision; record file hashes, input values and the parameter file. Include broker server, account and mode, account currency, symbol mapping, timeframe, dependencies, terminal build, clock basis, data sources, risk-policy version, start, end rule and review schedule. A file name alone is not a configuration identity.
For the teaching fixture, freeze build EA-A and inputs I1 on a demo EURUSD H1 run. The manifest contains the timestamps and identifiers of the fixed expected decision slots. Keep the trading and risk rules unchanged; the guide does not supply those rules or a trading controller. Operational safety remains governed by the existing account-risk policy.
4. Capture what was actually available at each decision
Save the decision cutoff, closed-bar identifiers, relevant prices and features, source timestamps, receipt times and freshness checks. Use a documented clock normalization. In the invented example, feature F1 is stamped 09:00:00 but arrives at 09:00:08, after the snapshot frozen at 09:00:05. It cannot enter that decision. The later 09:00:10 review must preserve this fact.
An earlier source timestamp is not proof that the EA could read the value then. Follow the frozen missing-data rule, including a documented skip if required. Store later corrections separately. Reconstructing decisions with revised history, a finished forming bar or a value received afterward introduces information the original run did not have.
5. Predeclare the window and expected opportunities
Specify the start and end rule, market calendar, permitted sessions, expected decision schedule, warm-up exclusions and planned review points before observation. Explain how closures, missing bars, restarts and outages are treated. An outage must not disappear from the denominator merely because no order was sent. Keep scheduled slots distinct from signals, requests and completed trades.
The invented schedule contains 100 expected decision slots in 4 consecutive blocks of 25. Review after each block and close the scheduled observation after the last slot. These counts make the audit easy to reproduce; they are not a recommended minimum or a statistical power calculation. Real duration and evidence needs depend on trading frequency, dependence, market conditions and the question asked.
6. Predeclare review, interruption and change rules
Separate source-quality gates, operational escalation and performance criteria. Define metrics, ownership, costs, cash-flow handling, open-position treatment and comparison tolerances before results are known. The equity and drawdown guide and cost guide supply accounting context, not universal acceptance thresholds.
For this demo fixture, every expected decision must have traceable evidence before the performance dossier can be signed off. An unresolved slot keeps that sign-off inconclusive. Scheduled reviews do not delay urgent action under the existing risk policy. Do not extend a test until it wins, stop at a favorable peak or quietly change a threshold after a loss.
7. Audit the invented coverage example
The table contains non-overlapping blocks, not cumulative totals. A traceable decision has preserved as-of inputs and a logged outcome, including any documented no-signal or skip; an unknown slot lacks sufficient evidence. R2 has a missing decision record that remains unresolved at the final review. Do not assume that the missing slot had no signal, request or exposure.
| Review block | Expected decisions | Traceable decisions | Unknown slots | Evidence coverage |
|---|---|---|---|---|
| R1 | 25 | 25 | 0 | 100% |
| R2 | 25 | 24 | 1 | 96% |
| R3 | 25 | 25 | 0 | 100% |
| R4 | 25 | 25 | 0 | 100% |
Across all blocks, 99 of 100 decisions are traceable and 1 is unknown: coverage 99%. Later complete blocks do not repair the earlier gap. Under the fixture's predeclared complete-evidence gate, the dossier stays inconclusive. The coverage calculation neither measures trade win rate nor says that the strategy failed; even complete records would still need a separate adequacy and performance assessment.
Optional: reproduce the evidence counts and coverage
Expected slots: 25 + 25 + 25 + 25 = 100. Traceable decisions: 25 + 24 + 25 + 25 = 99. Unknown slots: 0 + 1 + 0 + 0 = 1. Complete block: 25 / 25 × 100 = 100%. Incomplete block: 24 / 25 × 100 = 96%. Overall coverage: 99 / 100 × 100 = 99%. Unknown share: 1 / 100 × 100 = 1%. Count check: 99 + 1 = 100. Percentages describe evidence coverage only; numeric notation follows English conventions.
8. Treat changed rules as a new run
A changed threshold, input file, symbol universe, session filter or risk rule changes the experiment. Record the reason and effective time; preserve the old run and start an identified new version. For example, EA-B with inputs I2 must not be appended to EA-A with I1 as if nothing changed. Infrastructure changes also need a dated incident/change record and an assessment of comparability.
A bug fix may be necessary, but it does not turn already viewed observations into unseen validation data. Preserve the incident and the affected period; obtain later evidence under the new protocol. Report all variants and prior looks. Do not overwrite a poor run, pool incompatible results or present a retrospective replay as an original forward record.
9. Respect historical-tester and platform limits
Historical testing and forward observation answer different questions. Native MT4 testing has documented limits: external-interaction functions such as WebRequest() and SendNotification() are not executed in the Strategy Tester, and trade operations on symbols other than the tested symbol are not performed. A historical pass cannot demonstrate the working live data and alert paths.
Use the backtesting guide for model and data assumptions and the monitoring guide for operational paths. Verify cross-symbol input availability separately from order execution. Actual receipt, disconnection, recovery and protection evidence must come from an appropriate observed environment, not an assumption that tester behavior transfers unchanged.
10. Write a bounded conclusion at the planned review
Report protocol identity, mode, actual dates, expected and observed coverage, incidents, version changes, unresolved items and the predeclared metrics with their limitations. Include losses and open exposure rather than only favorable closed trades. Statistical assessment must account for dependence and repeated selection; this teaching example performs no significance test or probability-of-overfitting calculation.
- Were the manifest, comparison, window and review rules frozen before results?
- Did every decision use only information actually available at its cutoff?
- Are shadow, demo and live records clearly separated?
- Are gaps, incidents, costs, open positions and version changes visible?
- Does the conclusion follow the original criteria without treating coverage as profitability?
Use a precise conclusion: evidence incomplete, evidence complete but insufficient for the stated question, or a documented result under the predeclared assessment. None automatically promotes a demo EA to live funding. Any later deployment or allocation needs its own authorized decision and risk controls. Preserve the dossier for subsequent monitoring and revalidation.
11. Questions about forward validation
Does forward mean live trading with real money?
No. State whether the observation is shadow, demo or live. Only the live mode records actual funded-account execution, and it exposes capital to loss.
Are the example's 100 decisions enough to validate an EA?
No such claim is made. They are an invented coverage fixture, not an evidence-size recommendation. Decisions are not necessarily trades or independent observations, and complete coverage alone does not establish an edge.
Can I improve parameters and keep the same forward result?
Retain the old result, but identify the change as a new run/version. Observations already used to choose parameters are development evidence, not fresh validation for that choice.
Does 99% coverage mean a 99% win rate?
No. It means that the stated share of scheduled decision slots has traceable evidence. In this fixture the unresolved gap blocks the predeclared evidence sign-off, regardless of any trading result.
12. Sources and scope
Primary sources: MQL4 Strategy Tester operation and limits, MetaTrader's tester setup and input parameters, and Bailey and co-authors, The Probability of Backtest Overfitting. Sources checked on 2026-10-18. The research motivates caution about selection; it does not certify this protocol or supply its example counts.
The run names, feature times, schedule and counts are invented teaching inputs. No actual EA strategy, live performance, minimum sample size, expected return or funding recommendation is supplied. The diagrams depict protocol and evidence, not original tester reports. A frozen plan improves traceability; it does not guarantee profitable or safe trading.