Name research files so a revision can be traced and recovered

1. Agree what each part of a filename means

For the fictional RP17 team, use project_artifact_version_date.extension. The project code is stable, the artifact token comes from a short shared list, and v01, v02 and v03 identify successive saved milestones for that artifact. The date is the date the milestone was recorded, not the study’s data-collection date or evidence of approval.

Write this rule in a project README with the owner, timezone and examples. RP17 uses ASCII letters, numbers, underscores and ISO-style dates to keep filenames simple across tools; Arabic descriptions belong in the manifest. This is a chosen convention, not a rule that Arabic filenames are inherently unsafe. Agree how exceptions will be documented instead of inventing new tokens during a deadline.

2. Make a manifest that explains six different artifacts

The invented snapshot below contains one working manuscript and the items needed to interpret its status. “Dictionary” describes variables; “plan” describes intended work; “script” contains instructions. Their existence does not prove that analysis ran. The manifest is a separate table recording path, purpose, version, custodian and actual dependencies.

UK Data Service guidance recommends systematic version identities, change records and relationships between files, including code and its input data. A filename can carry a short identity; the manifest carries the details that would make the name unreadably long.

Reference: UK Data Service: version control

On small screens, scroll the table horizontally, or focus it and use the arrow keys.

3. Separate a saved date from a version and an approval

Two milestones may be saved on the same day; the version field distinguishes them. A file’s operating-system modified time can change during copying, so do not use it as the only evidence of the team’s decision. Record who created the milestone and why in the change log, with an unambiguous timestamp where same-day order matters.

For RP17, a later manuscript v02 might correct a sentence while leaving the dictionary and script at v01. Version numbers belong to each artifact and do not need to match across the project. The manifest must identify the actual dependency, rather than assume that every file marked v02 belongs together.

4. Resolve two edits without letting “latest” choose

In the fictional exercise, the methods editor and language editor both receive manuscript v01. They return separate review copies named RP17_manuscript_v01_methods-review.docx and RP17_manuscript_v01_language-review.docx. These are labelled review branches, not competing approved milestones. Each reviewer records the base version.

The coordinating author compares both against that base, checks any meaning-changing language edit with the methods owner, and records unresolved differences. Only after reconciliation is a new manuscript v02 saved. File naming does not decide a scientific disagreement; the named decision and its rationale belong in the change log.

On small screens, scroll the table horizontally, or focus it and use the arrow keys.

5. Rehearse recovery using a harmless teaching file

Suppose RP17’s working copy of v02 is accidentally overwritten after a retained milestone copy was saved. In this invented exercise, the custodian first preserves the damaged working copy for diagnosis, then restores the retained v02 into a separate recovery location. The team compares it with the recorded milestone before replacing the working copy.

The recovered name alone cannot prove recovered content. Check that the document opens, the expected sections are present, and its bytes match a previously recorded checksum when available. A matching checksum establishes agreement with those saved bytes; it does not establish scientific correctness. If no retained copy exists, renaming the damaged file cannot restore the lost text.

6. Give backup and access their own owners

UK Data Service treats backup and restoration as separate storage responsibilities and recommends testing recovery. Determine which approved workspace is backed up, who can restore a milestone and what the retention window actually covers. A synchronised folder may copy an unwanted deletion; verify the relevant version and recovery behaviour in your own service.

Do not put participant names, diagnoses or passwords into filenames. A readable project code does not make its underlying files anonymous or authorize sharing. Keep restricted materials in approved storage with the required access controls, and make the manifest available only to people entitled to see its contents.

Reference: UK Data Service: storage and security, backup and recovery

7. Close a handoff with a specific artifact

Ask a colleague to find the intended manuscript, identify its dependencies and explain whether analysis and author approval have occurred using only the README and manifest. Any ambiguity is a concrete defect to fix. In the present RP17 example, analysis is still unrun, so the handoff must not imply that the manuscript contains verified results.

When final approval eventually occurs, record exactly which version each required author approved and preserve the corresponding file. “Approved” should be an evidence-backed status in the manifest, not an adjective added to an editable filename. A subsequent substantive change requires the team to reconsider that approval against the changed artifact.

Questions for a practical final check

• Define project, artifact, version and date fields.
• Retain a readable manifest and change log.
• Record base versions for parallel review copies.
• Link the exact inputs and outputs actually used.
• Practise recovery in an approved non-sensitive exercise.
• Bind approval to a specific retained artifact.