How I Turn What I Read Into Something I Can Query

I read a lot of useful things, and for years my system for keeping them was a bookmark and good intentions — which is to say, a graveyard. The article I “saved for later” was gone the moment I closed the tab, because a saved link isn’t knowledge, it’s a promise to do the actual work later, and later never comes. What finally fixed it is a workflow with a clear split: capture the raw source once, then compile it into notes I can query — so that months later I ask my notes a question instead of trying to re-find and re-read the original. Here’s the workflow, because the shape of it is more portable than any tool.

Save the source, but don’t mistake saving for learning

Step one is still to capture the thing — but capture it properly and know that capturing isn’t the point. When something’s worth keeping, I grab the actual content (not just a URL that’ll rot) and store it as an immutable raw copy: the original, untouched, so I can always return to what was really said. That raw archive matters — it’s ground truth — but I’m clear-eyed that dropping it in a folder has taught me nothing yet. It’s a candidate for knowledge, not knowledge. The graveyard is built entirely out of things people saved and mistook the saving for learning.

A saved link is a promise to learn something later. A compiled note is the thing you actually learned. Only one of them survives contact with a busy month.

Compile it: rewrite, connect, file

The step that does the real work — the step everyone skips — is compiling the raw source into my knowledge base. Concretely, that means:

• Summarize it in my own words. Not a copy, not a highlight dump — a restatement of what it actually says and why it matters to me. Rewriting in my own words is the part that forces understanding; if I can’t restate it, I didn’t get it, and that’s useful to discover now.
• Connect it to what I already have. This is the highest-value move and the one that turns a pile into a web: link the new material to existing notes, update the concept notes it touches, note where it agrees or disagrees with something I already believed. A note that links to nothing is nearly worthless later; a note wired into the graph surfaces exactly when I need it.
• File it where I’ll find it. Put it where my future self, chasing a question, will actually trip over it — connected to the projects and topics it bears on.

The raw source stays untouched; the compiled note is the new, connected thing. That separation — immutable source, synthesized note — is what lets me trust the notes and always check them against the original. It’s the difference between compiling your notes and endlessly re-reading them: compiling pays the understanding cost once, up front, so retrieval is cheap forever after.

Then query the notes, not the sources

The whole point of the compile step is what it enables at the other end: months later, when a question comes up, I ask my notes, not the original sources. The understanding is already extracted, already in my words, already connected to everything related — so I get a synthesized answer in seconds instead of re-finding an article, re-reading it, and re-deriving the point I already worked out once. That’s the payoff that makes the up-front compile worth it: you do the reading-and-understanding work a single time, and every future question draws on the compiled result.

It also reframes what a note is for. A note earns its place only if it’ll actually get used — to answer a question, feed something I’m writing, or change a decision. A note that can’t do any of those is just tidy hoarding, which is why I hold notes to the bar of being an asset only once they’re used, and why the compile step is aimed squarely at future retrieval, not at feeling productive today.

Where automation fits (and where it doesn’t)

The compiling — reading, summarizing, finding the connections, updating the linked pages — is exactly the kind of tedious, mechanical work that’s a chore for a human and a natural fit for an LLM, which is what makes a second brain that files itself possible: hand the source to the machine, let it do the compile-and-link, keep the human for choosing what’s worth ingesting and asking the questions. But you don’t need any of that to get the benefit — the workflow is the point, and it works with nothing but a text editor and the discipline to compile instead of just save.

The one habit that makes it stick

If I had to compress it to a single change: stop asking “how do I save this?” and start asking “how will I use this?” Saving optimizes for the moment of reading and produces a graveyard. Compiling optimizes for the moment of needing it later and produces a knowledge base that answers questions. Same sources, completely different outcome — and the difference is entirely in whether you did the compile step or told yourself you’d do it later. Do it now, in your own words, connected to everything else, and “what I read” quietly becomes “what I know.” It’s the whole reason I write everything down in the first place. If you’ve got a capture-to-query workflow that beat your own bookmark graveyard, I’d like to hear how it works.