Research software problems are often described as reproducibility problems first. A result cannot be rerun, a notebook no longer executes, a dependency changed, or a released figure cannot be matched to the code a paper claims to use. That framing is useful, but it is incomplete. In software-based research, broken reproducibility is sometimes only the visible surface of a deeper issue: the workflow no longer preserves enough traceability to support confident review, attribution, or audit.
That is where integrity enters the picture. Not every irreproducible result signals misconduct, and not every messy repository deserves suspicion. But once version history becomes ambiguous, software citation becomes vague, authorship boundaries blur, or notebook state stops reflecting what was actually run, the problem is no longer just technical inconvenience. It becomes harder to verify who did what, which code state produced which output, and whether the published record can still be trusted on its own terms.
For research systems, that matters because software-based work moves through environments that increasingly depend on technical checks: pre-publication QA, repository review, automated similarity analysis, workflow validation, and post-publication scrutiny. Those systems do not need a perfect software engineering culture to be useful. They do need enough structured evidence to distinguish ordinary workflow noise from integrity-relevant risk.
Why reproducibility failures become integrity problems
A failed rerun does not automatically imply an integrity breach. Sometimes the cause is mundane: a package update, an undocumented local environment, a missing seed, or a collaborator who assumed a file was obvious enough not to archive. Research software is full of fragile points that create reproducibility trouble without dishonest intent.
The integrity problem appears when those weak points block accountability. If a team cannot show which tagged version underlies a published result, the issue is no longer only “the code is hard to rerun.” It becomes “the record cannot support confident verification.” If a notebook’s final figures come from hidden manual re-execution or untracked edits, the problem is not merely untidy process. It is that the workflow can no longer explain how evidence became output.
That distinction matters because integrity review is rarely about perfection. It is about whether claims remain traceable enough to inspect. In software-heavy research, traceability depends on workflow artifacts: commit history, release tags, environment files, dependency versions, execution order, preserved archives, and explicit links between code, data, and reported results. When those artifacts are weak or missing, integrity risk rises even if the original scientific intent was entirely ordinary.
In research software, integrity is often less about catching a dramatic breach than about preserving a chain of evidence strong enough to withstand normal scrutiny.
Research software changes the integrity question
Text-based plagiarism review usually begins with overlap, attribution, and authorship signals. Research software changes that landscape because the object under review is not just prose. It is a moving workflow made of scripts, notebooks, configuration files, dependencies, containers, data interfaces, branches, merges, and execution environments. The integrity question expands from “Was this copied?” to “Can this computational claim still be tied to a verifiable workflow?”
That is why software-origin questions and reproducibility questions often collide. A public repository may exist, but the paper may cite no exact release. A branch may contain the relevant code, but nobody can tell when it diverged. A collaborator may have reused prior internal modules without documenting provenance. A notebook may show the final output, but not the state in which the result was produced. Each of these is partly a workflow problem and partly an integrity problem because each one weakens reviewability.
Scientific software teams often assume that good intentions and active development are enough to preserve trust. They are not. Review systems do not read intention. They read traces. If the traces are thin, conflicting, or missing, editors, integrity analysts, and future users inherit a record that is harder to verify than it should be.
The workflow-integrity chain
The most useful way to think about this is not as a list of isolated best practices but as a chain. Research software integrity depends on several linked controls that either reinforce one another or fail together.
Version control gives the work a time-ordered structure.
Provenance capture connects outputs to code state, parameters, and data context.
Environment traceability preserves the conditions in which computation was performed.
Software citation ties the research claim to a specific scholarly object rather than a vague repository identity.
Release and archive discipline stabilizes what would otherwise remain a moving target.
Review visibility makes that chain understandable to someone outside the immediate team.
When these elements are treated separately, teams often overestimate their strength. A repository without a clear release path does not solve citation ambiguity. A release without environment detail does not solve rerunability. A notebook with visible code does not solve provenance if execution order, hidden state, or generated intermediates cannot be reconstructed. The chain only works when each link supports the next one.
Where workflows fail, and what risk each failure creates
This is the point where reproducibility advice becomes more useful if it is translated into a risk model. A workflow weakness matters because it creates a specific kind of integrity exposure, leaves a certain kind of trace, and demands a certain kind of review response.
| Workflow weakness | Integrity risk created | Auditable trace | Likely control point |
|---|---|---|---|
| No clearly tagged release tied to the paper | Result cannot be linked to an exact software state | Paper cites a repository generally, but not a specific release or snapshot | Publication QA, repository checklist, editorial review |
| Notebook executed out of order or with hidden state | Figures and results become hard to verify as produced outputs | Execution counters, stale cells, missing generated files, inconsistent reruns | Workflow validation, notebook review, reproducibility audit |
| Dependencies or environment not captured | Reproduction failure masks whether the result or setup changed | Missing lockfiles, incomplete environment files, unpinned packages | Pre-submission checklist, automated environment checks |
| Reuse of prior code with unclear provenance | Authorship and attribution ambiguity | Unexplained imported modules, copied fragments, inconsistent headers | Code-origin review, similarity analysis, human follow-up |
| Public repo updated after publication without stable archive link | Published record drifts away from inspectable evidence | Mismatch between article claims and current repository state | Archive verification, citation review, post-publication QA |
| AI-assisted code changes with no disclosure or review trail | Methodological opacity and responsibility gaps | Abrupt style shifts, undocumented code rationale, unverifiable edits | Team policy, review notes, integrity screening plus manual assessment |
The value of this model is practical. It stops treating reproducibility as a vague virtue and instead asks what kind of weakness exists, what kind of doubt it introduces, and what evidence a reviewer would need to evaluate it. Once that logic is visible, integrity work becomes less moralistic and more operational.
When bad reproducibility becomes attribution or reuse risk
Some research software failures stay within the lane of poor workflow discipline. Others move into authorship, provenance, or reuse ambiguity. That shift matters because teams often underestimate how quickly unclear software history can create disputes about contribution and code origin.
A common example is internal reuse that nobody documents carefully. A lab copies an analysis module from an earlier project, modifies it under pressure, and treats the result as part of the new workflow without preserving the earlier origin clearly. Another team forks a repository but later merges fragments back into a shared codebase without stable notes on what came from where. The result may still run. The integrity question appears when publication, review, or dispute forces the team to explain provenance more precisely than their workflow can support.
At that point, the issue starts to overlap with code-similarity analysis for software plagiarism. Similarity alone does not prove misuse, but provenance gaps make origin questions harder to resolve. If a team cannot distinguish ordinary reuse, inherited infrastructure, forked development, and unattributed copying, reviewers are left with technical resemblance but weak contextual evidence.
This is also why version control does more than preserve productivity. In research settings, it can preserve authorship memory. Commit history, merge commentary, and release notes are not only conveniences for collaborators. They are part of the record that lets later reviewers understand how software evolved, who contributed what, and whether reused components were handled transparently.
What publishing QA and research systems can actually check
Not every integrity problem in research software can be solved by automation, but that does not mean systems have little value. The strongest research workflows make certain checks straightforward because they leave stable evidence behind.
A journal, repository, or research-integrity platform can reasonably ask whether a paper points to an exact software version rather than a living repository home page. It can check whether a cited release exists, whether an archive snapshot is stable, whether repository metadata aligns with manuscript claims, and whether basic workflow artifacts are present. It can also flag obvious inconsistencies between a stated computational workflow and the evidence actually supplied.
That is where automated ways of measuring research integrity become relevant. Automation is strongest when it validates the presence, consistency, and coherence of workflow evidence. It is far weaker when asked to infer intent from sparse traces. A system can notice that no exact version was cited, that repository structure changed after submission, or that provenance documentation is thin. It cannot, on its own, decide why those gaps exist.
Good publishing QA therefore works as a layered filter. It catches missing or conflicting workflow evidence early, routes suspicious or incomplete cases for human review, and reduces the number of situations in which editors or reviewers discover version ambiguity only after trust has already weakened. That is a more realistic goal than promising fully automated integrity judgment.
The AI-era complication
AI-assisted research coding complicates this picture because it can introduce workflow changes that feel efficient in the moment but become opaque later. A developer asks a model to refactor a function, generate a parser, or patch a failing segment. The code seems useful, but the rationale, source patterns, and testing path may never be recorded. In a fast-moving project, those edits can enter the workflow without the sort of explanation a future reviewer would need.
The problem is not merely that AI can generate buggy or derivative code. The deeper issue is that it can weaken provenance if teams treat generated suggestions as disposable scaffolding rather than as meaningful interventions in the research workflow. Once a code path shapes a figure, a model output, or a reported conclusion, its origin matters as part of the record.
That does not mean every AI-assisted edit requires extraordinary ritual. It means research teams need a clearer threshold for what deserves review visibility. If an automated suggestion changes logic, data handling, simulation behavior, or interpretation-critical output, the workflow should preserve enough explanation to keep the computation auditable. Otherwise the project inherits an integrity gap disguised as convenience.
What small research software teams should require by default
Not every team can build an elaborate reproducibility infrastructure, but most can establish a minimum viable integrity baseline. The right defaults are not glamorous. They are simply the workflow habits that keep later review from becoming guesswork.
- Tag the version that supports every published result.
- Keep one stable path from manuscript claims to repository evidence.
- Capture the computational environment in a way another person can inspect.
- Record provenance for reused modules, inherited scripts, and major external components.
- Treat notebooks as reviewable workflow artifacts, not private scratchpads that happen to render figures.
- Write down when AI-assisted code materially changes logic or output behavior.
These requirements are modest, but they change the quality of downstream review dramatically. They give collaborators a shared memory, reviewers a usable trail, and editors a much better chance of distinguishing ordinary technical fragility from a record that has become too opaque to trust comfortably.
What this article is not saying
It is not saying that every irreproducible workflow hides misconduct.
It is not saying that version control alone resolves authorship and provenance disputes.
It is not saying that similarity analysis can replace contextual review of software reuse.
And it is not saying that journals or research systems should try to automate judgment where they can only automate consistency checks.
What it is saying is narrower and more useful: once research depends on software, integrity depends increasingly on the quality of workflow traces. Teams that preserve those traces make verification easier, attribution clearer, and publishing review more stable. Teams that do not may discover too late that they did not merely create a reproducibility problem. They created an evidentiary one.
That is why research software integrity should be treated as a workflow property, not just a coding virtue. Reproducibility matters because it supports science. Version control matters because it stabilizes collaboration. But both matter for another reason as well: they help ensure that when a result is questioned, corrected, reviewed, or reused, the record still knows how to answer.