The integrity question does not start at publication
Research integrity in software-heavy science begins long before a manuscript is submitted. In materials simulation, computational modeling, and research computing workflows, the published claim is often only the final surface of a much longer chain: code, configuration, dependency versions, input data, solver behavior, run history, and interpretation.
That chain can weaken quietly. A figure may come from a script that was later changed. A simulation may depend on a local environment that no one else can rebuild. A notebook may contain the final output but not the exact sequence that produced it. A parameter file may have been edited after the result was first discussed. None of these situations automatically proves misconduct, but each one makes the research harder to verify.
For research software teams, integrity is not only about avoiding copied text or fabricated data. It is also about preserving enough workflow evidence to answer a practical question: can the team explain how this computational result came into being?
Version control is evidence, not just organization
Version control is often introduced as a way to organize collaboration. That is true, but incomplete. In research software, commits, branches, tags, releases, and change history also become evidence. They show when code changed, who changed it, what the change was meant to address, and which software state supports a reported result.
This matters because scientific software is rarely static. A solver may be refined, a boundary condition may be corrected, a plotting script may be cleaned up, or a dependency may change behavior between versions. Without a stable version record, a team may know that a result was “from the current code,” but that phrase becomes useless once the current code moves on.
The familiar folder pattern of final_code, final_code_v2, and final_code_revised may feel harmless during a project deadline. Later, it becomes a traceability problem. If a paper, report, or dataset cannot be tied to a specific commit or tagged release, the result depends on memory rather than evidence.
Good versioning does not guarantee correct science. It does something narrower and essential: it keeps the computational record inspectable.
Reproducibility makes debugging and integrity overlap
Debugging and integrity review often begin with different motives but ask related questions. Debugging asks, “What changed?” Integrity review asks, “What produced this result?” Both questions depend on reproducibility.
When a simulation stops matching an earlier figure, a team needs to know whether the cause was a code change, a parameter adjustment, a dependency update, a mesh setting, a random seed, or an undocumented manual step. That same information matters if a reviewer, collaborator, or future user later asks whether the reported result can be trusted.
This is why reproducibility as part of debugging scientific software is not only a developer convenience. It is part of the integrity infrastructure of a research workflow. A reproducible workflow gives teams a way to diagnose errors without guessing and to defend results without relying only on authority.
The overlap is especially important in fast-moving research projects. A team may fix bugs, explore alternatives, and rerun simulations many times before publication. Unless those changes are traceable, ordinary development work can later look like an unexplained gap in the evidence chain.
The Research Software Integrity Chain
A useful way to think about research software integrity is not as a list of isolated best practices, but as a chain. Each link connects a scientific claim to the workflow evidence that supports it. If one link is weak, the entire claim becomes harder to inspect.
| Integrity-chain link | Question it answers | Evidence teams should preserve |
|---|---|---|
| Research question | What claim, behavior, or model result was being tested? | Experiment notes, issue references, project plan, or analysis goal |
| Code state | Which exact software version produced the result? | Commit hash, release tag, branch reference, archived snapshot |
| Environment | What computational conditions affected execution? | Dependency files, container recipe, compiler details, solver versions |
| Model configuration | Which parameters, boundary conditions, mesh settings, or inputs were used? | Configuration files, input datasets, parameter logs, run metadata |
| Execution record | When and how was the simulation or analysis run? | Run logs, notebook execution order, job scripts, random seeds |
| Output link | Which figures, tables, or reported values came from that run? | Output directories, figure-generation scripts, result manifests |
| Review trail | What changes, tickets, corrections, or discussions explain the result history? | Issue tracker entries, pull requests, review notes, bug reports |
The chain helps teams distinguish between a messy workflow and an integrity-sensitive workflow gap. A missing note may be inconvenient. A missing link between a published figure and the code state that produced it is more serious because it weakens the result’s reviewability.
Why materials simulation raises the stakes
Materials simulation can be especially sensitive to small workflow changes. A phase-field model, a PDE solver, a mesh choice, or a boundary condition can influence how a result behaves and how it should be interpreted. Even when the code is mathematically reasonable, the output may depend on details that are easy to lose if the workflow is not disciplined.
In FiPy-based phase-field modeling workflows, for example, the integrity chain might include solver settings, grid resolution, timestep choices, material parameters, initialization assumptions, and post-processing scripts. If those pieces are not versioned or recorded, a later reviewer may see the final plot but not the computational path that made it meaningful.
This does not mean every simulation project needs an enterprise-level software process. It means materials simulation teams should treat configuration and execution evidence as part of the research object. The model is not only the equations. It is also the implemented, parameterized, executed workflow that produces interpretable output.
The more sensitive the output is to setup choices, the more important it becomes to preserve those choices in a way that another team member can inspect.
Issue trackers are part of the research record
Issue trackers are often treated as project-management tools, but in research software they can also become part of the scientific record. A bug report may explain why a result changed. A feature request may show when a new model capability was introduced. A discussion thread may clarify why a parameter was adjusted or why a previous output was considered unreliable.
This context matters because scientific code evolves through uncertainty. A ticket about unstable convergence, unexpected output, dependency changes, or incorrect post-processing may be directly relevant to a figure that later appears in a paper.
An issue history should not be used as a blame log. Its stronger role is explanatory. It helps future readers understand the relationship between software development and scientific interpretation. If an issue was resolved before publication, the record can show how. If it remained open, the team can explain whether it affected the reported result.
When issue trackers are disconnected from outputs, teams lose an important layer of evidence. When tickets, commits, and results are linked, the workflow can explain itself more clearly.
When workflow gaps become integrity risks
Not every workflow gap is an integrity problem. Research software is complex, and incomplete documentation is common. The risk rises when missing workflow evidence prevents a team from explaining authorship, provenance, result generation, or the relationship between the software and the published claim.
Examples include a manuscript that cites a repository but not a tagged release, a notebook edited after figures were generated, a copied internal script with unclear provenance, a dependency update that changes output without being recorded, or simulation results stored separately from the run configuration that produced them.
These are not just technical inconveniences. They can become review problems because editors, collaborators, and quality-assurance systems may need to evaluate workflow-level integrity risks in research software when computational evidence is part of the research record.
The important point is proportionality. A technical QA process should not treat every missing file as misconduct. But it should recognize when the absence of traceability makes a result difficult to verify, attribute, or reproduce.
A practical traceability checklist for research software teams
Research software teams do not need perfect infrastructure to reduce integrity risk. They need a minimum set of habits that keep claims connected to evidence.
- Tag result-supporting versions. Every published figure, table, or reported value should connect to a stable code state.
- Record the environment. Preserve dependency versions, solver versions, container files, or environment specifications where they affect results.
- Document parameters. Treat configuration files, mesh settings, boundary conditions, and input assumptions as research evidence.
- Link issues to outputs. When a bug, anomaly, or correction affects interpretation, connect the discussion to the relevant result.
- Preserve notebooks carefully. Notebooks should show a reliable execution path, not only a polished final state.
- Cite software versions. A general repository link is weaker than a release, archive, or versioned reference.
- Review changes before publication. Check whether the manuscript’s claims still match the repository, tags, outputs, and documentation.
These habits are modest, but they change what a team can say when a result is questioned. Instead of reconstructing the workflow from memory, the team can point to a record.
Integrity is easier to defend when the workflow can speak
Scientific software teams work in an environment where code, data, models, dependencies, and documentation all move. That movement is normal. The integrity risk appears when the workflow moves without leaving enough trace to explain itself.
Version control, reproducibility practices, issue tracking, and result traceability protect more than efficiency. They protect the credibility of the computational claim and the people who produced it. They also make honest correction easier, because a team with a clear record can identify where a problem entered and how it was handled.
Research software deserves the same integrity attention as text, data, and figures. When the workflow can speak, teams are better able to show what was run, why it changed, who contributed, and how a result became part of the scientific record.