Pre-registration means writing down a study's method and its kill condition before anyone has seen the data, then fixing that document so it cannot be quietly revised once the results arrive. The document is a commitment, not a plan. Whatever the frozen method produces is the result, including a result nobody wanted.
Why the order matters
Market data is generous to anyone searching it after the fact. There are thousands of tickers, dozens of plausible measurement windows, several defensible ways to define an entry, an exit and a hit, and a choice at every one of those points. Make those choices while looking at the answer and a finding will turn up. Make them before, and most ideas quietly fail, which is what an honest research process is supposed to feel like.
The failure has a name in academic research: researcher degrees of freedom. Nothing dishonest has to happen. An analyst tries a 30-minute window, sees nothing, tries 15 minutes, sees something, and reports the 15-minute result because it is the one that worked. Every step was reasonable. The published number is still the best of several attempts being presented as the only attempt.
Pre-registration closes that gap by making the choices in advance and making them visible. If the frozen rule says 30 minutes, the study reports the 30-minute answer.
What a pre-registration document contains
A usable one is short and specific:
- The hypothesis, stated so it could turn out false.
- The exact measurement, including the data source, the sampling cadence and what counts as a hit.
- The window, with a start date and an end date fixed in advance.
- The kill condition, which is the result that would count as a failure. This is the part most often missing, and it is the part that does the work.
- The publication commitment: that the result is published either way.
The kill condition matters because without it, a disappointing result can be reinterpreted as inconclusive forever. Writing down in advance what would make you stop is what turns a study into a test.
Why this is not the same as a backtest
A backtest is a measurement of the past, and it is usually run many times before it is shown to anyone. That is not a criticism, it is what development looks like. But it means the published backtest is a survivor from a population of attempts nobody sees, and the number on the page does not carry the count of that population.
A pre-registered forward test is a different object. The method is fixed, then time passes, then the data arrives. There is no population of hidden attempts because the attempt was declared before the data existed.
Both are useful. They answer different questions, and combining their sample sizes into a single number misstates both.
How to check that something was actually frozen first
"We wrote the method down in advance" is easy to say. Three things make it checkable:
- A countersignature. A second party reviews the document and signs it before the window opens. A review that finds nothing is not much of a review, so the useful countersignatures are the ones that list defects.
- A record that breaks if it is edited. A hash of the document's contents is a fixed-length fingerprint: change one character of the document and the fingerprint changes completely. Chain those fingerprints so that each entry includes the previous entry's hash, and editing any entry breaks every entry after it.
- A verification anyone can run. A status badge that says "verified" is worth nothing if the same party that wrote the record also computes the badge. The check has to be runnable by the reader.
How SquawkFlow's ledger works
Each countersigned pre-registration document is recorded in an append-only file. One line per entry, and each entry holds the document's path, the SHA-256 of its contents, the size, a timestamp, the previous entry's chain hash, and its own chain hash. The chain hash is computed over the whole entry including the link backwards, so no entry can be edited, reordered or removed without every entry after it failing to recompute.
The ledger is published at /api/public/lab/ledger, and the Lab page carries the chain, its status, and the exact command that recomputes it. The command fetches the JSON, rehashes every entry with the Python standard library and stops at the first mismatch. It does not trust the page, and it does not trust the status line.
What the chain does not prove
Three limits, stated because a verification tool that oversells itself is worse than none:
It does not prove when an entry was written. The timestamp inside each entry is written by us. The chain proves the entries have not been altered relative to each other, not that any of them existed on a particular date. Proving a date without trusting the publisher needs an external anchor, such as committing a hash to a public blockchain. That is not switched on, and the Lab page says so rather than leaving the impression that it is.
It does not prove the ledger is complete. Removing entries from the end leaves a shorter chain that still verifies perfectly. A reader who wants protection against that can record the current head hash on any date and check later that the chain still contains it.
It does not say anything about the results. The ledger records what was committed to in advance. Whether a study then produced a clean answer, a null, or a mess is a separate question, answered on the Lab page next to the record itself.
The entries seeded when the ledger was created
The first entries in the ledger are marked retrospective_seed. Those documents were countersigned in August and September 2026, before the ledger existed, and were added to it afterwards using the documents as they stand today. Their entry timestamps are when the ledger entry was written, not when the method was frozen. The freeze dates are stated inside the documents themselves.
This is worth labelling rather than smoothing over. A seed entry proves that the document has not changed since it entered the ledger. It does not, by itself, prove when the document was first written. Anything frozen after the ledger existed is recorded at freeze time and carries no seed label.
What to ask of anyone publishing a record
If a service publishes a track record of any kind, the questions that separate a record from a marketing number are the same ones this page describes:
- Was the method written down before the window opened, and can you see that document?
- What result would have counted as a failure, and who decided that, and when?
- Is the sample size published next to every rate?
- Are the losing and unresolved cases in the record, or only the resolved winners?
- Can you verify any of this without taking the publisher's word for it?
A record that answers all five is rare. A record that answers none is a brochure.