Our audits do not pair trades from the report alone. All 33 audit files in this catalog, 26 default runs and 7 variant runs, record that the tester journal was provided, and all 33 report that the pairing was decided from that journal at exact confidence. In 2 of them the journal holds two test runs instead of one. MT5 starts its order numbers over with every test, so reading both at once would connect an exit of the second run to an entry of the first. What follows is what the engine does about that and what a reader can check afterwards.
A tester report lists deals. It does not say which entry an exit closed, and for a robot that holds several positions at once that link cannot be recovered from the deal list alone. The journal says it, in two shapes of line. One is the stop or target line that names both orders at once. The other is a close request followed by the execution line that quotes the order it was based on. Our source records why both are needed and attaches a measurement. In the Pulse Engine run 2,709 of 2,801 exits were actively closed and only 92 went through stop or target, so the stop line alone would have left almost every pair unresolved.
Six further fields of every audit come from the journal rather than the report. The date from which real ticks exist, per symbol. The minutes for which ticks had to be generated. The execution delay. The count of failed entries. The count of failed modifications. And the count of randomizer prints, which is the field that sets the non deterministic flag of the audit. A missing journal would not just cost the pairing, it would empty that whole row of the measurement table.
The parser reads the journal line by line and starts over from an empty state whenever it passes a test start marker. What survives at the end of the file is the last test in it. The number of markers passed is published as its own field of the audit.
The reason for starting over sits in the source comment at that line. A journal that was never cleared holds several backtests, and the order numbers begin again with each one. Carrying pairs across a marker would not leave a visible gap, it would produce wrong pairs that look right.
31 of the 33 files report exactly one test in their journal. The two that report two are Logan, whose journal is 20260817.log, and Waka Waka, whose journal is 20260813.log and which is unlisted here and therefore stands without a link. Both audits print the same sentence under the measurement table, that the tester journal contained 2 test runs and only the last one was used.
Three audits name two journal files instead of one, and in each case the two are consecutive days. Adaptive Gold Scalper lists 20260816.log and 20260817.log, Gold Trade Pro lists 20260823.log and 20260824.log, and Prop Firm Gold EA lists 20260817.log and 20260818.log. All three still report exactly one test run. The run crossed midnight, the terminal opened a new daily file, and the parser reads the files as one stream in name order, which for MT5 journal names is chronological order.
The opposite case has its own printed note. A journal that begins after the start marker, the second file of such a rollover taken on its own, counts zero runs, and the audit then states on the page that the file looks like a fragment and that the pairing falls back where the journal is incomplete.
Counting markers is bookkeeping and not proof. The proof is the coverage figure. For every exit the engine looks up the entry the journal names and uses it only if that entry is still open in the reconstruction. Only those hits count toward coverage. A pair carried over from a different run cannot match, because its order numbers are not in this report, so reading the wrong run does not create wrong pairs, it creates missing ones. Our source states that at the line that grants exact confidence, and the grant requires at least 90 percent of the exits to be covered.
Logan is the case worth reading twice. Its journal held two tests. Its coverage is 1.0 across 1,372 trades, which is 2,744 deals in the report, so the surviving run accounts for every exit in it. And the journal was not decoration. In 285 of those pairings the entry it names is not the one a first in first out rule would have taken.
Across the catalog 31 of the 33 files carry a coverage of 1.0. The two below it are Waka Waka at 0.996 over 530 trades, which is the other two run file, and Quantum Emperor at 0.995 over 559 trades. Both are still labelled exact because both sit far above the threshold. Waka Waka reports 0 pairings that differ from first in first out, so for that run the journal confirmed the simple rule instead of correcting it.
Every audit also stores a SHA-256 hash over the bytes of the report file it parsed, and the measurement table prints the first 16 characters of it. Logan's begins e43c96589c07916a.
What that hash proves is narrow and worth saying plainly. It pins the file we read. It is not a vendor signature, it says nothing about who produced the run or on which machine, and it cannot make the numbers inside the file true. It makes exactly one thing checkable, which is whether a report handed to you later is the report the audit was built from.
The practical version is short. When a seller sends you a backtest, ask for the journal that produced it, and then check that the two describe the same test. A folder with a report and a log in it is not evidence until something in the log names the trades in the report.
Every verdict lamp in the catalog is public on the audit pages. Your own tester report? The browser check is free.