Every signal vendor that has been running long enough publishes some form of historical performance, and the Market Reversal Engine lists historical signal performance among its delivery features alongside the live dashboard and the alert channels. Allocators tend to open that view first and read the summary statistics. That is the wrong order, because summary statistics are the last thing you can evaluate and the first thing that can be constructed.
The productive sequence starts with the plumbing. Before any performance number means anything, three separate properties have to hold: the population is the one that was actually observable at the time, the record has not been rewritten since, and the timestamps place each event where it really happened. Those are testable. The Sharpe ratio is not, at least not until they are.
Reconcile the counters before you open the history
The header of the live view carries the cheapest integrity test available, and it costs a minute. At capture the setups tile read 2 in the last 24 hours, with 30.3 per day quoted as the 7 day average directly underneath it. Overbought in 24 hours read 2 and oversold read 0. Tickers covered read 4 over the last 30 days. The archive control showed 100 of 3,022.
Do not read that 2 against that 30.3 as a fifteenfold collapse in signal production. It is not usable as a result, and treating it as one is the mistake this section exists to prevent. There are at least four ordinary explanations and the panel does not tell you which applies. The two tiles may count different populations, one deduplicated and one raw. The 24 hour window may be a rolling window while the average is computed over calendar days. The daily distribution may be heavily clustered, in which case a mean of 30.3 is compatible with a modal day near zero. Or the day was quiet.
The point of the exercise is not to resolve it from the outside. It is that you should resolve it, in writing, with the vendor, before you cite any count in a memo. A desk that cannot explain the relationship between two numbers on the same header strip has no business quoting the third.
Note the coverage line specifically. Tickers covered reads 4 over the last 30 days, while the stated coverage universe spans Bitcoin, Ethereum and Solana plus the S&P 500, the Nasdaq 100, the Dow and blue-chip names. Those two statements are not in conflict. A coverage universe is what the engine watches and the tickers-covered figure is what actually produced signals in a window. But if your evaluation of the history implicitly assumes the universe was live throughout, you are evaluating a different product from the one that generated the rows.
The three doors survivorship comes through
Survivorship in a signal archive is not the equity-index version everyone learned. It arrives by three specific routes and each needs a separate question.
The first is instrument disappearance. Crypto pairs get delisted, renamed, redenominated and migrated between venues. If rows referencing instruments that no longer trade have been dropped from the archive rather than retained with a status flag, the surviving record is biased toward assets that persisted, and persistence is correlated with everything you care about.
The second is universe drift. If coverage expanded over time, the early history was produced by a narrower engine than the one you are buying. Ask for the coverage universe as a dated series, not as a current list. A vendor who can produce that has probably thought about the rest of this too.
The third is the quiet one, which is row-level curation. Any archive that supports deletion supports selective deletion. You cannot test for this from the outside at all, which is why the only real control is your own captured copy of the feed accumulated forward from the day you start diligence. Six weeks of independent snapshots is worth more than any assurance, and it costs a scheduled job.
Restatement is an engineering fact, not an accusation
Historical data changes for legitimate reasons. Backfills complete, deduplication logic improves, a scoring bug is fixed and the affected rows are recomputed. All of that is normal, and all of it silently invalidates a memo that quoted the previous version.
The test is simple and belongs in your process rather than in a questionnaire. Hash each archived row across its meaningful fields at ingest, store the hashes with your own receipt timestamp, and re-pull a fixed slice of history on a schedule. Diff. What you are looking for is not the presence of changes but their character: silent in-place edits to rows you already analysed are a different governance risk from an appended correction with a version marker.
Ask the vendor two questions with specific answers. Are historical rows ever modified after publication, and if so, is there a version or revision marker on the row. If the answer to the first is no, your own diff will confirm or refute it within a quarter at no cost. If the answer is yes with a marker, that is the better answer, because it is the one you can build reconciliation around.
Timestamps are where look-ahead hides
The Time column in the live feed resolves to the second. What it does not display is a timezone, and until that is pinned every temporal analysis you run on the archive is provisional. Establish it once and document how.
Then separate two things that a single column conflates. The moment the signal was computed and the moment it became available to a subscriber. The product states that scoring updates on every supported timeframe close and that signals surface in the live feed within seconds of computation, then go out by email, Discord and Telegram. If the stored stamp is the computation moment, then any backtest that assumes execution at that stamp has helped itself to the delivery interval, and on a scalp-class signal that interval is not negligible relative to the trade.
The third timestamp question is the one that catches genuine problems. Are the archived stamps derived from the bar close, or from the wall-clock at write time. Bar-close derivation is cleaner but it can hide a pipeline that ran late, presenting a signal as though it existed at a moment when nothing had yet computed. The reconciliation is your own capture log: your receipt time for a row should never precede the vendor stamp by any amount, and if it ever does, that finding outranks everything else on this page.
What a clean archive can and cannot settle
Suppose all of the above comes back well. The population is dated, the rows are immutable or versioned, the clocks are pinned. You still do not have a track record in the sense an investment committee means, because the archive records signals rather than positions, and the distance between the two is entry assumptions, exit assumptions, sizing, costs and the small matter of which signals a human would actually have taken.
What you have is something more useful than it sounds: a defensible event set. Every performance figure downstream is now yours, computed under assumptions you wrote down, on a population you can date and reproduce. That is the artefact to put in front of the committee. A vendor-computed return series, however good, is a number whose construction you cannot inspect, and the correct treatment of such a number in diligence is to note that it exists and then not rely on it.