How I chose a note format future-me and an LLM can both read

I am not going to tell you which note format I settled on until the end. I want to show you how I picked it, because the decision is reusable and the answer probably isn't. I have kept notes as a solo developer for about three years, and for most of that time they had exactly one reader: a slightly tired version of me, three weeks later, trying to remember why I changed something. Then the second reader showed up. Now I paste my own notes into Claude and Cursor as context two or three times a week, and the model reads them cold, with no idea what any of my private shorthand meant. The day I started doing that, some of my formats quietly fell apart.

So I did the boring thing and ran an actual decision instead of drifting into a habit. Here is the whole thing, axes and weights and rejected options included.

Two constraints, ranked before I looked at any format:

• Capture friction comes first. A format I won't use at the end of a bad day is worth nothing, no matter how elegant it reads.
• Machine-legibility comes second. The notes have to survive being pasted into a model with zero cleanup, or the second reader gets nothing.

The five formats I actually weighed

Freeform prose. Just write paragraphs. Lowest possible friction going in: you type what you think. The cost shows up later. Future-me can't skim a wall of prose, and a model handed three months of undated paragraphs struggles to tell where one thought ends and the next begins. It reads everything as one blurry context.

Per-note structured metadata. Every note gets a small header: a title field, tags, a type, a date, maybe a status. This is lovely to query and genuinely nice for a machine, which likes named fields. But the friction is brutal at exactly the wrong moment. To write one line about a bug, I first have to decide its title and its type and its tags. Most nights I just wouldn't, and an unwritten note beats a well-formatted one zero times out of a hundred.

Full Zettelkasten. Atomic notes, stable IDs, dense links between them. In theory the richest structure of the five, and the only one that builds a real graph. In practice it asks me to do link-maintenance forever, and I already ran this experiment and quit it. I hand-kept around 1,400 Luhmann-style IDs for three years and then deleted every one of them, and my notes got better, not worse. That result is still fresh, so Zettelkasten started this round with a scar.

Timestamped one-liners. Plain text, one thought per line, each line beginning with a date and a concrete noun or verb. 2026-03-14 fixed cold-start regression: moved the keychain read off the launch path. No header, no fields, no links. It looks almost too simple to count as a system.

Question-and-answer notes. Each note is a question with an answer underneath, like a private FAQ. Wonderful for the notes that are genuinely questions. Terrible ceremony for the eighty percent that are just an observation I want to park before it evaporates.

Which axes actually decide it?

I scored the five on the five things I care about. Low, medium, high — where for maintenance cost, low is good.

The table alone doesn't pick a winner, because the columns are not worth the same. A format that scores high on graph value and high on friction is not a tie against one that scores low on both — it depends entirely on how much I weight friction. Which is the actual decision.

How I weighted the axes

I gave capture friction more weight than everything else combined. This is not a principled information-theory stance. It is a fact about me: I am one person, I capture at the worst moments, and any friction at capture time doesn't make my notes tidier, it makes them not exist. So friction dominates.

Machine-legibility came second and it is the axis that changed since last year. A note is now something a model reads, and models turn out to have a clear preference that surprised me: they do not need my metadata nearly as much as they need my ordering and my verbs. A timestamp gives a model sequence for free. A leading verb gives it the topic of the line without a tags field. Plain dated lines read to a model almost like a commit log, and models are very good at commit logs.

Future-me skimming came third, maintenance cost fourth as a penalty, and graph value came dead last. That last one is the deliberate, uncomfortable trade I want to name out loud: I am choosing a format that will never build me a navigable web of linked ideas. I am giving up the graph on purpose. I decided I almost never actually traverse a knowledge graph; what I actually do is search for a line and read the twenty lines around it. So I optimized for the thing I do, not the thing I once imagined I'd do.

