Content types

Use one canonical name for each job. Synonyms are allowed as tags or search terms, but not as new top-level buckets.

Canonical types

Canonical name	Primary question	What the reader does
Playbook	”How do I execute this full outcome?”	Follow end to end.
SOP	”What is the approved standard way?”	Follow as policy-backed procedure.
Runbook	”What exact commands/checks do I run?”	Execute during an operation or incident.
Checklist	”Did I do everything?”	Tick off / verify.
Guide	”How does this task work?”	Read to learn one focused thing.
Handbook	”Where is everything about this area?”	Browse a domain reference hub.
Concept / Explainer	”What does this mean and why?”	Build understanding.
Research	”What did we find out?”	Review findings and evidence.
Case study	”What happened in a real example?”	Learn from an instance.
Blueprint	”What should be built and how is it structured?”	Read before building.
Template	”Give me the empty structure to start.”	Copy and fill.
Kit	”Give me the bundle.”	Download or copy many related files.
Cheat sheet	”Quick, what is the fact or command?”	Glance.
Reference	”What is the exact value, rule, or table?”	Look up.
Glossary	”What does this term mean?”	Look up definitions.
Prompt pack	”What prompts do I reuse?”	Copy prompts.
Directory entry	”Who or what exists?”	Browse, filter, compare.

Synonym map

Use this	Fold these into it
Playbook	workflow, recipe, end-to-end flow
SOP	standard procedure, protocol, official process
Runbook	incident steps, ops checklist, command procedure
Guide	how-to, tutorial, walkthrough
Handbook	manual, field guide, knowledge base
Concept / Explainer	theory, overview, primer
Research	findings, source notes, study, investigation
Blueprint	architecture, system design, map, plan
Template	boilerplate, starter, skeleton, scaffold
Kit	bundle, package, starter pack
Cheat sheet	quick reference, TLDR, crib sheet
Reference	command list, spec table, lookup page
Directory	catalog, index, database

Build shelf spectrum (playbook · runbook · SOP)

Beginners confuse these because all three can contain numbered steps. They differ by reader moment, not by file length:

Type	Reader question	Voice	Shape
Playbook	”Walk me through the full outcome — why and how.”	Teaching journey — phases, gates, context	Multi-phase folder
Runbook	”I know the drill — what do I run right now?”	Terse operator card — commands + checks, no teaching	Usually one short page
SOP	”What is the approved way we always do this?”	Policy-backed standard — compliance-ish	One file or small folder

Default for workflow docs (e.g. WF1–WF5): use a playbook on the Build shelf. Peel a runbook when one phase (rollback, restore, DNS cutover) should stand alone. Add an SOP only when the method is frozen and approval matters.

Full diagrams, Learn-vs-Build framing, and promotion rules: Type decisions (reference).

Confusing pairs

Pair	Decision rule
Playbook vs Guide	Re-read every time you execute the full outcome = Playbook (Build). Read once to learn one topic = Guide (Learn).
Playbook vs Runbook	Whole multi-phase journey with teaching = Playbook. One operation, exact commands, no narrative = Runbook.
SOP vs Runbook	Approved org-wide standard = SOP. Literal commands/checks in the moment = Runbook.
SOP vs Playbook	Playbook teaches and phases; SOP states the frozen approved method with less story.
Playbook vs Blueprint	Blueprint = design before build. Playbook = execute the build/deploy journey.
Checklist vs Runbook	Checklist verifies steps were done. Runbook tells you what to run. Often paired.
Blueprint vs Template	Blueprint is read. Template is copied.
Handbook vs Guide	Handbook is a whole area. Guide is one focused topic.
Cheat sheet vs Reference	Cheat sheet is glanceable memory aid. Reference is exact lookup.
Research vs Blueprint	Research preserves findings. Blueprint turns findings into a buildable design.

Recommendation

Keep SOP as a canonical type, but use it sparingly. Most solo-founder execution docs should be Playbooks (full journey) or Runbooks (one op). Reserve SOP for “this is the approved, repeatable, auditable way” documentation.