Software engineering went through a reproducibility crisis in the early 2010s that the field solved — imperfectly, but substantially — through a shift in how it thought about configuration and process. The answer was not better documentation. It was treating configuration as code: version-controlled, executable, testable, and reviewable like any other artifact. Infrastructure-as-code, configuration management, container-based build environments — each of these was a concrete implementation of the same underlying idea. The environment that produced a result should be as precisely specified as the result itself.
Biological research is working through an analogous reckoning, roughly a decade behind. The reproducibility problem in life sciences is well-documented at the literature level — replication studies across multiple subfields consistently show failure rates that warrant concern. The causes are multiple and not all addressable by tooling. But a significant and tractable portion of the problem is not experimental uncertainty; it is protocol underspecification. The conditions that produced a result were not recorded with enough precision to reconstruct them.
What "Underspecified" Actually Means
When a methods section says "cells were incubated at standard conditions," that phrase carries a different meaning in every lab that reads it. Standard conditions for one group might mean 37°C / 5% CO₂ in a specific incubator model that runs slightly warm; for another, it means an incubator that was just serviced and is running at exact setpoint. The difference in actual temperature may be one to two degrees. Whether that matters depends on the cell type and the assay, but the point is: the published protocol does not provide enough information to distinguish between the two scenarios.
This is the normal state of biological protocols. They are written for human comprehension, not for machine execution. A human who has run Western blots for three years fills in the gaps from training and tacit knowledge — incubation time variability, blocking buffer concentration range, ECL exposure judgment. That tacit knowledge does not transfer when the protocol is handed to a new lab member or a collaborating group.
The result is a kind of protocol drift: each person who executes a procedure slightly adjusts it based on their own experience and the specific conditions in their environment. The adjustments are often reasonable. But they accumulate, and over time the protocol being run in the lab bears a family resemblance to the one that produced the original result rather than being the same procedure.
Protocol as Executable Specification
The software parallel is instructive. A shell script that says "run the build" is not a reproducible build specification. A Dockerfile that pins the base image, the dependency versions, and the build commands is a reproducible build specification — not because it is more verbose, but because it is executable and unambiguous. Two people with different laptops running the same Dockerfile get the same environment. Two people with different tacit knowledge reading the same protocol may run materially different experiments.
Protocol-as-code applies the same logic to experimental methods. A protocol specified as a structured, versioned, executable artifact — with explicit parameters, dependency references (reagent lot, instrument model, calibration state), conditional branching for decision points, and validation checks at critical steps — is a different artifact than a protocol written as a narrative document. It is not more information; it is information in a form that can be executed consistently, diffed when it changes, and audited when a result needs to be reconstructed.
Consider what a structured protocol for an ELISA might contain versus what is typically in a methods section: explicit lot numbers for antibodies and standards, incubation times with variance tolerances, instrument-specific calibration parameters, expected signal range at each step with flagging conditions if the range is exceeded, and a provenance link to the experiment that generated the reference curve. Each of these parameters is knowable at the time the protocol is run; the question is only whether the system captures it.
The Branching Problem in Biological Workflows
One complexity that makes biological protocols harder to formalize than software build scripts is conditional branching. Experienced researchers make judgment calls mid-experiment: if the primary antibody signal looks low, extend the exposure; if the cell count is below threshold, reseed and delay the assay. These decisions are real protocol steps, but they are usually undocumented because they happen in the researcher's head.
A protocol representation that cannot capture branching is incomplete. It forces researchers to either pre-specify every possible condition (impractical) or accept that the executed protocol diverges from the recorded one whenever a decision is made (which defeats the purpose). The right model is explicit conditional logic: step N checks condition X; if condition is met, proceed to step N+1; if not, branch to remediation step with parameters for that branch. This is standard control flow in code; it is largely absent from biological protocol documentation.
We are not claiming that every bench decision can be reduced to a conditional statement. Judgment calls that depend on visual inspection, on pattern recognition from years of experience, on a researcher's feel for whether a gel looks right — these resist full formalization. What we are saying is that the decisions that can be formalized should be. The remainder can be flagged as "researcher discretion applied at step N" — at least that is captured, rather than silently absorbed into an apparently clean protocol record.
Version Control for Protocols
When a protocol is a document, versioning it means saving a new file. The diff between version 4 and version 5 of a Word document is typically not readable by anyone other than the person who made the change — and even then, it requires opening both files and comparing manually. When a protocol is a structured, parameterized artifact, diffing versions is a first-class operation: what parameters changed, what steps were added or removed, what the justification for the change was.
This matters practically when an experiment run in Q3 produces a result that contradicts a run from Q1. The first question is whether the protocol was the same. With document-based protocols, answering that question may require tracking down email chains and shared folder histories. With versioned protocol objects, it is a query: show me the protocol state at each run date, diff them. The answer is available in seconds, not hours.
A research group working on a gene editing workflow — a mid-size team running iterative optimization across multiple guide RNA designs — ran into exactly this situation. They had a reproducibility gap between runs that looked identical from the methods section. When they worked backward through their records, the difference turned out to be a blocking buffer concentration that had drifted between batches, undocumented because the protocol document had not been updated. A versioned protocol with parameter-level tracking would have flagged the change at the point it was made.
Open Science and Protocol Sharing
Protocol reproducibility is also an open science problem. The pressure toward preregistration and methods sharing in biological research is real, but the infrastructure for sharing protocols at sufficient fidelity is underdeveloped. Depositing a PDF methods section is better than nothing; depositing an executable, parameterized protocol specification that another lab could actually run is a qualitatively different contribution to the scientific commons.
Initiatives like protocols.io have pushed in this direction, and structured protocol sharing is increasingly a norm in certain fields. The gap that remains is between a human-readable shared protocol and one that is machine-executable — that can be imported into a lab's operational tooling, adapted for local conditions, and run with the modifications tracked. That gap is the one that protocol-as-code infrastructure addresses.
Where the Hard Work Is
The technical barriers to protocol-as-code are not insurmountable, but they are real. Instrument interfaces are heterogeneous and often export data in formats that are not designed for structured ingestion. Reagent lot tracking requires integration with procurement and inventory systems that most labs manage separately. Conditional protocol logic needs a representation that is expressive enough to capture real experimental decisions but simple enough that a bench scientist can work with it directly without programming.
These are the engineering challenges that lab informatics platforms are working toward in 2025, and none of them are solved end-to-end yet. What is clear is the direction: the biological research community is converging on the same insight software engineering reached more than a decade ago. The procedure that produced a result should be as precisely specified as the result itself. That is not a higher bar than science already aspires to — it is the original aspiration, implemented with tools that can actually deliver on it.