Six systems from the same primitives

A personal GTD setup, a release plan, an incident log, and a book manuscript are the same headings, timestamps, and properties pointed at different jobs.

The point of learning the primitives is that you rarely need new ones. Capture, refile, Agenda, links, properties, timestamps, and Babel recombine into whole working systems. What changes between systems is not the machinery but which external source of truth each one respects.

Personal system

A durable layout is six files under ~/org/:

~/org/
├── inbox.org      quick unprocessed capture
├── projects.org   outcomes and next actions
├── areas.org      recurring responsibilities
├── notes.org      durable reference notes
├── journal.org    chronological record
└── archive.org    inactive material

Capture to inbox.org. During daily review, clarify, refile, schedule only date-bound work, and choose a small number of NEXT actions. Weekly, inspect projects without next actions, future deadlines, waiting items, and clock data. Archive completed subtrees with C-c C-x C-a according to your archive policy.

Development, sysadmin, business

One project subtree can hold a requirement, source links, decisions, TODOs, a deployment checklist, a test-output block, and release notes. Link to Git issues rather than duplicating team state; keep destructive deployment commands confirmable and outside automatic export.

For system administration, keep server inventory as properties or tables, recurring maintenance as TODOs, and incident timelines as inactive timestamps. Link to the secret manager; never store plaintext credentials. Business management captures meetings into dated headings, records decisions separately from discussion, and assigns OWNER and due date to actions surfaced through Agenda. Org suits a small owner-operated system; a team needing permissions, notifications, and simultaneous editing likely needs a collaborative service.

Research and writing a book

Research keeps bibliography, reading notes with citation keys, immutable data, named Babel blocks, generated figures, and interpretation together. Pin environments, rebuild cleanly, and export the article. Org organizes the narrative; it does not replace domain validation or peer review.

A book uses a master file, chapter includes, an images directory, BibTeX data, custom IDs, and Git. Capture research into an inbox, refile verified notes into chapter research, draft without executing untrusted code, and export HTML frequently with PDF at milestones. A release tag should identify exact prose, bibliography, generated assets, and build environment.

The selection questions

Before adding structure to any of these, answer: which external system remains authoritative; what must surface by date, state, tag, or property; which data is too sensitive for this repository; which outputs must be reproducible; who collaborates, and do they use Emacs; what is the restore path after device loss; and which metadata actually changes a decision. If the answers are unclear, keep the workflow small. Structure can grow later without migration drama because the source is text.

Summary. Six working systems (personal, development, sysadmin, business, research, and book) reuse capture, refile, Agenda, links, and Babel. Each keeps its domain's real source of truth outside Org and lets Org organize the narrative around it.