A concrete example of the weighting doing real work. Structured metadata scored high on machine-legibility and I was tempted, because a model does love a clean type: bug, tags: [ios, launch] header. But run it through the weights and it collapses: the header buys a little legibility I mostly already get from the verb, and it costs friction on the one axis I refuse to spend on. A format can be objectively richer and still lose, because the axis it wins is the axis I priced cheap and the axis it loses is the one I priced above everything. Writing the weights down first is what stopped me from being seduced by the format that demos best.

Does the machine really change the answer?

It is worth being honest about how much the second reader actually moved the decision, because it would be easy to overstate it. Three years ago, with only future-me reading, I would probably have landed on timestamped lines anyway — skimmability and low friction were already pulling that way. What the model added was a second, independent vote for the same format, and it retired one candidate I might otherwise have kept flirting with. I used to assume that the day notes became machine-input, I'd need more structure, not less. The opposite happened. The model reads my least-structured format the most comfortably, because plain dated lines look like exactly the kind of sequential, terse log that these systems were trained on oceans of. The machine didn't ask me to build it a schema. It asked me to stop building one.

What I actually picked

Timestamped one-liners. Plain text, one thought per line, each line led by a date and a concrete noun or verb, no per-note structure at all. The lines accumulate in a folder of dated markdown files, and that folder is the whole system. There is no schema to remember and nothing to maintain.

It won capture friction outright, which was most of the weight, because writing a note is just typing a line. It won machine-legibility for a reason I didn't predict before I tested it: when I paste a month of these lines into a model, I paste them raw, no cleanup, and the model handles them better than it handled my old structured notes, because the timestamps give it order and the leading verbs give it topics. It won future-me skimming because a column of dated first-words is the most skimmable thing I've ever kept. It lost graph value completely, and I let it, because that was the trade I'd already decided to make.

Why did the other four lose?

Structured metadata lost on the only axis I refused to compromise: it taxes the moment of capture, and taxed capture is skipped capture. Zettelkasten lost because I had already paid its maintenance cost for three years and written about deleting every one of those IDs; choosing it again would have meant un-learning my own result. Question-and-answer lost because it's a great format wearing the wrong uniform for daily use — I kept it, but only as a thing I reach for deliberately, not as the default. Freeform prose lost on both readers at once: unskimmable for me, unsegmentable for the model.

None of these are bad formats. They lost against my specific weights. Someone who traverses a real graph every day, or who queries structured fields constantly, should weight the axes differently and would correctly pick something else. That's the point of showing the weights instead of just the answer.

The checks I'll run in three months

A decision journal is worthless if you never check it, so here is how I'll know I chose wrong. Did I stop capturing? If the friction of even a dated line turns out to be too much on bad days, the format failed at its one job. Did a paste into a model need cleanup? If I find myself reformatting notes before they're useful as context, machine-legibility wasn't as high as I scored it. And did I ever badly want a link I didn't have? If I keep reaching for a connection between two lines and the flat format can't give it to me, then I underweighted graph value and I owe myself a rematch.

A few questions I had to answer first

Won't a model prefer clean structured data over plain lines? I assumed yes and was wrong in practice. For long-context pasting, ordering and short topical verbs did more work than named fields, and they cost me nothing to produce. A model reading dated lines reconstructs the structure it needs; it does not need me to pre-chew it.

Isn't plain text going to rot without a system? It would if it had no anchor. The timestamp is the system. Every line is findable by date and by its first word, which is all the retrieval I've ever actually performed on my own notes.

What about tags? I don't add them at capture time, because that's the friction I'm avoiding. When I need a category, I search for the verb. The leading word is a tag that costs nothing to write.

If you keep notes for both a human and a machine now, I'd like to know: what is the one piece of structure you add at capture time that has actually paid off later when you fed the notes to a model — and what did you add once, feel clever about, and end up ripping out?

I build a small iOS app by myself, and most of it is an argument that the moment of capture should cost almost nothing. I write here every few days about the parts of doing that alone that I'm still getting wrong. If you're curious where these dated lines eventually land, it's here.