Concepts
1 Introduction
1.1 Who this is for
Two readers, and the book is arranged so neither has to wade through the other’s material.
The first is new to the field: comfortable with a terminal and some programming, but meeting sequence alignment, variant calling or single-cell analysis for the first time. For that reader, concepts come first and nothing is assumed. A term in bold is being defined right there.
The second has been doing this for years and wants to know what moved. The tooling landscape here turns over faster than any textbook cycle, and most of what is written down is either a decade stale or a single tool’s own documentation arguing for itself. For that reader, the implementation chapters and What changed are the entry points.
1.2 How the book is organized
Each subject is a part containing two chapters: concepts, then implementations. They are separate files, not two halves of one page, and that is deliberate.
Concepts age slowly. What a Burrows–Wheeler index does, why mapping quality is not alignment score, why spliced alignment is a different problem from contiguous alignment — none of that will be different in a decade.
Tool recommendations age in months. Keeping them in their own chapters means a revision touches only those files, each one carries its own review date, and a reader can see at a glance how fresh the advice is. It also means the stale-content risk is confined to the chapters that admit to it, rather than smeared across the whole book.
A teal badge under the chapter title marks a concepts chapter and a magenta one marks an implementations chapter. The same two colors carry the section rails and the tool cards throughout.
1.3 How to read a tool page
Every implementation chapter is generated from a machine-readable registry rather than written out by hand, which is what makes periodic revision tractable. Four things on those pages carry specific meanings — the verdict, the upstream status, the date beside it, and the language chips — and the Preface defines each of them. It is one page, it is the contract the tool survey runs on, and reading it once will save you misreading a page later.
The short version: the verdict is the book’s advice and never appears without a rationale; the status is a fact about the project and is independent of the advice; the date beside the status is the evidence for it; and the chips say what a tool supports rather than what it lacks.
1.4 What this book does not do
It does not benchmark. Where a speed or accuracy claim appears it is attributed to a published comparison, not measured here — a benchmark that is not maintained is worse than none, and this book is committed to maintaining what it publishes.
It does not evaluate expensive code. Some pages show commands you would run on real data; those are illustrative, and the book does not claim to have executed them against a genome at build time.
It is not a protocol. Knowing that minimap2 -x map-ont is the current default does not tell you whether your experiment was designed correctly.
It does not survey general developer infrastructure — package managers, container runtimes, editors. The Preface explains why that boundary is where it is, and it is a stronger reason than tidiness.