Reproducible research starts with the method, not the manuscript. Five concrete things turn a protocol someone else can actually repeat — exact materials, unambiguous steps, version history, recorded failures, and a citable version.
A protocol is reproducible when someone else can follow it and get your result without guessing. That takes five things: pin the exact materials, write unambiguous steps, put the method under version control, record what doesn't work, and make each version citable. The rest of this guide is how to do each one.
When researchers were surveyed by Nature on reproducibility, the majority reported having failed to reproduce another lab's experiment — and more than half had failed to reproduce one of their own. The single most cited cause isn't fraud or bad statistics. It's the method: the written protocol left out something the original experimenter knew but never wrote down.
So reproducibility is mostly a documentation problem, and it's fixable at the bench. A reproducible protocol removes the guesswork in five places. None of them require a new instrument — just a more honest, more structured way of writing the method down.
Ambiguous materials are the number-one reproducibility leak. "Add blocking buffer" tells the next person nothing; "block in 5% BSA (Sigma A7906, lot-tracked) in TBST, 1 h at room temperature" tells them everything. For every reagent, record:
If you're starting from an existing method, you don't have to retype any of this. You can bring the document into jnar and the materials and steps are extracted into a structured form you then annotate with the details above.
Write for someone who has never seen the experiment and can't ask you a question. Every step gets its explicit parameters — time, temperature, volume, speed — and an unambiguous order. Replace "spin down" with "centrifuge 10 min at 12,000 × g, 4 °C". Replace "incubate briefly" with a number.
Flag the steps where timing or technique actually decides the outcome — the transfer that has to stay cold, the wash that can't be rushed. A critical-step callout is the difference between a protocol that technically lists every step and one that tells you which steps you can't get wrong.
A good test: hand the protocol to someone in a different lab and watch where they hesitate. Every hesitation is a missing parameter.
Methods change — you find a better block, a cleaner transfer, a concentration that stops the background. The reproducibility failure is that most labs copy the protocol when this happens instead of versioning it. Within a year there are six files named some variation of v3_FINAL, and nobody can say which one works or why a step changed.
Version control fixes this by keeping one canonical method with a visible history of what changed and why — not just that an edit happened. The reason a step changed is the half a plain diff leaves out, and it's the half that makes the next version trustworthy. This is the core idea behind version control for lab protocols: the same mental model developers use for code, adapted for wet-lab methods, with the change and its reason kept together.
The path that worked is only half the knowledge. The reagent concentration that suppressed the signal, the step that only works below 8 °C, the antibody lot that gave nonspecific bands — these negative results narrow the search space for everyone who repeats the method. They almost never survive into a published methods section, because there's no slot and no credit for them.
Treat them as first-class, attributed data attached to the protocol rather than folklore in someone's notebook. When a failure changes how a step is done, it should show up in the version history next to the fix it motivated. We make the full case for this in why negative results belong in your methods.
"See our protocol" isn't reproducible if the protocol has changed three times since the paper. Cite the version — the exact state of the method you actually ran — so a reader lands on what you did, not what it became later. Versioning, the fix history, precise diffs, and ORCID attribution per version are live on jnar today; DOI minting for published versions is on our roadmap, not shipped yet.
The payoff compounds: because fixes and failures fold into later versions, the protocol you cite next year is measurably more reproducible than the one you publish today.
A protocol is reproducible when another scientist can follow it and get the same result without guessing. In practice that means exact materials (reagents, catalog and lot numbers, concentrations, equipment and software versions), unambiguous steps with explicit parameters, a record of what changed and why, and the failure modes that aren't obvious from the working path.
At minimum: a materials list with concentrations and supplier details, numbered steps with explicit time / temperature / volume / speed, critical-step callouts, expected results, and known failure modes. A reproducible protocol adds two things most methods sections omit — a version history that records why each change was made, and negative results attached to the steps they affect.
A methods section describes the single path that worked, compressed for publication and frozen at submission. A reproducible protocol is a living document: it keeps the exact parameters, the version history, and the dead ends out of the narrative — the information a replicator needs most. The methods section is a summary; the protocol is the source.
No. You can bring an existing methods document or PDF into jnar and the structure — steps, reagents, figures — is extracted for you, so you start from your real method instead of a blank page. From there you add lot numbers, version notes, and the failures you already know about. The first conversion is free.
Most labs copy protocols instead of versioning them, so within a year there are several divergent files and no record of why any step changed. Version control keeps one canonical method with a visible fix history: the buffer that fixed a transfer, the antibody lot that ruined a week, the block that was switched from milk to BSA — each change kept next to its reason. That reason is the half a plain diff leaves out.
