PowerUp Coaching — Living Knowledge Base

Your Second Brain Has Three Layers and You Are Only Using One

4 min read

Topic

The three retrieval layers every personal knowledge base should have — keyword, graph, semantic — and why most practitioners are only using one of them, leaving most of their knowledge inaccessible.

Target Reader

Coaches, consultants, and knowledge entrepreneurs who are building or maintaining a personal knowledge base (Obsidian, Notion, Roam, or similar). AI maturity level: early-to-intermediate. Specific friction: “My knowledge base returns stuff when I search, but I can’t find things I know are in there, and the results feel shallow.”

The Fear / Frustration / Want / Aspiration

  • Fear: I’ve spent hours building a knowledge base and it still doesn’t feel smart or useful
  • Frustration: I search for something I know I put in there and either don’t find it or get too many results
  • Want: My accumulated knowledge to be actually retrievable in the moment I need it
  • Aspiration: A personal second brain that thinks alongside me rather than just storing things

Before State

Relies on keyword search for everything. May have semantic retrieval (NotebookLM) for some content. Has no knowledge graph / relationship layer — files are stored but not connected. Feels like the system is shallow even when there’s good content in it.

After State

Understands the three-layer model and why each layer is necessary. Has a framework for diagnosing which layer is missing in their current setup. Knows what a taxonomy is for and what to invest in first. Has concrete next steps for adding the missing layer(s).

Narrative Arc

Most second brains are built in a single dimension — words in, keyword search out. The reader assumes they need better tools, more content, or better organization. The reveal: they need a different architecture. The three-layer model isn’t complex — it’s a natural extension of what they’re already doing — and it changes what’s possible to retrieve.

Core Argument

Optimal knowledge retrieval requires three complementary layers — keyword, graph, and semantic — and most practitioners are missing at least one. The missing layer is almost always the knowledge graph, and it’s the one that enables the most powerful queries.

Key Evidence / Examples

  • Lou’s claim from May 7: the hybrid knowledge graph + Markdown approach approaches RAG performance at ~96.6% up to a certain vault scale, while enabling temporal queries that vector retrieval can’t do
  • Kasimir’s five-pillar taxonomy enabling 500 files to be navigated across 4 search dimensions
  • The specific failure mode: searching for “client retention” vs. “churn reduction” — keyword fails; semantic retrieval surfaces it; graph retrieval can connect it to a specific client’s case and timeframe
  • Insight - RAG Is Raw Material, Not Answers — Design for the Right Retrieval Architecture

Proposed Structure (5–7 beats)

  1. The search frustration. You know you put something in there. You can’t find it. Or you find too many things. This is a layer problem, not a content problem.
  2. The three layers, simply. Keyword: find exact words. Graph: follow relationships. Semantic: find similar meaning. Each retrieves something different.
  3. Why keyword alone fails. You don’t always search with the same words you wrote with. And keyword can’t tell you what connects two things.
  4. Why semantic alone fails. Similarity is not relevance. NotebookLM surfaces what sounds like your question — not what is actually connected to your specific client, case, or constraint.
  5. What the graph layer adds. The queries only graphs can answer: “What did I think about this in the context of that person?” “What changed between June and November?” “What connects these two frameworks?” These are the questions that make a second brain actually useful.
  6. What to build first. Taxonomy is the highest-leverage investment. Not more content. Not a better search plugin. A taxonomy that defines the entities and relationships in your knowledge domain.
  7. The AI does the tagging. You define the taxonomy; Claude Code does the classification. The overhead that previously made knowledge graph maintenance impractical is now gone.

Editorial Notes

Pair with the inference engine brief — they’re complementary: this one explains the architecture; that one explains the mode switch. Avoid getting technical about vector embedding implementations. The audience needs conceptual clarity, not implementation detail. The 96.6% claim needs a footnote caveat (“up to a certain scale”) — don’t overstate it.

Next Step

  • Approved for drafting
  • Needs revision
  • Deprioritised

Graph View

Backlinks