Research Trail began with a different version of the same problem: too much of the logic of an investigation can exist only in the researcher’s head. A paper may eventually present a research question, hypotheses, methods, findings and claims in a coherent order, but the investigation that produced them is rarely so linear. A source changes the question. An analysis undermines an assumption. An unexpected result generates a new hypothesis. An AI system proposes an explanation that the researcher later rejects. A claim in the final paper may have a long ancestry, yet reconstructing that ancestry months later can require searching through notes, drafts, code, references, conversations and memory.
Research Trail is an experimental open research tool for making those consequential relationships explicit while the work is developing. Its purpose is not to record every thought a researcher has. It is to reduce the amount of important methodological information that must be remembered implicitly, and to create a structured record that can be inspected, revisited and extended.
The methodological argument behind this approach is developed in How Do You Document How a Research Idea Became a Scientific Claim?. Research Trail is our attempt to operationalize part of that argument.
The published paper is not the investigation
Scientific writing necessarily compresses. A reader needs a coherent account of what was studied and what the evidence supports, not a transcript of every detour. The difficulty is that compression can also erase distinctions that matter for understanding how a claim developed. A hypothesis that existed before analysis is not temporally equivalent to one generated after an unexpected result. A proposition suggested by an AI system has a different provenance from one derived from a cited theory, even though neither origin tells us whether the proposition is true. A source may have supplied background, contradicted an assumption, provided a method or directly supported a claim; the fact that all four appear in the reference list does not preserve those different roles.
Researchers often have pieces of this history in notebooks, reference managers, preregistrations, Git commits, analysis scripts, spreadsheets, drafts, emails or AI conversations. What is frequently missing is an explicit representation of the relationships among those pieces. Research Trail is designed around those relationships.
Following an idea through an investigation
Imagine that a researcher begins with an observation: two groups appear to respond differently to the same environment. At that point, the observation is not yet an explanation. Reading the literature suggests one possible mechanism, which becomes a tentative hypothesis. An analysis produces a pattern consistent with that hypothesis, but it also exposes an alternative explanation. The researcher revises the hypothesis, derives a more specific prediction and later tests it with different data. By the time the work is written up, a claim may be defensible, but the final claim is not the same object as the observation that started the investigation.
During active research, the researcher often knows this ancestry without writing it down explicitly. They remember which source prompted the first explanation, which result was unexpected, when the alternative hypothesis appeared, and which later evidence changed its status. The problem appears when those relationships have to be reconstructed from artifacts created for different purposes: notes, references, scripts, drafts, preregistrations, conversations and perhaps several AI interactions.
Research Trail treats consequential elements of an investigation as objects that can be related to one another. A question can be prompted by a source. A hypothesis can emerge from that question. A prediction can test the hypothesis. An analysis can produce a result that supports, contradicts or complicates it. A finding can contribute to a claim. If the status of an idea changes, the earlier state does not have to disappear simply because a later one exists. The purpose is to preserve the development of the idea, not merely its final label.
Provenance and evidence are not the same thing
This separation is one of the most important design principles in the tool. Knowing where an idea came from tells us something about its provenance; it does not establish its evidential status. A proposition suggested by a researcher, collaborator, paper, reviewer or AI system still has to be evaluated on the basis of appropriate evidence. Recording an origin should therefore make the research history clearer without conferring scientific authority on that origin.
The same principle applies to AI participation. A generic disclosure that “AI was used” can hide very different activities. An AI system might suggest search terms, propose a hypothesis, generate code, criticize an argument, classify material or offer an interpretation. Research Trail is intended to let those interventions be recorded at the point where they matter, together with what the researcher subsequently did with the output. The aim is attribution and inspectability, not automated validation of AI-generated content.
A common record for research that is not itself uniform
Research is too heterogeneous to force into a single rigid sequence, and that is not what Research Trail is trying to do. The standardization we are interested in is more modest: recurring distinctions can be recorded consistently enough that the resulting trail remains understandable. What kind of object is this? Where did it come from? When did it enter the investigation? What does it relate to? What is its current status? What changed it?
Those questions can be useful across very different kinds of work even when the answers differ. A theoretical investigation, secondary analysis, empirical study and methodological project may not share the same design, but each can contain questions, assumptions, sources, decisions, analyses, findings and claims whose relationships matter. The structure is there to reduce memory burden and improve inspectability, not to pretend that every research programme follows the same path.
Why temporal status matters
An idea can change scientific roles over time. Something that begins as a question may become a conjecture; a conjecture may become a hypothesis; a result may generate a new exploratory hypothesis; later work may test it prospectively. If only the final label is preserved, the chronology disappears. Research Trail therefore treats temporal status as information worth keeping rather than something to reconstruct at publication.
This is complementary to preregistration. Preregistration can preserve what was planned at a defined point in time. A research trail can preserve consequential developments around that point: what existed beforehand, what changed afterward, which analyses were exploratory, and how later claims relate to those developments. This is relevant to concerns raised by the HARKing literature, but the purpose is not to stigmatize exploration. It is to make the difference between planned and emergent work visible.
What becomes possible when the trail survives
A structured trail has value even before anyone else audits it. The original researcher can return to an old project and recover why a decision was made. A collaborator can understand the state of an investigation without relying entirely on oral explanation. When a claim is challenged, the team can trace backward through the findings, analyses, assumptions and sources that contributed to it. When a later study changes the interpretation, the earlier reasoning can remain visible instead of being silently rewritten by hindsight.
This does not make the science correct. A perfectly preserved chain of reasoning can still contain weak assumptions, poor measurements or invalid inferences. Integrity of the record and validity of the science are different properties. The value of the record is that it makes more of the work available for inspection and criticism.
What Research Trail currently does
The current alpha focuses on recording and connecting research objects such as questions, assumptions, hypotheses, predictions, sources, analyses, findings, interpretations and claims. It can distinguish provenance from evidential status, preserve temporal information, record typed relationships among entries, and represent AI or external tools as contributors to specific activities rather than as an undifferentiated disclosure.
The model is deliberately still developing. We do not want to invent an isolated vocabulary where established semantic frameworks already provide useful concepts, nor do we want to force equivalence where the meanings do not align. Future interoperability work should therefore be based on careful mappings rather than on renaming existing ideas.
Built in conversation with existing provenance work
Research Trail is not presented as the first attempt to model scientific provenance or argument. Its development is informed by W3C PROV for entities, activities, agents and derivation; SWAN for scientific discourse and evolving research objects; Micropublications for claim-evidence and argument structures; CiTO for typed citation intentions; and Nanopublications for bounded assertions with provenance and publication information. These approaches solve different parts of the problem. Our interest is in how a researcher-facing workflow can make useful parts of that structure practical during live research.
What Research Trail does not establish
Research Trail does not prove that a claim is true, turn a timestamp or hash into scientific validity, replace preregistration, infer undisclosed AI use, or require every thought and conversation to be recorded. It also does not claim to have invented provenance, hypothesis tracking, evidence graphs or citation semantics. The narrower proposition is that recording consequential research objects, their provenance, their temporal status and their relationships prospectively may make the development of research easier to reconstruct and inspect. That proposition should itself be tested.
Why we are releasing it openly
Research Trail grew out of the way our own investigations were becoming harder to reconstruct as questions, sources, analyses and AI-assisted work accumulated across different places. Building a private solution would have addressed the immediate organizational problem, but not the broader methodological one. If the structure is useful, other researchers should be able to inspect it, challenge it, adapt it or decide that a different structure works better.
This reflects the same principle behind our other research tools: software should not replace scientific judgment, but it can reduce how much of the scientific process depends on undocumented memory. Where recurring parts of research can be externalized without pretending that research itself is mechanical, we want to explore whether doing so makes the work more transparent, reusable and open to scrutiny.
Use Research Trail
If you want the methodological argument without using the software, read How Do You Document How a Research Idea Became a Scientific Claim?. The current alpha is available as Research Trail on Hugging Face, and the source and development record are available in the Research Trail repository on GitHub.
Like the research it is intended to support, the tool is not finished. We expect its categories, relationships and workflows to change as they encounter real investigations. Keeping that development visible is part of the experiment.
