Recommended resources
The freely available resources this lesson will direct you to.
Welcome. In this module, you will examine how research records support trustworthy findings—and how gaps in those records can make a result difficult to check. This lesson focuses on the foundation: choosing practices that let you identify where data came from, follow changes to them, understand research decisions, and keep the records both secure and usable.
“Data” here means more than numbers in a spreadsheet. Depending on the project, it could include interview recordings, field notes, images, questionnaires, measurements, or computer code. The question throughout the lesson is: Could someone with appropriate access understand how the reported result was produced from the original material?
What a trustworthy record must make possible
Research data management begins before collection. You need a plan for what you will keep, where it will live, who may access it, and how you will describe it. Watch these short portions of Research Data Management 101 from UniSydneyLibrary for the scope of research data and the role of a plan. The video mentions requirements specific to its institution; treat those as examples, not rules that apply everywhere.
Watch Research Data Management 101 from UniSydneyLibrary to see why record keeping covers both physical and digital materials, and why planning should begin early.
Watch data management for the definition and examples of research data. Then watch the lifecycle and the plan. Focus on the questions a plan must answer, rather than the video's institution-specific procedures.
Four related ideas help organize those questions:
- Provenance is the origin and history of material: where it came from, who collected it, when, and by what method.
- Version history identifies successive states of a file or dataset and what changed between them.
- Decision records explain choices that affect interpretation, such as why a measurement was excluded or a coding rule was revised.
- Traceability is the resulting ability to connect a reported finding to its sources, processing steps, and decisions.
These are not four separate piles of paperwork. They are qualities of a connected record. A file named final_data.csv might contain correct values, yet tell you little about which observations it contains or how they were processed. A useful record lets an authorized reader answer those questions without relying on the researcher's memory.
At the outset, decide on a consistent folder structure, file-naming convention, documentation method, access permissions, backup arrangement, and applicable retention requirements. Revisit the plan when the project changes. A plan is valuable only if the records actually kept reflect the work that occurred.
Record collection as it happens
The first opportunity to preserve provenance is when material is created or received. Record the date, the people and roles involved, the source or subject identifier where appropriate, the method, relevant equipment or software, and observations that could affect interpretation. Record unsuccessful attempts and departures from the intended procedure too: they can explain why later records look different.
The Office of Research Integrity’s Record Keeping guidance distinguishes durable records from records that have merely been saved. Read its discussion of notebooks and electronic records, followed by its concrete recording practices.
data.pdf - The Office of Research Integrity | ORI - HHS.gov
Read the Office of Research Integrity's Record Keeping guidance for the information a record should preserve and for ways to make corrections without obscuring the original entry.
In “Record Keeping,” begin where the text discusses what records should say about data collection and amendment. Read record formats through “Electronic Records.” Then, in “Pop up Page: Best Practice Tips - Record Keeping” (p. 11), read the practical tips. Focus on what to note, how to mark an error, and how to check a transfer from paper to electronic form.
A correction should preserve evidence of the earlier entry, not silently replace it. In a paper notebook, that can mean drawing a single line through an error, then dating and initialing the change. In an electronic system, it can mean retaining the original record and using an audit log or a new, documented version. The form differs; the principle is the same: a later reader should be able to tell what changed, when, by whom, and why.
Transfers deserve particular attention. If handwritten responses are entered into a spreadsheet, transcription introduces another chance for error. The reading describes independent double entry and comparison as one way to catch discrepancies. Other projects may use different checks, but the record should establish which source was transcribed, how accuracy was checked, and how discrepancies were resolved.
Follow each change from source to finding
Collected material often needs cleaning or preparation before analysis. A researcher might standardize several spellings of the same response or mark an empty answer as missing. Such changes can be justified, but an unexplained cleaned file cannot establish exactly what happened to the originals.
Return to Research Data Management 101 for its discussion of cleaning, file names, and versions.
Continue Research Data Management 101 for practical ways to keep processed data findable and distinguish one version from another.
Watch cleaning and versions. Notice the distinction between improving consistency in a dataset and losing track of its earlier state; pay particular attention to agreed file names and revision tracking.
A workable arrangement separates original source material from processed material. Keep the original protected against accidental overwrite. Give processed files distinct identifiers, and maintain a change log or version-control history that links each version to its input. Retain the scripts or written procedures used to produce it, including software versions when they matter. A backup protects against loss; it does not, by itself, explain the differences between dataset versions.
Documentation also has different levels of detail. Knowledge clip: Data Documentation from UGent Open Science shows how a study description, a file inventory, and a description of individual variables serve different purposes.
Knowledge clip: Data Documentation
Watch Knowledge clip: Data Documentation from UGent Open Science to see how documentation at several levels makes a collection of files interpretable.
Watch study context, file structure, and item meanings. Focus on where you would record methods, relationships among files, definitions of variables, and the reasons for processing choices.
The DMPTool guidance adds concrete suggestions for organizing files and documenting what they contain. Read the indicated parts rather than treating any one naming pattern as mandatory.
Read the DMPTool's general guidance to connect consistent file organization with documentation that explains sources, methods, and transformations.
Under “Organizing Files” and “Basic Directory and File Naming Conventions,” read file organization. Under “Metadata: Data Documentation,” read “Why document data?” from why document. In “What to document?”, read project and dataset details. Finally, under “How will you document your data?”, read the README advice.
A README can explain the project, the purpose of each file, how files relate, and how to interpret them. A data dictionary or codebook can define individual fields: for example, whether 999 means “no response” rather than a measured value. Notes or scripts can document each transformation. Crucially, a decision log gives the reason, not just the operation.
For instance, imagine a survey dataset in which blank answers were recoded as missing. A useful entry would identify the input file and resulting version, the date and person responsible, the fields affected, the rule applied, and why that rule was chosen. If the rule changes later, retain a record of both decisions and which analyses used each version. This is how someone can distinguish an ordinary, documented correction from an unexplained difference in reported results.
The guidance mentions discarding obsolete versions after backups. Do not interpret that as permission to discard original records or material subject to retention requirements. Decide what may be removed according to the project's policy and its need for a reconstructable history.
Keep the record secure—and retrievable
A traceable record is of little use if it is lost, corrupted, or exposed to people who should not see it. Security concerns paper as well as digital records. Access should be limited to authorized people; sensitive identifiers should be separated from research data when appropriate; and storage must protect against both unauthorized changes and accidental loss. Authorized access for verification is not the same as public release.
Read the DMPTool’s guidance on security, backups, and retention. Its technical examples are general guidance: use the requirements and approved systems that apply to the particular project.
Read the DMPTool's security and storage guidance to distinguish protection from unauthorized access, protection from loss, and long-term obligations to keep records.
Under “Security and Storage” and “Data Security,” read security considerations. Under “Backups and storage,” read “Backup Your Data” and “Test your backup system,” from backup and testing. Under “Other data preservation considerations,” find “How long should the data be retained?” and read retention questions.
A practical choice of storage accounts for who can access it, whether changes can be tracked, whether backups are made and tested, and whether files will remain readable. Keep any encryption keys or recovery arrangements secure and manageable under the applicable policy; an inaccessible encrypted archive is not a successful preservation strategy. For long-term use, keep documentation alongside the data and, where suitable, use widely readable formats. Check the relevant rules before deleting records: retention periods depend on the project and its governing policies, not on a single universal number.
The central test
Good record keeping does not require one particular notebook, application, or file-name template. It requires a dependable account of origin, changes, choices, and custody. Select practices together: consistent identifiers connect records; contemporaneous notes explain them; version histories preserve change; access controls and tested backups protect them; and retention planning keeps them available for as long as required.
In the next lesson, you will use this foundation to distinguish data fabrication, falsification, and selective reporting. A clear record does not settle every question about a finding, but it makes those questions possible to investigate.