Protocol Documentation¶
Document — instantiates Reproducibility Protocol
Describes the ordered method, required inputs, assumptions, roles, and output checks that allow a process or analysis to be repeated.
Protocol Documentation is the prescriptive specification of how a piece of work should be carried out — the canonical ordered method, the inputs it requires, the roles involved, and the checks its output must pass — written to be followed by anyone, on any run. Its defining idea is that it is prospective and run-independent: it names the result to be reproduced and lays down the repeatable path to it before the work happens, so that many executions can converge on the same procedure. It is the rulebook, not the eyewitness account. Where an as-run notebook captures the messy particulars of one instance, protocol documentation captures the intended shape that all instances are meant to share.
Example¶
A contract manufacturer runs a torque-and-inspection step on assembled valve housings. The protocol document names the target explicitly — a housing that passes the seal-integrity spec, reproducibly, across shifts and operators — then lays down the ordered method: fixture the housing, apply torque to a stated value in a stated sequence, hold, then measure. It states the required inputs (calibrated torque driver, the specified gasket part), the roles (operator performs, line lead verifies), and the acceptance check the output must clear (leak-down below a stated threshold on the test rig). Because the method is written to be followed identically by whoever is on shift, a new operator on nights produces housings indistinguishable from the day crew's — and when a batch later fails, investigators can compare what the protocol said to do against what the as-run records show was done. (Thresholds and parts named are illustrative.)
How it works¶
The document fixes an intended procedure independent of any single execution. Three elements make it a reproducibility mechanism rather than a mere how-to: it names the reproducibility target so it is clear what "repeated correctly" even means; it lays out the ordered, unambiguous method with required inputs and roles, written so a competent second actor can follow it without tacit knowledge; and it specifies the output checks — the acceptance criteria a correct result must satisfy. Crucially, it is not a record of what happened on any given run; it does not log the deviations or the actual materials used. It is the standard against which those as-run records are read.
Tuning parameters¶
- Specification tightness — every step pinned versus latitude left to skilled judgment. Tight specs reproduce across novices but are brittle and slow to write; loose specs are flexible but let two operators diverge.
- Prerequisite explicitness — how fully required inputs, calibrations, and roles are named. Naming them prevents silent substitution; assuming them is faster but invites drift.
- Acceptance-criteria form — pass/fail threshold, tolerance band, or exemplar comparison. Sharper criteria make "correct" checkable; vaguer ones invite dispute.
- Versioning discipline — whether the protocol itself is version-stamped so runs can cite the exact edition followed. Stamping ties each result to its governing method; leaving it unversioned makes "which protocol?" unanswerable.
- Readership target — written for an expert peer or a first-day trainee. The trainee version reproduces more reliably but is longer; the expert version is terse but assumes context.
When it helps, and when it misleads¶
Its strength is giving many runs a shared, checkable standard — a documented standard operating procedure lets work reproduce across people and time precisely because the method no longer lives in one person's hands.[n1] It is also the yardstick that makes deviations visible: you can only see that a run departed if there is a written intended path to depart from.
Its failure mode is documentation theater: a polished, official-looking protocol that no one actually follows, or that omits the tacit step everyone "just knows," so the written method and the real method quietly diverge. Because the document looks authoritative, it is trusted over the practice it has drifted from. The classic misuse is writing the protocol to satisfy an auditor rather than to guide the work. The guarding discipline is to keep the document synchronized with actual practice — reconciling it against as-run records and revising it when reality moves — so the standard stays a description of what is really done, not a fiction.
How it implements the components¶
reproducibility_target— the document opens by naming the result or procedure that must be repeatable, so "reproduced correctly" has a definite meaning.method_record— it lays out the canonical ordered method, required inputs, and roles as prose meant to be followed identically across runs.output_reference— it specifies the acceptance criteria and output checks a correct result must satisfy.
It does not capture what happened on any single run — the as-run deviations (exception_log) and interpretive notes (assumption_register) belong to its nearest twin, Lab Notebook Record; protocol documentation prescribes the method, the notebook records the instance.
Related¶
- Instantiates: Reproducibility Protocol — the protocol supplies the intended-method-and-target strand of the archetype.
- Sibling mechanisms: Lab Notebook Record · Containerized Environment Snapshot · Workflow Script or Pipeline · Reproducible Research Package · Replication Package · Version-Controlled Analysis · Rerun Checklist · Decision Log · Audit Trail
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Protocol Documentation operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it describes the ordered method, required inputs, assumptions, roles, and output checks that allow a process or analysis to be repeated.
Independent corroboration: The frozen evidence defines Protocol Documentation as 'Describes the ordered method, required inputs, assumptions, roles, and output checks that allow a process or analysis to be repeated', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Statistics & Experimental Design
Origin pattern: Historically ambiguous
Present-day reach: Universal
Rationale: The prospective record of method, inputs, assumptions, and output checks is rooted in experimental protocol and reproducible research practice.
Related originating lineages:
- Engineering & Design — Engineering test and process documentation independently formalized repeatable controlled procedures.
- Medicine & Healthcare — Clinical protocols institutionalized role, safety, and recordkeeping requirements.
Review resolution: Both blind reviewers agree on statistics_experimental_design as the primary origin. Explicit reconciliation resolves reported_ambiguity, alternate_origin_disagreement, origin_mode_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=universal records later applicability separately from origin breadth.
Attribution caveat: Prescriptive procedural documentation also has independent engineering and organizational lineages; the page's reproducibility emphasis favors experimental method. The mechanism is generic enough that no single modern discipline owns its full lineage.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] A standard operating procedure (SOP) is the established name for a documented, authoritative method written to be executed consistently across operators and time; its whole point is to move a procedure out of individual memory and into a shared, citable standard. ↩