A report says twenty-four compounds were tested. A revised spreadsheet contains twenty-two usable results. The scientist who made the correction knows why, but the explanation is in a message that the report’s author never saw.
This is a familiar research problem: files change independently, and the decision loses contact with the evidence. Version control helps by recording related changes together and making them available for review.
“Pharma as code” applies that discipline to a research program’s protocols, analysis methods, structured records, and documents. The aim is to make a scientific decision traceable from its source to the version someone actually read.
What Git Actually Adds
Git records snapshots of tracked files. A commit identifies a saved state, along with a message describing the change. A diff shows the differences between states. A repository holds the files and their history.
That is useful even for people who never write software. A reviewer can see that a report changed because two samples were excluded, inspect the recorded reason, and locate the analysis used for the revision.
GitHub and similar services add collaboration features such as review discussions and access controls. Those features are separate from Git itself, and a team needs to configure them deliberately.
The dataset, analysis, and report initially describe all twenty-four samples.
The quality record flags the samples. The raw observations remain available with their status.
The analysis is rerun. The report's count and interpretation are reviewed against the revised evidence.
A coherent commit can connect the correction, analysis change, and revised report. Review records establish who accepted the change and why.
A commit identifier names a particular state. It does not establish that the result is scientifically correct, that the named person performed an experiment, or that a reviewer approved it. Those facts need their own evidence and workflow.
Experiments as Code
Consider an enzyme assay. A useful record connects the protocol version, sample identities, instrument output, quality checks, analysis settings, and interpretation. Another scientist should be able to follow those connections without guessing which spreadsheet is current.
Some materials fit naturally in Git: analysis scripts, small structured tables, protocol text, and document source. Large instrument files and restricted datasets often belong in managed storage. The repository can retain an inventory with stable references, version identifiers, and checksums instead.
A checksum helps determine whether a retrieved file matches the expected bytes. It cannot tell you whether the sample was mislabeled before the file was created. Data integrity and scientific validity are related, but different, questions.
Protocol text, analysis code, small tables, data inventories, environment definitions, and report source.
Raw instrument files, imaging data, and sensitive datasets, with appropriate access and retention controls.
Git Large File Storage is another option for large assets: the repository contains a pointer while the content is stored separately. A reproducibility plan still needs to preserve access to that content. A pointer alone cannot rerun an analysis.
Make the Analysis Repeatable
Saving code is only the beginning. Record the software environment, relevant package versions, model identifier, parameters, and any random seed. Preserve the inputs and the outputs that supported the decision.
For a hosted model or external database, the service may change. Keep the returned result and the date of the query, alongside enough information to understand the request. A later rerun might produce a different answer even when the local code is unchanged.
An automated check can confirm that required inputs exist or that a report’s count matches the accepted dataset. It cannot substitute for reviewing whether the exclusions were scientifically justified.
AI Needs an Audit Trail
An agent might update an analysis, draft a summary, or propose the next experiment. Its work is easier to assess when it arrives as a focused change with the supporting tool outputs and source references.
The reviewer needs the task, inputs, model and tool versions where available, results, and stated assumptions. A fluent explanation of how an answer was reached is insufficient evidence on its own. The underlying calculations and cited observations must remain inspectable.
A good review asks three questions: what changed, why did it change, and which conclusions depend on it? If a data correction changes a shortlist, the report should say so. If it leaves the decision unchanged, the record should explain that too.
At AgentCures, version-controlled research gives scientists and agents a shared place to propose, inspect, and improve work. The examples here describe that working method, without implying that a commit is a scientific approval.
Why It Matters
A useful starting point is one recurring analysis. Define its inputs, keep its method under version control, and generate a small report from the same accepted data. Ask a colleague to reconstruct the result from the saved record.
The difficulties they encounter are valuable: an inaccessible dataset, an undocumented setting, or an unexplained exclusion tells the team what to fix next. Expanding this practice gradually is more useful than moving every file into Git at once.
The payoff is a research record that survives handoffs. When a result changes, the team can understand what happened and update the decisions that depend on it.