how this works
The second brain, and the choices behind it
The interesting part of this site is a chatbot that answers questions about me. Building it well meant making real engineering decisions — and being able to defend them. That's the point of this page: the bot both tells you about me and shows you how I work.
- 01
You ask a question
The chat UI streams your question to a server route. Nothing about the model or my data touches the browser — the API key and the context live server-side only.
- 02
The gate runs first — and fails closed
Before any model call, the route checks that you're verified, rate-limits per person, and caps input length. An unauthorized or over-limit request never reaches the model, so it never costs anything.
- 03
A fixed context, cached as one frozen prefix
My whole background is assembled into a single context block and cached. Every question reuses the same cached prefix — which is what makes it fast and cheap, and why the answers stay grounded in the same source of truth.
- 04
The model answers — only from what it's given
It's instructed to answer strictly from the provided background, to say when it doesn't know rather than invent, and to stay on script. A test suite checks exactly that on every change.
why not RAG?
The obvious-sounding move is retrieval — chunk everything, embed it, fetch the relevant bits per question. I deliberately didn't. One person's background fits comfortably in a modern context window, and handing the model the whole thing gives sharper, less fragmented answers than retrieving three chunks and hoping the right one made the cut — for less moving machinery.
The content is kept in clean, separate files, so if the corpus ever outgrows the context window, adding retrieval is a small, isolated change rather than a rewrite. Reaching for the fancier tool wouldn't have made the answers better here — knowing when not to is the actual signal.