The question in a review is almost never whether the strategy is any good. It is narrower and much harder to answer after the fact: what exactly did you run, on what data, on what date, and what else did you try before you kept this one. A desk that can produce that in an afternoon has a process. A desk that reconstructs it from memory and a spreadsheet has an anecdote, and the reviewer can tell the difference within about two questions.
The awkward part is that most of the material is cheap to capture at the moment of the run and expensive or impossible to recover later. So the evidence file is not a documentation exercise you schedule for the end of the project. It is something you write while the run is going.
A relative window is not a reproducible one
Start with the artefact people assume is free, which is the dataset. On Autopilot, the Backtest a Profile panel takes a profile, a number of days, and a start equity, and it replays historical signals against the profile with no real orders placed. The days field is the one to look at hard. A window expressed as a number of days is anchored to the date you pressed the button, which means the same input reproduces a different test every time it is used.
A run of 180 days executed in March and the same run executed in June are two different experiments with identical parameters. If your file records only the parameters, you have recorded the thing that stayed the same and omitted the thing that changed. Write the run date and the resulting window explicitly, as absolute start and end dates, in the file. It is one line and it is the line that makes everything below it checkable.
The same logic applies to the signal history itself. The replay uses historical signals, and a signal history is a live database that grows and can be corrected. Note the run timestamp to the minute, and note anything you know about the state of the underlying feed, including whether the instrument list has changed since. If you cannot vouch for the immutability of the source, say so in the file rather than letting the reader assume it.
The parameter set lives on a mutable object
The panel states that the replay honors all filters, sizing, leverage caps, and risk guards. That is a good property for the test and a hazard for the record, because it means the experiment is defined not by what you typed into the panel but by the state of the profile at the instant the run executed. Profiles are editable. The one on screen today is not necessarily the one that produced the result you are quoting from six weeks ago.
So capture the full parameter state alongside the run, not a reference to the profile name. Name, and then every setting that was live: entry source and any per source rules, filters, position sizing rule, leverage cap, each risk guard and its value, stop and trailing behaviour, and any partial take profit levels. Autopilot describes trailing stops and partial take profits as part of what a profile can carry, so anything you leave out of the capture is something that silently varied between runs.
I cannot tell you from the panel whether the platform stores a versioned snapshot of the profile with each backtest run, and this is precisely the kind of assumption that should not be made on faith. Find out before you rely on it. If it does not, then the export is your job, and the operating rule is simple: no result enters the file without its parameter block attached, and a result whose parameter block is missing is deleted rather than caveated. Caveated numbers survive into decks.
Rejected variants are the evidence, not the one you kept
This is the artefact desks most often fail to produce, and it is the one a reviewer is genuinely probing for, because it is the only thing that distinguishes a tested strategy from a selected one.
Every run you performed and discarded belongs in the file with the same fields as the run you kept: parameters, window, start equity, result, and one line saying why it was rejected. Not a summary of the search. Each run. The count matters, because a parameter set chosen as the best of forty attempts on the same window carries a very different expectation than one chosen as the best of three, and the reviewer cannot adjust for a search whose size you did not record.
The rejection reason is where honesty is cheapest and most valuable. There is a real difference between rejected because it broke a risk constraint, rejected because the logic was wrong, and rejected because the number was worse, and only the last of those is a selection decision that eats into the credibility of the survivor. Writing the true reason costs nothing at the time and is unreconstructable later.
Two operational rules make this stick. Log the run before you see its output, so the file cannot be curated by outcome. And keep runs from the exploratory phase, including the embarrassing ones, because a file that contains only well behaved experiments is evidence that the file is being edited.
Where the file lives and what shape it takes
Keep it outside the platform, in whatever system your firm already uses for immutable records, and make each run a row rather than a document. The fields that make it work in review: run id, run timestamp, absolute window start and end, profile name, parameter hash or full parameter block, start equity, instrument universe as of that date, headline result, trade count, kept or rejected, rejection reason, and who ran it.
Trade count deserves particular emphasis because it governs how much weight any row can bear. A result from a run with thirty trades and a result from a run with three hundred should not appear in the same column without the count beside them, and a reviewer who sees counts in the file will trust the rest of it more than one who has to ask.
Store the run's own trade list too, not just the summary. Summaries are what get argued about. A trade list is what settles it, and it is also what you will need when live results start diverging and someone asks whether the divergence is execution or selection.
The paragraph about unattended operation the file must contain
An evidence file for an automated profile is incomplete without a section describing what happens when nobody is watching, because that is the question the reviewer arrives with even if they phrase it as something else.
Autopilot is explicit on the same screen that when paper mode is off it places real orders on connected exchanges, that execution prices may differ from signal prices because of market conditions and latency, and that the user is solely responsible for the trades. It offers a global emergency kill switch and pause and resume controls at the fleet level, and the recommended sequence is to start in paper, verify behaviour, then go live with small sizes. Record that you followed that sequence, with the paper period dates and the size you went live at.
Then write the failure mode down in your own words, because a backtest documents intent rather than operation. The replay places no orders, so it cannot tell you what a stale feed, a rejected order, a venue outage, or a gap through a stop does to this profile. Name who holds the kill switch, what triggers its use, how quickly they can reach it outside business hours, and what the profile does to open positions when it halts. If you have not tested the halt on a live profile with a position open, the file should say that, and the review is the correct place to find out rather than the incident.