DBAdmin/brain/GEMINI.md

LLM Knowledge Base Schema: Personal Technical Knowledge Base

This document defines the structure, conventions, and workflows for maintaining the LLM Knowledge Base in this repository.

Overview

This knowledge base is an LLM-maintained knowledge base focused on AI, Databases, Programming, and Knowledge Management, integrated with Feynman's 12 Favorite Problems framework. The LLM writes and maintains all files under knowledge/. The human curates raw sources and directs queries.

The Core Idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent knowledge base — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing knowledge base — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

This is the key difference: the knowledge base is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The knowledge base keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the knowledge base yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time. Obsidian is the IDE; the LLM is the programmer; the knowledge base is the codebase.

Example Contexts

This pattern applies to a lot of different contexts:

• Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
• Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive knowledge base with an evolving thesis.
• Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect.
• Business/team: an internal knowledge base maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The knowledge base stays current because the LLM does the maintenance that no one on the team wants to do.
• Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you're accumulating knowledge over time and want it organized rather than scattered.

Architecture

There are three layers:

1. Raw sources (raw/) — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.
2. The knowledge base (knowledge/) — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.
3. The schema (this GEMINI.md file) — a document that tells the LLM how the knowledge base is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the knowledge base. This is the key configuration file — it's what makes the LLM a disciplined knowledge base maintainer rather than a generic chatbot.

Directory Layout

• raw/ — Immutable source documents (transcripts, articles, notes). Never modify these.
• knowledge/ — LLM-generated markdown files.
  • knowledge/summaries/ — One summary page per raw source document.
  • knowledge/concepts/ — Concept, strategy, and framework pages.
  • knowledge/entities/ — Entity pages (tools, technologies, organizations, products).
  • knowledge/syntheses/ — Comparison tables, decision frameworks, cross-cutting analyses.
  • knowledge/journal/ — Research or session journal entries.
  • knowledge/presentations/ — Marp slide decks generated from knowledge base content.
  • knowledge/feynman_problems.md — Central tracking of long-term problems.
  • knowledge/index.md — Master catalog and portal to thematic indices.
  • knowledge/indices/ — Thematic and type-based index files.
  • knowledge/log.md — Append-only activity log.

File Naming & Format

• Naming: All lowercase, hyphens for word separation: concept-name.md. No spaces or special characters.
• Frontmatter:

  ---
  title: "Page Title"
  type: concept | entity | summary | synthesis
  tags: [tag1, tag2]
  created: YYYY-MM-DD
  updated: YYYY-MM-DD
  sources: ["[[Source Link]]"]
  confidence: high | medium | low
  ---
  

Required Sections by Page Type

Summary pages (knowledge/summaries/)

• ## Key Points — Bulleted list of main claims/ideas.
• ## Relevant Concepts — Links to concept pages this source touches.
• ## Source Metadata — Type of source, author/speaker, date, URL or identifier.

Concept pages (knowledge/concepts/)

• ## Definition — One-paragraph plain-English definition.
• ## How It Works — Mechanics, process, or structure of the concept.
• ## Key Parameters — Important variables, dimensions, or factors.
• ## When To Use — Situations and contexts where this concept applies.
• ## Risks & Pitfalls — Known failure modes, common mistakes, limitations.
• ## Related Concepts — Knowledge base links to related pages.
• ## Sources — Which raw sources inform this page.

Entity pages (knowledge/entities/)

• ## Overview — What this entity is.
• ## Characteristics — Key properties, attributes, structure.
• ## Common Strategies — Links to concept pages for strategies or methods associated with this entity.
• ## Related Entities — Links to related entity pages.

Feynman's 12 Problems Framework

We maintain a list of ~12 "Favorite Problems" in knowledge/feynman_problems.md. Every new piece of information is checked against this list to see if it offers a new insight or connection.

Operations / Workflows

1. Ingest

You drop a new source into the raw collection and tell the LLM to process it. An example flow:

1. The LLM reads the raw source completely.
2. The LLM discusses key takeaways with you, and writes a summary page in the knowledge base (knowledge/summaries/<source-slug>.md).
3. Identify all concepts, entities, and strategies mentioned.
4. Feynman Check: Compare against knowledge/feynman_problems.md and update it if connections are found.
5. Create/Update concept and entity pages across the knowledge base using the required sections. A single source might touch 10-15 knowledge base pages.
6. Add cross-links in both directions between all touched pages.
7. Update knowledge/log.md and relevant indices in knowledge/indices/.
8. Update knowledge/index.md if new categories are needed.
9. Flag any contradictions with existing content.

Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision.

2. Query

You ask questions against the knowledge base. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations.

1. Read knowledge/index.md and relevant thematic indices to find pages.
2. Synthesize an answer citing specific pages with knowledge base links.
3. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart, or a synthesis.
4. Crucial insight: good answers can be filed back into the knowledge base as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do. Create a synthesis page in knowledge/syntheses/.

3. Lint

Periodically, ask the LLM to health-check the knowledge base. Look for:

1. Contradictions between pages.
2. Stale claims that newer sources have superseded.
3. Orphan pages with no inbound links.
4. Important concepts mentioned but lacking their own page.
5. Missing cross-references.
6. Data gaps that could be filled with a web search.

The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the knowledge base healthy as it grows.

Indexing and Logging

Two special files help the LLM (and you) navigate the knowledge base as it grows. They serve different purposes:

index.md is content-oriented. It's a catalog of everything in the knowledge base — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

log.md is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [YYYY-MM-DD] ingest | Article Title), the log becomes parseable with simple unix tools. The log gives you a timeline of the knowledge base's evolution and helps the LLM understand what's been done recently.

Why this works

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon knowledge bases because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The knowledge base stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.

Rules

• Never modify files in raw/.
• All dates in ISO 8601 format: YYYY-MM-DD.
• Use Obsidian-style links: [[concepts/concept-name]].
• Confidence levels: high (multiple sources), medium (single source), low (speculative).
• Polish language for content, English/Technical slugs for filenames.

Optional: CLI tools, Tips and tricks

• Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
• Download images locally. In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey. After clipping an article, hit the hotkey and all images get downloaded to local disk. This lets the LLM view and reference images directly instead of relying on URLs that may break.
• Obsidian's graph view is the best way to see the shape of your knowledge base — what's connected to what, which pages are hubs, which are orphans.
• Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from knowledge base content.
• Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to knowledge base pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
• qmd is a good option for proper search: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI and an MCP server.
• The knowledge base is just a git repo of markdown files. You get version history, branching, and collaboration for free.