Most experiments begin with a method. It might come from a published paper, a manufacturer’s manual, a shared drive or the colleague at the next bench. Before the first sample is touched, someone has to turn that method into a sequence of actions that can be carried out in this lab, with these materials, for this particular question.

That makes the protocol more than a set of instructions. It is the bridge between experimental intent and experimental work.

We think protocols should be treated as the building blocks of a laboratory’s knowledge: reusable, versioned and connected to every experiment that depends on them.

How laboratory methods are commonly managed

There is no single way that labs manage protocols today. Most use some combination of documents, templates and specialist workflow software. Each approach solves part of the problem.

Static documents

Word documents, PDFs and shared online documents are familiar and flexible. They are easy to write, annotate and distribute, which is why they remain the default in many laboratories.

But a document is usually separate from the work performed with it. A scientist follows the method at the bench, records deviations somewhere else and stores results in another folder or application. If the document changes later, it may be difficult to determine which version was used for an earlier run.

Static documents are good at describing a method. They are less effective at preserving the relationship between the method and its execution.

ELN templates

Electronic lab notebooks often let teams create experiment templates. These improve consistency by providing a repeated structure for notes and results. In practice, however, a template is frequently copied into each new experiment.

Copying is convenient, but it creates many disconnected versions of the same method. Improvements made in one experiment do not necessarily return to the shared protocol, and comparing runs can require reading through several near-identical records.

Structured workflow systems

At the other end of the spectrum are systems that model methods as highly structured workflows. They can enforce steps, capture parameters and integrate with automation. This is valuable where processes are stable and standardisation is essential.

The trade-off is rigidity. Research methods change frequently, and scientists need room to respond to what they observe. If representing a protocol requires extensive configuration—or if every deviation is treated as an error—the software can become an obstacle to exploratory work.

Our method: structure without rigidity

Sous starts from a simple distinction:

A protocol describes what is intended. An experiment records what actually happened.

The two should remain connected without being collapsed into the same record.

In Sous, a protocol is a reusable method with an explicit version history. Starting an experiment links that experiment to the exact protocol version selected at the time. The link remains stable even if the team improves the protocol later, so an old result can always be interpreted against the method that produced it.

At the bench, the protocol becomes a guide rather than a cage. Scientists can work through its steps, record observations and capture deviations as they occur. Those changes belong to the run. They do not silently rewrite the shared method or pretend that the original plan was followed exactly.

Afterwards, the difference between plan and execution becomes useful information. A one-off adjustment may remain part of that experiment alone. A change that repeatedly improves results can be reviewed and promoted into a new protocol version.

Protocols connect the experimental lifecycle

Treating protocols as first-class, connected objects creates continuity across work that is often split between different tools.

Planning

A protocol provides a concrete starting point for a new experiment. The researcher can select a proven method, review its parameters and adapt the experimental plan without rebuilding the procedure from scratch.

Execution

The same structure guides work at the bench. Steps, materials and observations stay associated with the run, making it easier to capture context while it is still fresh.

Review

Because results remain linked to protocol versions, runs can be compared meaningfully. A team can see whether a difference in outcome coincided with a changed method, a recorded deviation or another part of the experimental context.

Improvement

The evidence generated by experiments can feed back into the method. Protocol development becomes an explicit cycle: use a version, observe what happens, review the differences and publish the next version when the evidence supports it.

Building a shared method without erasing judgement

Standardisation is useful when it preserves knowledge and reduces avoidable variation. It becomes counterproductive when it removes the scientist’s ability to respond to reality.

Our aim is not to automate judgement out of laboratory work. It is to give that judgement a durable place in the experimental record. The protocol captures the team’s current best method; the run captures the decisions made while applying it.

Together, they create something stronger than either a static SOP or an isolated notebook entry: a method that can be reused, examined and improved without losing the history of how it was used.

Experiments produce more than results. They also produce knowledge about how to obtain those results. Protocols are how that knowledge becomes a building block for whatever the lab does next.