How to prove when a result was produced
4 min read
Auditable, reproducible research records are important, and provenance matters. Cryptographic hashes and commit identifiers help bind a result to an exact artifact and code state, and later rehashing can reveal tampering.
A timestamped research record is evidence that a specific result existed in a specific form at or before a recorded time. The usual mechanism is to compute a cryptographic hash of the result and store that hash in a record that is hard to alter without leaving evidence. If the result changes, its hash changes. If the record is publicly visible or independently controlled, later verification can show whether the current file still matches the earlier record.
A cryptographic hash is a short fingerprint derived from data. In practice, a researcher can hash a result file, a report, a notebook export, or a source control commit identifier. The important property is determinism. The same input produces the same hash, and even a small change in the input produces a different hash. That makes the hash a compact way to anchor the exact contents of a result without publishing the full file.
The Sonar Sciences research workflow describes a progression from research to publishing that emphasizes preserving research artifacts and making methods reviewable. Research outputs should be auditable and reproducible. The backtest overfitting audit tool is presented as an audit-oriented mechanism for examining research results, and the glossary entry on the deflated Sharpe ratio explains why raw performance summaries are not enough when many trials or selection effects are involved. Provenance is part of research integrity. A result should be accompanied by artifacts, definitions, and checks that allow another person to inspect what was produced and how it was derived.
Within that supported scope, a practical timestamping workflow can be described at a high level. First, freeze the research artifact you want to preserve, such as a result file or a commit snapshot. Second, compute a cryptographic hash of that artifact. Third, record the hash together with contextual metadata such as the strategy name, dataset version, code revision, and the time of recording. Fourth, retain the original artifact so that it can be hashed again later. Fifth, when verification is needed, recompute the hash from the preserved artifact and compare it with the recorded value. A match shows that the artifact has not changed since the record was created. A mismatch is tamper evidence because it shows that the current artifact is not identical to the one that was originally recorded.
A commit hash fits naturally into this model. Source control systems identify a specific state of the repository with a content derived identifier. If the repository state changes, the identifier changes. Recording that identifier alongside the generated research output links the result to the exact code state used to produce it. That does not by itself prove when the code state first existed in an immutable public ledger, but it does strengthen internal provenance by tying the output to a reproducible code snapshot.
Third party timestamping and public ledgers are stronger forms of anchoring because they place the recorded hash outside the sole control of the researcher. In principle, that can reduce disputes about whether a local timestamp or internal database entry was altered after the fact.
Hash based records are useful for proving that a preserved artifact matches an earlier recorded fingerprint. Audit and review oriented workflows make those records more valuable because they connect results to methods and code states.
Drafted with AI assistance from cited sources. Reviewed and approved by Sonar Sciences Quant & Research Team.