The Revise & Resubmit Problem

You have the files. You don't have the reasoning. This gap has a name.

The email arrives on a Tuesday in March. The journal has sent back your paper — revise and resubmit. The reviewers are constructive. Reviewer 2 wants additional calculations to validate the claim about surface stability under thermal perturbation. Reviewer 1 wants you to justify the choice of exchange-correlation functional for the oxide surface calculations specifically, given recent papers challenging that approach.

This is good news. The paper is close. The reviewer feedback is tractable.

The postdoc who ran those calculations defended in December.

What You Have

The calculation outputs are on the cluster. Job submission scripts are in a git repository. The cluster logs show exactly when each job ran, what node it used, and how long it took. The OUTCAR files exist. The CONTCAR files exist. The final energy values are in a spreadsheet that feeds the paper's figures.

You have everything you need to reproduce the calculation.

What you do not have is the reasoning.

Specifically: why was PBE+U chosen over HSE06 for this particular material class? The postdoc made that decision in October 2024, after testing both. The tests exist somewhere — they ran VASP jobs comparing functionals — but the conclusion is in an email, or a Slack message, or a lab meeting slide that was never uploaded anywhere, or just in the postdoc's memory. You cannot find it in the repository. There is no note in the job directory. The git commit message says "updated INCAR settings" and nothing else.

# commit f3a91b2
# Author: Chen Wei <c.wei@lab.edu>
# Date:   Wed Oct 8 16:43:22 2024

updated INCAR settings

 INCAR | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Two insertions, two deletions. Four lines that switched the functional and adjusted the Hubbard U parameter. The reason is gone.

The Reasonable Response

You email the postdoc. She is at a national lab now, starting a new project. She replies within a day — she is helpful, she remembers roughly what she did. She thinks it was because PBE+U gave better agreement with experimental lattice constants for this specific composition range, but she is not certain about the U value justification. She can look at her local backups if she has time this week, but she is in the middle of something.

You spend two days reconstructing the reasoning from what you can find: the postdoc's partial memory, a paper she cited in a draft supplement that was never included, a similar calculation in another job directory with a slightly different material that suggests the reasoning. You piece it together. You write the response to the reviewer. It is correct — you are confident enough to submit — but you have now spent two researcher-days on a calculation decision that was already made and documented nowhere retrievable.

This is not a failure of documentation culture. It is a structural property of research workflows: the reasoning behind decisions is generated at the moment of decision and has no natural home that is both low-effort to create and high-fidelity to retrieve.

Why This Happens Structurally

Research workflows have very good memory for outputs and very poor memory for reasoning. Every computational cluster keeps precise logs of what ran. Git tracks every file change. The OUTCAR from a 2021 VASP calculation is perfectly retrievable. What is not retrievable is the conversation that happened at group meeting in September 2021 where the convergence criterion was discussed and a decision was made to accept a threshold that was slightly less tight than the default because of cost constraints on that particular HPC allocation.

The decision was made by people, in real time, for reasons that seemed obvious and did not need to be written down. The VASP INCAR reflects the decision. It does not reflect the reasoning, the alternatives considered, the tradeoffs evaluated, or the constraints that made one option clearly better than another in October 2024.

This is not a problem of bad habits or insufficient documentation discipline. It is a problem of where reasoning lives in a research workflow. Reasoning is generated during meetings, in Slack threads, in email chains, in conversations between a postdoc and a PI where the postdoc says "I tried both, PBE+U was closer to experiment for these compositions, I'll go with that." It is not generated in git commit messages, because writing commit messages is a different cognitive act than making a scientific decision.

The Three Failure Points

The revise-and-resubmit scenario fails at three distinct points, each of which looks like a different problem but is actually the same problem.

Failure point one: decision reasoning is not captured at the moment of decision. The postdoc makes a choice, the choice is good, the result is used. Nobody writes down why. The window for capturing the reasoning is the moment it is generated — after that, it degrades with time and is lost entirely when the person leaves.

Failure point two: existing records are not synthesized. The reasoning often does exist somewhere — in a Slack message, an email, a meeting summary that one student wrote once. But it is not connected to the artifact it explains. A git commit points at a file. It does not point at the Slack thread where the decision to change that file was made.

Failure point three: retrieval requires knowing where to look. Even if the reasoning exists and you know it exists, finding it requires navigating Slack search, email search, and filesystem search simultaneously — with enough context to know which terms the postdoc used when she was thinking about it. This is not a search problem. It is a synthesis problem.

What Would Have Made This Trivial

The revise-and-resubmit scenario described above becomes a twenty-minute task instead of a two-day reconstruction if the lab's reasoning context is indexed and queryable.

Not the files — you already have those. The reasoning. The Slack thread from October 2024 where Chen wrote "ran the HSE06 comparison — PBE+U gives 0.3% better agreement on lattice constants for the Ti-O system, going with U=4.5, matches the Dudarev et al. values that the Heinz group validated last year." The email where the PI replied "sounds good, let's document this for the supplement." The lab meeting slide from October 7 where the functional choice was confirmed.

A query to an indexed version of that context — "why did we use PBE+U instead of HSE06 for the oxide surface calculations in the stability paper?" — would return that thread directly. The reviewer response writes itself.

This is not a future capability. It requires only that the reasoning context that already exists in the lab's communication channels be indexed and made queryable against the artifacts it explains. The Slack messages exist. The emails exist. The meeting notes exist in someone's drive. They are just not connected to the INCAR file that implements the decision they document.

The Broader Pattern

The revise-and-resubmit scenario is one instance of a pattern that happens across every computational lab several times per year. The same reconstruction problem occurs when: a new student takes over a project and cannot find the rationale for a parameter choice; when a collaborator asks for the justification behind a method decision for their own paper; when a grant renewal requires documenting the lab's methodology and the PI realizes that the documentation that exists describes the outputs, not the reasoning that produced them.

Each instance is recoverable. The postdoc replies to emails. The reasoning can be reconstructed. Research groups manage. But each instance costs researcher-days, delays submissions, and represents a category of work that would not exist if the reasoning had been indexed when it was generated.

The pattern scales with lab size and publication velocity. A lab submitting eight papers per year, with four to six researcher-transitions per year, encounters this problem regularly enough that the cumulative cost — in delayed revisions, duplicated reconstruction work, and simply lost institutional knowledge that was never recovered — is significant.

It is also, unlike most research infrastructure problems, fully solvable with tools that already exist.