A trial-registry record may contain results and dates without making it immediately clear when those results became publicly visible. An attempt to submit results and a state containing the results tables are different things. We also need a rule for dating the change. Those questions come before comparing the records.
I designed a framework for reading ClinicalTrials.gov histories that separates state, clock and anchor. Even with the same records, we can choose different observable states, assign different dates to events, and use different reference points for comparison. I made those choices explicit in a state–clock–anchor audit, preparing the manuscript and supporting materials around them.
Keeping three choices separate
A state describes what is present in a registry record at a given point. I distinguished a results-submission attempt from a state in which results content was actually present. Instead of relying on a “has results” flag alone, the audit defines the observable posted-results state by the presence of content in that version’s results section.
The clock is the rule used to assign a date to a change. The anchor determines the reference against which that date is compared. I distinguished a reference taken from the first posted-results record from one taken from a later record, crossing the clock and anchor choices in the comparison. Changing both together should not leave us attributing the resulting difference to only one of them.
The purpose is to examine what a measurement made from registry records actually represents. A visible change in a record does not by itself establish a legal breach or a researcher’s intent. I framed the audit around choices in representing and comparing the records.
Releasing the reproducibility materials separately
On 29 August 2026, I released reproducibility materials v1.0.0 on Zenodo. The package brings together retrieval, reconstruction and analysis code, derived data, figure inputs, tests and instructions. I also retained a retrieval manifest and file hashes so that the inputs can be traced. A hash provides a value for checking whether file contents have changed.
The bulk archive of raw history responses is not redistributed in that package. Tests and figure generation can run from the distributed materials, but reconstructing the complete histories from the same inputs also requires raw files matching the recorded hashes. A later retrieval from the site is not guaranteed to match those preserved inputs. I therefore distinguished the availability of code from the conditions needed to replay the analysis on identical source data.
TrialTrace: exploring the changes in a trial record
I built TrialTrace to make these record histories easier to inspect, releasing the code on 14 September 2026. It uses the reproducibility materials described above and covers 5,629 reconstructed transitions between versions of 400 trial records. These counts describe the bundled corpus, not all of ClinicalTrials.gov or the current state of its records.
Enter an NCT identifier, the registry’s identifier for a trial, to follow version dates and changed fields in a timeline, then open the official history page to check the source. I included a retrieval manifest and file hashes so that readers can trace the inputs behind the comparison. The tool distributes derived tables and selected provenance information, not the bulk archive of raw history responses.
The code runs locally in a Python environment and provides a search interface and API. Database construction checks file hashes and corpus counts; the repository also includes tests and automated checks. This release reads a frozen corpus. It does not monitor live records or determine why a registry field changed.
To try it, use Python 3.11 or later and follow the local setup instructions, then open http://127.0.0.1:8000. Search for NCT04153409, the example in the usage guide, inspect its dates and changed fields, and follow the result to the official history.
If you get stuck during setup or a comparison, email me the step and what you were trying to check. Include only error details and environment information that are safe to share.
On the same day, the project met the OpenSSF Best Practices Passing criteria. This is a project self-certification supported by evidence about development, testing and security practices, not an independent security audit or a guarantee that the software has no vulnerabilities.
The dataset release and the manuscript
I submitted the manuscript to a journal on 30 August 2026 and received a submission receipt. I am also continuing to reassess the research’s structure and next route. The reproducibility DOI identifies the released dataset package; it is not an acceptance or a journal version of record.
The detailed research findings remain for an account after a live journal version of record and active DOI are available. This note does not disclose unpublished counts or conclusions, review correspondence or manuscript identifiers.
The question is how clearly we can state the conditions of comparison before interpreting the records. Keeping state, date and anchor separate lets another reader return to those choices when examining the same registry history.