Concepts

Not a vector database. Not an app's storage. Folders and .md files, with YAML at the top of each one.

The reason is not nostalgia for plain text. It is that you can read it, edit it in any editor, git log it, and walk away with it. Delete the server and your brain is still there and still useful. A brain you cannot read is a brain you cannot trust, and trust is the entire point of a thing you feed your unpublished thinking to.

The repo has eight directories, and each has one job:

• INDEX.md, the catalog. One line per entity. Read first, always.
• identity/, who you are, how you write, what you believe.
• knowledge/, the distilled notes. The retrieval workhorse.
• projects/, one card per project.
• content-catalog/, what you have published, for remix questions.
• lenses/, named retrieval scopes.
• raw/, full sources, archived. Almost never loaded.
• eval/, the falsification test for your own schema changes.

CLAUDE.md at the root of your brain is the contract. It is what makes an agent's retrieval trustworthy instead of improvised: the schema, the visibility rules, the taxonomy, the compiler rules, the reader rules.

Some of it is structure you inherit. Some of it is yours:

The contract carries a contract-version, currently 1.0. Your brain is a copy of the template and never auto-updates, so that field records which contract your copy speaks. Being straight about the current state: nothing reads it yet. The warn-on-mismatch behaviour is designed and not built.

Every note in knowledge/ is one of four kinds:

Two body rules do most of the work. One idea per note, so two ideas means two notes. And 5 to 15 lines, because a note is a retrieval unit, not an essay.

The third rule is the one that makes any of this worth doing. Voice is sacred. Every take and every story must carry at least one verbatim quote of your actual words, marked > VERBATIM:. The agent paraphrases around it, never instead of it. That quote is what survives retrieval, and it is why an answer comes back sounding like you rather than like an assistant summarising you.

Which brings up the part people skip. Your three identity/ files matter more than any single note. They ship empty, they load on nearly every retrieval, and until they are filled an agent has your positions but not your voice. Ask a question with them still blank and the reader answers correctly, then volunteers that it cannot write in the owner's voice yet. Filling them is about twenty minutes and it changes more than the next ten notes will.

Every note carries one of three visibilities:

• public, derived from things you already published. Safe for any consumer, including an audience-facing bot.
• agents-only, derived from source code, planning docs, unpublished thinking. Your own agents, nobody else's.
• private, never surfaced in generated output at all. Background only.

The default when the feeder is unsure is agents-only. Deny by default, and anything genuinely unclassified resolves to private.

Now the part that is easy to say and hard to mean. "Enforced server-side" here does not mean a filter runs on the way out. It means each tier is a separate materialized snapshot, built when your brain is indexed. A public caller is reading a smaller copy of your brain that never contained the note in the first place.

The difference shows up at the boundary. Ask a public key for a note that really exists one tier up, and ask it for a note that does not exist at all, and you get the same status code and the same sentence back. There is no "exists but you may not have it", because that sentence is itself a disclosure: given enough guesses it maps a brain you cannot read.

Change your mind and the old note stays. It gets marked superseded and it points at whatever replaced it.

This is enforced, not encouraged. The proposal format an agent writes has only create and update in it, there is no delete action to reach for, and emptying a file is treated as deleting it and refused.

You end up with a record of how your thinking moved rather than only where it landed. That is worth keeping: the fact that you changed your mind about something, and when, is often the more interesting note. Retrieval is not cluttered by it, because a reader agent is told to treat superseded notes as history and never as a current position.

A lens is a named retrieval scope. A small file that says: for this kind of task, these topics, these note kinds, this visibility ceiling, these identity files.

---
lens: building-in-public
topics: [build-in-public, open-source, tools, engineering-thinking]
types: all
visibility-ceiling: public
identity: [core, beliefs]
---

That visibility-ceiling is doing real work. A lens for audience-facing content is capped at public, so a retrieval through it cannot reach your unpublished thinking even if the key could.

Lenses focus, they do not censor. The primary topics are where the agent looks first, not a wall. Any topic is still reachable when the task clearly needs it.

The advice worth taking: a good lens is discovered, not designed. Do not sit down and plan six of them. Notice which retrievals keep pulling the same cluster of topics, then name that. The template ships one example, and you are meant to delete it once you know what your agents actually keep asking for.