A Research Record That Survives You Leaving

Research projects routinely outlast the people working on them. A student finishes, a postdoc moves, a collaborator changes field. What remains is whatever was written down.

Usually that is the files, and the files are the easy part. What disappears is the reasoning. For a concrete operational comparison, Monitask explains online timesheets in practical terms.

What actually gets lost

Why decisions were made. Why these observations were excluded, why this specification, why the measure was changed in month four. The files record what was done; nothing records why.

What was tried and abandoned. The successor repeats it, and there is no way for them to know.

Where things are. Which version is current, which folder is the real one, what the file named final_v3_new supersedes.

The state of external relationships. Who at the partner institution agreed to what, what the data provider's conditions were, what the ethics approval covers.

What is fragile. The step that only works if run in a particular order, the dataset that has a known problem in one year.

None of this is in the analysis code, and all of it is required to continue the work.

The decision log

The single highest-value artefact, and it takes minutes.

A running file. Date, decision, reason, alternatives considered.

2026-03-14  Excluded 2019 wave.
            Instrument changed mid-year; responses not comparable.
            Considered rescaling — no reliable crosswalk exists.

2026-04-02  Switched primary outcome to X.
            Y is only available for a subsample and the subsample
            is not random (see note in codebook).

Why this matters more than documentation of the code: the code shows what happened, and anyone can read it. The reasoning is the part that cannot be reconstructed, and it is the part a reviewer will ask about in eighteen months.

Write it when you decide, not later. Reconstructed reasoning is a rationalisation of a decision you no longer remember making.

And it is for you. Returning to a project after a year, you are the successor.

The other things worth keeping

A project README, kept current: what this is, what stage it is at, what the files are, what to run, who to contact about what.

A record of what was tried and did not work, with enough detail that it will not be repeated. This is frequently the largest saving and almost nobody keeps it.

Contacts and agreements. Who provided what, under what conditions, with what expiry. Data agreements have end dates and ethics approvals have scopes, and both are usually held in one person's memory.

The codebook, kept current rather than written at submission. See sharing data and materials.

Version discipline. One current version, in one place, with history. The details are less important than that there is a convention and it is followed.

Handover, specifically

When someone is leaving, and this is usually arranged too late.

Start a month before, not in the last week. Handover is a process of the successor asking questions, which requires them to have started.

Overlap if you can. Two weeks with both people present is worth more than any document.

Have the successor do something real while the predecessor is still there — reproduce a result, run the pipeline end to end. Whatever breaks is what the documentation was missing.

Record the conversation or take notes. Handover meetings contain a great deal that nobody writes down.

Transfer the relationships explicitly. An introduction by email to the data provider, the collaborator, the technician who knows the equipment.

And write down what the departing person is worried about. Ask directly: what will break, what do you know that nobody else does. The answers are specific and they are the most valuable part.

For supervisors and group leaders

The group's memory is your responsibility, because the students and postdocs cycle through by design.

Require a decision log from the start of each project. Not as bureaucracy — as the thing that makes their own work reproducible and their thesis easier to write.

Do a handover properly every time, including when someone leaves on bad terms or abruptly. That is when it matters most and when it is least likely to happen.

Keep a group-level record of what has been tried across projects, or the same dead end gets explored every three years.

See supervision.

The objection

"I do not have time."

The decision log is a few lines a week. The README is a page, updated occasionally. The handover is a fortnight once every few years.

The alternative is a project that stalls when someone leaves, or a revision that cannot be completed because nobody knows why the sample was constructed that way.

And the beneficiary is usually you. Most people who wish a record existed are looking at their own project from eighteen months ago.

The short version

The files survive; the reasoning does not. A decision log with date, decision and reason is the highest-value thing you can keep.

Record what was tried and abandoned, or it will be repeated.

Start handover a month early, and have the successor run something real while the predecessor is still there.

Ask the departing person what will break. They know, and nobody asks.

For an independent authoritative reference, consult the Open Science Framework for infrastructure for transparent research practice.