Journals and datetrees

Org prescribes no journal layout; you choose one by how you expect to retrieve what you wrote.

Org does not prescribe one journal layout. The shapes trade different costs:

• A single file makes chronological search and capture simple but grows indefinitely.
• Yearly files keep manageable boundaries and easy archiving.
• Monthly files reduce size further but scatter cross-month context.
• Daily files integrate naturally with file-based PKM, at the cost of many files.
• Datetrees create year/month/day heading hierarchies inside one file.

Datetrees and capture

A datetree is a nested outline of dates. The capture template introduced earlier uses file+olp+datetree, which creates a date heading only when you first capture under it:

* 2026
** 2026-09 September
*** 2026-09-01 Tuesday
**** Standup notes
Deployment slipped to Thursday.

Journal timestamps should generally be inactive, written [2026-09-01 Tue] rather than <2026-09-01 Tue>, so a stream of daily entries does not flood the Agenda.

Choose by retrieval

Pick a layout by how you expect to find things again. If you remember when something happened, chronological journals work well; scanning by date lands you on the entry. If you remember what project it belonged to, a raw journal is a poor index: capture the entry with a link back to the project, or refile the durable conclusion into project notes where you will actually look for it.

A journal is not yet knowledge

Writing entries every day accumulates a record, not a knowledge base. The record is raw material. Synthesis (pulling recurring observations into a reusable note, discarding the rest) is what turns a journal into something you consult later. Preserve the conclusions; you do not need to preserve every daily line that led to them.

Summary. From a single growing file to yearly, monthly, daily files, or an in-file datetree, each journal shape trades search convenience against boundaries and file count. A journal becomes knowledge only when you synthesize it.