How Can I Ensure My Data Remain Understandable Over Time?
Why future you will thank present you
Many people assume that they will remember the details of their data collection, analysis and decision-making processes. In practice, memory is unreliable, and details can be forgotten surprisingly quickly (Schacter, 2021; Schacter, 2001).
The challenge is not that researchers do not care about documentation. Rather, documentation often competes with many other responsibilities. Researchers may be collecting data, analysing results, writing papers, preparing grant proposals, teaching, supervising students, attending meetings and dealing with administrative tasks. When time is limited, documentation can easily feel like something that can be done later.
A dataset that seems perfectly understandable today may become much more difficult to interpret a few months later. Variable names that once seemed obvious, undocumented assumptions, processing steps and methodological decisions can all become difficult to reconstruct over time.
Imagine returning to a water quality dataset six months after the last field campaign. The dataset contains measurements from three sampling sites labelled:
Site_A
Site_B
Site_C
At the time, everyone in the project knew that Site_A referred to the upstream location, Site_B to the agricultural area and Site_C to the river mouth. But, six months later, without additional documentation, that information is nowhere in the dataset and must be reconstructed from memory.
The challenge becomes even greater when projects evolve, researchers leave a team or data are reused for a new purpose.
Good documentation is not only for collaborators, reviewers or future users. It is also for the researchers who created the data. Researchers are often the first people who need to understand and reuse their own data months or years later.
For this reason, it is usually more effective to document information as it is created. Small updates made throughout a project are often easier and more accurate than trying to recreate everything at the end.
For example, researchers can:
- Update a README file when new files are added.
- Document new variables when they are created.
- Record important decisions when they are made.
- Note changes when a dataset is updated.
Documentation does not need to be perfect from the beginning. What matters most is developing a habit of recording information while it is still fresh and easy to remember.
A few minutes spent documenting work today can save hours of confusion later.
Future you will thank present you.
Write README files
One of the simplest and most effective ways to document research data is to create a README file.
A README file provides an overview of a dataset, project folder or collection of files. It helps researchers understand what the data are, how they are organised and where to find additional information.
For example, imagine opening a project folder six months after a water sampling campaign. The folder may contain several files:
Water_Samples_Raw.csv
Water_Samples_Cleaned.csv
Sampling_Locations.csv
Laboratory_Results.xlsx
Without documentation, it may not be immediately obvious:
- Which file should be used for analysis.
- How the files relate to one another.
- What processing steps have been applied.
- What abbreviations or codes have been used.
- Where additional documentation can be found.
A README file can answer these questions in a single place.
README Files Can Be Simple or Detailed
For personal use or small projects, a README file may only contain a short description of the dataset, the purpose of each file and an explanation of any naming conventions, abbreviations or codes.
For example:
Dataset: Water quality monitoring campaign
Water_Samples_Raw.csv
Raw measurements collected during field sampling.
Water_Samples_Cleaned.csv
Data after quality control and removal of invalid measurements.
Site codes:
A = Upstream site
B = Agricultural site
C = River mouth
For larger projects or datasets intended for sharing, a more comprehensive README may be appropriate. These often include information such as:
- Dataset title and description.
- Researchers and contact information.
- Dates and locations of data collection.
- File and folder descriptions.
- Methods used to collect or process the data.
- Version history.
- Licences and access conditions.
- Links to related publications or protocols.
Many repositories and data archives encourage or require README-style documentation when data are shared. Creating and maintaining a README throughout a project can therefore support both day-to-day work and future data sharing.
Practical Tips
- Create a README file as early as possible.
- Update it whenever important changes occur.
- Store it alongside the data it describes.
- Use non-proprietary formats such as
.txt,.md(Markdown) or PDF where appropriate. - Use consistent date formats such as
YYYY-MM-DD.
Further Readings
Cornell University Research Data Management Service Group. Writing READMEs for Research Data. Licence: CC BY 4.0
Kozlowski, Wendy. (2025). README Template for Data. Licence: CC0
Documenting variables and codes
Even when the purpose of a dataset is clear, researchers still need to understand what individual variables, codes and values mean.
For example:
- What does M mean?
- Does 1 mean Yes and 0 mean No, or vice versa?
- Are dates recorded as DD/MM/YYYY or YYYY-MM-DD?
- What units were used for measurements?
Without documentation, these details can be difficult to remember and may lead to misunderstandings or errors during analysis.
A good practice is to document:
- The meaning of each variable.
- Units of measurement.
- Allowed values or categories.
- Missing value codes.
- Abbreviations and acronyms.
- Any calculations used to derive variables.
This type of information is often recorded in a data dictionary or codebook. Although the names vary between disciplines, the purpose is the same: to help researchers understand exactly what the data mean and how they should be interpreted.
Recording decisions and changes
Research data are rarely collected and analysed exactly as originally planned. Throughout a project, researchers make decisions that can affect how data are interpreted and used.
For example:
- Certain observations may be excluded from the analysis.
- Errors may be corrected.
- Variables may be renamed or transformed.
- Data cleaning procedures may be applied.
- New versions of a dataset may be created.
Although these decisions may seem obvious at the time, they can be difficult to remember later, particularly in long-running or collaborative projects.
A good practice is to keep a record of important decisions and changes as they occur. It is not versioning itself, but the reasoning behind changes.
This does not need to be complicated. A simple document, spreadsheet or project log may be sufficient.
For each change, it can be helpful to record:
- What changed.
- When it changed.
- Why the change was made.
- Who made the change, if multiple people are involved.
For example:
| Date | Change | Reason |
|---|---|---|
| 2026-05-14 | Removed 12 duplicate records | Data entry error |
| 2026-06-02 | Corrected sampling site coordinates | Incorrect GPS values recorded |
| 2026-07-10 | Added calculated nitrate concentration variable | Required for analysis |
Keeping a record of important decisions helps researchers understand how a dataset evolved over time and supports transparency, reproducibility and future reuse.
Data about data
So far, we have discussed documentation stored alongside research data, such as README files, data dictionaries and project notes.
However, some information can also be stored directly within the data file itself. This information is known as metadata, often described as "data about data".
Metadata can include information such as:
- The title of a dataset.
- The creator of the data.
- Dates of creation or modification.
- Units of measurement.
- Geographic locations.
- Keywords and descriptions.
- Licences and access conditions.
Unlike separate documentation files, metadata are often embedded within a file, database or repository record. As a result, they can remain attached to the data when files are moved, copied or shared.
Many software applications automatically create some metadata. Researchers may also add metadata manually or through repository submission forms.
Although metadata alone cannot replace README files or other documentation, it can make data easier to find, understand and reuse.
Key Takeaways
- Documentation helps ensure that research data remain understandable and reusable over time.
- README files provide an overview of a dataset and its organisation.
- Data dictionaries and codebooks help explain variables, units, codes and missing values.
- Important decisions and changes should be recorded as a project evolves.
- Small amounts of documentation created throughout a project are often more effective than trying to document everything at the end.
References
Resources
Cornell University Research Data Management Service Group. Writing READMEs for Research Data. Licence: CC BY 4.0
Kozlowski, Wendy. (2025). README Template for Data. Licence: CC0
Research Evidence
Schacter, D. L. (2021). The seven sins of memory: An update. Memory, 30(1), 37-42. https://doi.org/10.1080/09658211.2021.1873391
Schacter, D. L. (2001). The seven sins of memory: How the mind forgets and remembers. HMH. ISBN: 0-618-04019-6
Author: Jonathan England
Created: August 2026