The empty daily-note tax
Almost everyone tries daily notes, and almost everyone quits within a few months, for the same reason: the blank page. You open today's note to a blinking cursor and a silent demand — what happened today? — and the honest answer, most days, is I don't fully remember, and reconstructing it is work. So you write a line or two, or nothing, and by Wednesday the day is gone. The habit dies not because journaling is worthless but because the cost of the first keystroke is too high and the payoff is deferred to a someday-review that never comes.
Here's the thing that fixes it, and it's not more discipline. The first draft of your day already exists — scattered across your bank, your calendar, your phone's location history, your photo library, your reading app, your wearable. You didn't have to remember any of it; those systems recorded it for you. The tax isn't that your day went unrecorded. It's that it was recorded in twenty places you never look. Stop typing the daily-note. Start enriching it.
The daily-note as a view, not a destination
The reframe that changes everything: your daily-note is not a place you type into. It's a view over your data — a rendered surface that a small script rebuilds each morning by pulling the day's facts from every source you've connected, and dropping them into the note as sections.
I check my enriched daily-note the way I used to check email. Not because I wrote it — I barely did — but because it tells me things: what I spent, where I went, who I met, what I read, how I slept, what I asked an AI. Two dozen sources feed one file per day, and the file becomes a memory-trigger dense enough to actually restart the memory. The blank page is gone because the page is never blank; by the time I open it, the machine has already written the parts a machine can write.
This is the same principle that runs under a well-built vault at every level: the database is a view, not the master. The daily-note is a view too — over your life's data instead of a table — and it follows the same rule. You don't hand-maintain a view; you rebuild it. What you do maintain is the source and the one thing the source can't hold: your judgment.
The two kinds of section, and the line you must never cross
This is the load-bearing distinction, and it's the one detail that decides whether an enriched daily-note is a gift or a disaster: not every section is the machine's to write.
A daily-note grows two kinds of section. Auto-sections are the ones a script owns — Transactions, Trips, Locations, Workouts, Activity. These are facts pulled from data, and the enrichment script rewrites them freely every morning, because there's nothing of yours to lose in them. Manual sections are yours and yours alone — Notes, Reflection, Decisions, Memory updates. These hold the things no data source knows: what you felt, what you decided, what a conversation actually meant. The script must never touch them.
The mechanism is a whitelist/blacklist, enforced by defense-in-depth: the enrichment parses the note's section headings, rewrites only the whitelisted auto-sections, and leaves everything else byte-for-byte untouched — with checks that fail loudly rather than overwrite when something's ambiguous. This isn't theoretical caution. It's a rule I learned the expensive way: an early version of the script overwrote a reflection paragraph I'd written — a genuine loss, gone. That incident is why the section-protection is now a hard, tested boundary and not a good intention. When code and a human co-own the same file, the boundary between what each may edit has to be explicit and machine-enforced, or the code will eventually eat the human's work. (This section-protection contract shows up anywhere scripts and people share a file — it's worth stating as its own pattern.)
Where the sources actually live
The two dozen sources aren't two dozen plugins. They're a handful of kinds of source, each queried the same way.
Some live in local analytical databases — DuckDB files holding transactions, fitness metrics, photos-with-EXIF, location history — queried with plain SQL for the day's rows. Some come through tool connections — calendar, mail, CRM, travel, reading highlights — pulled live via their APIs. Some are periodic exports — bank statements, receipts, wearable dumps — that land in a dropzone and get imported. And some are conversation logs — chat exports from AI sessions — parsed for the day's activity.
The point isn't the count; it's that adding a source isn't a plugin install, it's a query and a target section. "Give me today's transactions" becomes a ## Transactions block; "today's workouts" becomes a ## Workouts block. The enrichment script is a loop over sources, each contributing one section, all idempotent so re-running only refreshes what's stale. Twenty-three sources is twenty-three small, boring queries — not twenty-three integrations to maintain.
Events versus facts — the distinction that keeps it honest
Enriching daily-notes surfaces a modeling distinction worth naming, because getting it wrong makes the notes lie. There are two kinds of thing you might pull in, and they belong at different altitudes of the calendar.
Events are things that happened on a date — a transaction, a trip, a photo, a workout. They belong in the daily-note, because the date is the event. Facts are things that were true on a date but didn't happen on it — an active agreement, your current weight, an ongoing subscription. A fact doesn't belong smeared across every daily-note it was true for; it belongs in the weekly or monthly view, as context. Conflate them — drip a standing fact into all thirty daily-notes of a month — and you've turned a signal into noise and made the day-level record dishonest about what actually occurred. Events flow to days; facts surface in the rollups. (This is the same events-vs-facts line that data modelers draw in a warehouse, applied to a life.)
The cascade: the year that reviews itself
Because every day is a view over structured data, the rollups are free. The same enrichment pattern runs at week, month, quarter, and year — each level aggregating the level below. The week sees every workout and transaction beneath it; the month sees the trends; the year sees the shape. "Total active hours this year," "distance this quarter," "favorite photos of the month" are all one query away, because the data was structured going in.
The result is that the year-in-review nearly writes itself — not as a chore you dread each December, but as a rollup that's been accumulating all along. The retrospective you could never make time for becomes a query you already have. That inversion — capture gets cheaper, retrospect gets richer — is the entire return on building the view instead of typing the note.
What deliberately stays manual — and should
An honest system is clear about what it won't automate, because the boundary is the point. What doesn't auto-enrich: your emotions, your decisions, your conversations by content (the metadata that a call happened, yes; what was said and what you concluded, no), and the captures you intentionally make. These are exactly the high-value, irreducibly-human parts — and the enrichment leaves them alone on purpose, so that the note has room for them and you're never fighting a script for your own reflection.
That's the division of labor: the machine writes the facts, you write the meaning. The friction of capturing the day drops toward zero because the facts arrive on their own; the value of reflecting on it rises because you open the note anyway — to read what the machine wrote — and the blank space for your own thoughts is right there, protected, waiting.
Build the view; write only the meaning
The daily-note habit doesn't die because journaling is worthless. It dies because typing a day from memory into a blank page is a tax nobody keeps paying. The fix is structural, not motivational: recognize that the day's facts already exist in the systems that recorded them, build the daily-note as a view that pulls them in every morning, protect your manual sections with a hard boundary, and keep events at the day and facts in the rollups.
This is structure beats magic applied to memory and habit at once. The magic answer is a journaling app that somehow makes you want to write every day. The structural answer needs no willpower: let the machine draft the day from the data it already has, and reserve your effort for the one thing no data source will ever hold — what any of it meant. Your journal writes its own first draft. You write the only part that was ever really yours.
Part of the Structure Beats Magic series — the umbrella over two spokes: Mobile Data Auto-Pipeline (how the export-only sources get in) and Health Metrics in a Local DuckDB (one source, in depth). The day's facts land in its day-folder; the view-not-master principle is Your Database Is a View.