The problem — Computational-microscopy pipelines fail silently when someone re-runs an analysis on new hardware or six months later: different software versions, different job ordering, missing intermediate files. The failure is rarely dramatic; you simply get different numbers and no way to know which run to trust.
What it is / how it works — Snakemake is a workflow management system that extends Python syntax with rules — declarations that say "to produce this output, apply this transformation to these inputs." From those rules it builds a directed acyclic graph (DAG) of jobs, resolves dependencies automatically by matching filename patterns, and executes only the outdated portions of the graph. The same workflow definition scales from a single workstation to SLURM, AWS Batch, Google Batch, or Kubernetes clusters via a plugin architecture — no code change required. Per-rule Conda environments or Singularity containers pin the software stack, so the run on a colleague's cluster is byte-equivalent to the one on your laptop. Snakemake also records inputs, outputs, parameters, code, and software for every executed job, emitting an interactive HTML provenance report — the basis for Verification — A Pipeline You Can Re-Run.
In bioimaging, Snakemake is the natural home for the multi-stage transforms described in From Research Script to Production Pipeline: illumination correction, segmentation, feature extraction, batch correction, and readout each become a rule, connected by well-typed intermediate files. Run manifests flow naturally into each rule's params block, keeping the link between raw acquisitions and downstream results traceable (see Metadata & Provenance: The Run Manifest).
Where it breaks — DAG inference from filename patterns is elegant but fragile when file-naming conventions drift across experiments or when a rule produces outputs whose names depend on runtime data. Large graphs (tens of thousands of jobs) are handled, but profiling shows runtime and memory grow linearly, so job-count discipline matters at scale. The determinism guarantee depends entirely on the workflow author: non-deterministic steps (random seeds, network calls inside rules, mutable reference databases) can produce different results on re-run even when Snakemake reports the workflow as up-to-date.