Principles of an Auditable Research Record

What does it take for a third party to accept a record of predictions and judgements? This note sets out seven principles and explains how a hash chain verifies that the record has not been altered.

1. Seven principles

1. Priority in time — A third party must be able to confirm that a prediction or judgement existed before the outcome. Local file times can be changed, so an external time anchor is needed (a remote repository push time or a public timestamp).
2. Immutability — Records are append-only; a correction is a new row, never an edit of the original row. A hash chain is needed to rule out deleted rows.
3. Completeness — No cherry-picking. Every prediction and every verdict (failures included) is kept, and records transcribed by people are regularly reconciled with the source records.
4. Reproducibility — Each figure carries its input hash, code version and reproduction method, so anyone can check that the same input yields the same figure.
5. Independent verification — The maker and the reviewer are separated, and review records (who, when, what scope) are kept in a ledger of the same format.
6. Performance presentation standard — When performance is shown, use time-weighted methods, include costs, show a benchmark and the full period, and say so when the sample falls short of the standard.
7. Judgement record structure — Prediction (value, probability, deadline) / rationale / execution rule / outcome / post-mortem are kept separate, so probabilistic predictions can be scored by machine.

Number of principle items in the source analysis document: 7 (they map to the seven items of this note)

2. How the hash chain is verified (concept)

1. At each daily close, compute SHA-256 for every tracked record file and build a list of (file identifier, hash, size).
2. Row hash = SHA-256( previous row hash + recording time, market and trigger + sorted file list ). The first row's previous hash is the digit 0 written 64 times.
3. If the list equals the previous row's list, no new row is written; otherwise one row is appended.
4. A verifier recomputes the row hashes from the first row. Altering any single row breaks every later row hash.
5. Put the first 16 characters of the latest row hash in the closing commit message and push it to a remote repository; the remote time becomes the external anchor.
6. Limit: if the records and the commit messages are rewritten together and recommitted, local verification alone cannot detect it — only a remote pushed copy or a public timestamp is an anchor.

3. Current chain status

Before the first run — the chain has no rows yet (before_first_run). The row hash will appear here after the first close.