Direct Answer
An experiment registry template is a structured log for recording each trading-research iteration, hypothesis, method, data sources, metrics, and outcome, before the result is known. Logging the hypothesis and success criteria in advance prevents HARKing (hypothesizing after results are known) and keeps a rejected idea from being silently dropped from the record. Over time, the registry becomes an audit trail showing a strategy's edge was found through disciplined testing rather than curve-fitting.
Tool
Identity
Hypothesis & Mechanism
Data & Method
Pre-specified Metrics & Thresholds
Results (fill after backtest; skip if filing pre-test only)
Nothing is stored or transmitted. Registry lives in your browser session only, use Export to save it. Disclosure.
No entries yet. Add your first research iteration using the "Add Entry" tab.
Export the complete registry as plain text for pasting into a Markdown file or committing to git.
How to use this registry
The registry is an in-session table of research iterations. Each row represents one experiment, one hypothesis tested once against one dataset configuration. The registry tracks the full lifecycle of each experiment: from the pre-test protocol (hypothesis, method, data, pre-specified metrics) through to the post-test result and the promote/revise/reject decision.
The intended workflow is to add a pre-test entry (entry type: "pre-test") before running the backtest, with the results fields left as "pending," then return to the registry after the backtest runs and add the post-test result as a separate entry (entry type: "post-test") referencing the same research line and the next iteration number. This two-step discipline, one entry before analysis, one after, is the core of preregistration-style research logging.
Use the Export tab to generate a plain-text version of the complete registry. Paste this into a Markdown file, commit it to git with a message like "Update experiment registry through 2026-08-07," and the git commit timestamp provides a tamper-evident record of when each entry was filed. The combination of pre-test commit timestamps and post-test commit timestamps is what makes the log meaningful as a safeguard against HARKing.
Entries are stored in your browser session only and are cleared when the page is closed. There is no server-side storage. Copy or export your registry before closing the tab.
What each column means
- ID / Iteration: A unique identifier for the entry, auto-generated if left blank, plus the iteration number within the research line. Together these allow you to trace a research line across multiple iterations without ambiguity.
- Type: Pre-test entries are filed before the backtest runs. Post-test entries log results. Exploratory entries record analysis done without a prior pre-test protocol, important to distinguish, since exploratory results require a new pre-test protocol before acting on them.
- Decision: Promote (strategy meets criteria and will be forwarded to paper trading or live consideration), Revise (strategy shows signal but did not meet pre-specified criteria, a new hypothesis must be written), Reject (strategy does not warrant further investigation, entry archived), or Pending.
- Threshold met: Whether the observed primary metric value cleared the pre-specified success threshold. "Partial" is for cases where the metric cleared but a pre-specified robustness check failed, a common scenario that should default to Revise, not Promote.
- Git commit: The short commit hash of the analysis code run for this iteration. Combined with the data checksum. This is sufficient for later reproducibility verification.
A Log Is Only Useful If It Records the Failures
A registry earns its keep on the entries nobody wants to make. Recording the ideas that worked is pleasant and largely redundant, since successes get remembered anyway. Recording the ones that failed, and the variations tried before something worked, is what makes an eventual success interpretable, because the number of attempts behind a result is part of the result.
The discipline that makes it real is entering the hypothesis and the success criterion before the test runs. A row completed afterwards records what was found rather than what was sought, and those are not the same document even when the wording looks similar.
The failure mode is a log that decays into a formality. Entries that are vague, batched, or written from memory at the end of a week supply the appearance of process without its function, and it is worth noticing when that has started to happen.
A registry documents. It does not evaluate, and a thoroughly logged programme of weak ideas remains a programme of weak ideas.
Frequently Asked Questions
Why do I need both a Protocol Generator and a Registry?
The Protocol Generator produces the pre-test document for a single new experiment, the detailed specification written before analysis runs. The Registry provides the running cross-experiment ledger: a table that lets you see all iterations in a research line, their decisions, and how many tests have been run. Together, the per-protocol detail and the cross-protocol registry give you both the depth of preregistration and the breadth tracking that drives Bonferroni adjustment calculations.
Should I add one entry per backtest run or one per hypothesis?
One entry per distinct hypothesis tested. If you run the same hypothesis on different data splits as a robustness check. That is one entry with multiple robustness check results, not multiple entries. If you materially change the hypothesis (different signal, different universe, different entry rule). That is a new entry and a new iteration number. The purpose is to count distinct claims about the world, not distinct code runs.
What does "exploratory" entry type mean for my research discipline?
Exploratory entries represent research done without a pre-test protocol, you analyzed the data before specifying what you were looking for. These results can be informative and are worth logging, but they carry less evidential weight than confirmed pre-test/post-test pairs. The key discipline: an exploratory result that looks promising must generate a new pre-test protocol entry before being taken seriously. You cannot retroactively convert an exploratory entry to a pre-test entry.
How do I handle a strategy variant that is mostly the same but with one parameter changed?
If the parameter change was pre-specified as a sensitivity/robustness check in the original protocol, log it as part of that entry's robustness check results, not as a new iteration. If you changed the parameter in response to seeing the original result (e.g., you varied the lookback period because the default lookback underperformed). That is HARKing, the new variant must be a new pre-test entry, not retrofitted into the original. When in doubt, new entry.
My registry was cleared when I closed the tab. How do I prevent this?
Use the Export tab to generate a plain-text copy of the registry before closing. Paste it into a .md file in your research folder and commit it to git. For ongoing use, keep the file open in a tab and export at the end of each research session. The browser-session-only storage is intentional, the registry is a staging area for generating the export, not a permanent database.
What should be recorded when an experiment is abandoned partway through?
The entry stays, with the reason for stopping and how far it got. Abandoned attempts are part of the search history, and deleting them makes the surviving entries look like the whole of what was tried. The distinction worth capturing is whether the run was stopped for a reason unrelated to results, such as a data problem or a coding error, or because early output looked unpromising. The second case is a selection decision and counts toward search breadth.
How should the registry handle an idea that came from reading someone else's published result?
Record the source alongside the hypothesis. An idea taken from published research arrives with a search history you did not run and cannot see, and the published version has already survived whatever selection produced it. Noting where it came from keeps that context attached, and it makes a later out-of-sample failure interpretable: the strategy may work as described on the original data and period while not generalizing to yours.
Should the registry record which results were shown to other people?
It is worth a column. Once a result has been presented, discussed or circulated, there is social pressure attached to the conclusion that was not there before, and subsequent revisions are more likely to defend it than to test it. Knowing which entries crossed that line helps explain, later, why a particular strategy received more forgiving treatment than a comparable one that stayed private.
How long should registry entries be kept?
Longer than the project, because the reason for keeping them is cumulative search breadth rather than the individual test. Entries from previous years are what tell you how many ideas have been run against the same dataset, which is the figure that should be inflating scepticism about the current result. Archiving by year keeps the working view manageable without discarding the history that makes the count meaningful.
References
- CFA Institute Research and Policy Center: Quantitative research methodology and reproducibility standards
- NBER: Empirical finance research on data mining, multiple testing, and result reproducibility
- SSRN: Financial economics research repository, including pre-registration and open-science practices for quantitative research
Educational Disclaimer
This tool is for educational and research organization purposes only. It does not constitute investment, financial, or trading advice. No data entered is stored or transmitted by Swoopr Investment. The registry is cleared when the browser tab is closed. Trading involves significant risk of loss.