Building a Personal Data Warehouse That an AI Can Actually Use

Last week I asked Claude for help preparing for a difficult conversation. It gave me a therapist's greatest hits: active listening, I-statements, validate their feelings. Technically correct. Completely useless.

The useful context exists. It is in notes I have written about this situation: patterns, history, what has and hasn't worked before. It is in playbooks I have built for navigating exactly these kinds of conversations. It is in frameworks I have distilled over years. All of it lives in an Obsidian vault that Claude cannot see.

I built Life Hub to give an AI assistant access to my personal data. It works. Claude can log my habits, check my infrastructure status, query my sleep patterns. But those tools cover maybe 20% of the context that would make an AI assistant genuinely useful. The other 80% is sitting in the vault, organized and waiting.

What Exists Today

For readers who missed the implementation post: Life Hub is a FastAPI application running on my homelab Kubernetes cluster. It serves an HTMX dashboard for humans and an MCP server for AI assistants, backed by SQLite.

Fourteen MCP tools let Claude interact with structured personal data: logging habits, recording mood, checking infrastructure monitors, querying sleep patterns, pulling reading stats from Miniflux, music activity from Navidrome, GitHub contributions, and finance summaries. Seven collectors pull data from external services and push it into the system via REST endpoints.

This is not theoretical. I use it daily. Claude can tell me I have slept an average of 6.8 hours this week, that my Kubernetes cluster has one monitor in warning state, and that I have read 23 articles in the last seven days. It can log that today's mood is a 7 and I meditated this morning.

What it cannot do is read the knowledge base that actually makes advice useful. It cannot reference the frameworks I have built for making decisions. It cannot check my calendar to know what is happening this week. It cannot pull up relevant context about a situation I have already thought through and documented.

The collectors are fine. The problem is scope.

The Gap: What an AI Actually Needs

Three categories of context live outside the system entirely.

Relational context. Who are the people involved in a situation? What is the history? What has worked before and what hasn't? This kind of context lives in notes I maintain but cannot surface to an AI. So it gives me generic advice calibrated to a generic situation, when the specifics are what actually matter.

Calendar. What is actually happening this week? Meetings, deadlines, commitments, travel. Currently invisible. An AI assistant without temporal context gives advice in a vacuum: it does not know that the conversation I am preparing for is in two days and the project deadline is in four. Calendar is not complex data, but it is essential grounding.

The knowledge base. Atomic cards capturing individual concepts. Maps of Content organizing them into navigable structures. Playbooks for specific situations. These are not bookmarks or highlights. They are frameworks distilled from years of reading, thinking, and lived experience. When Claude helps me work through a decision, it has general knowledge. It does not have my specific frameworks for evaluating it, built from actual experience.

Architecture of the Expanded System

Three components, each following patterns the system already uses.

Vault Indexing

The wrong approach is dumping thousands of markdown files into a database and calling it search. The right approach uses what already exists: every file in my vault has YAML frontmatter with type, tags, area, and review cadence. This is structured metadata begging to be indexed.

The design is a metadata index in SQLite with selective full-text retrieval. Index the frontmatter of every file: type, tags, area, date, linked notes. Store the full content only for types that benefit from search: atomic cards, playbooks, MOCs. Daily notes, raw journal entries, and private content stay out.

The MCP tools would look like search_vault(query, type, area), searching across playbooks in a specific life area. Or a tool that returns relevant context for a given topic, pulling from multiple note types. These return curated responses, not raw markdown dumps. The AI gets what it needs to be useful without drowning in irrelevant context.

For retrieval, SQLite FTS5 handles keyword search well. For semantic search (finding conceptually related notes even when they do not share keywords), sqlite-vec enables vector similarity without adding infrastructure. Both run inside the existing SQLite database. No Postgres. No Elasticsearch. No new moving parts.

Calendar Collector

A new collector following the existing BaseCollector pattern. Connect via CalDAV, pull events for the current and next week, push them to an /api/v1/ingest/calendar endpoint. The MCP tool get_upcoming_events(days) gives the AI temporal grounding: it knows what is on the schedule before offering advice about time management or preparation.

This is the simplest of the three components. CalDAV is a well-defined protocol. The collector pattern is proven across seven existing implementations. The value is disproportionate to the effort.

Trust Boundaries in the Data Model

Not everything belongs in the warehouse. This is the Architect vs. Slumlord divide applied to personal data. The Slumlord syncs the entire vault, indexes everything, and calls it done. The Architect defines a schema.

Reference material designed to be retrieved (atomic cards, playbooks, MOCs, resources): yes. Raw daily notes: no. Stream-of-consciousness writing has a different purpose than structured knowledge. Private content: absolutely not. Some notes exist to process experience, not to be queried by a system.

This is a schema decision made at index time, not an access control bolted on after. The vault indexer checks the type field in frontmatter and only processes types on an explicit allow list. If a note does not have frontmatter or its type is not in the list, it does not enter the database. Opt-in, not opt-out.

The Hard Problems

Building this is not just an engineering project. Four challenges require careful thought.

Expanding attack surface. A vault reader that traverses thousands of files is a different beast than one that reads mood scores. The current system handles structured data with predictable shapes: integers, dates, short strings. A vault indexer processes arbitrary markdown with embedded links, code blocks, and personal references. The security model has to keep pace. I did a security audit of Life Hub's existing attack surface. The expanded system needs the same rigor applied to a much larger surface area.

What you would never put in a database. Some context is too sensitive even for a self-hosted system. Notes about other people raise consent questions: the person described did not agree to be indexed in a queryable system, even one running on hardware I control. Financial specifics beyond trends. Medical details beyond what is useful for pattern recognition. These are judgment calls, not technical ones. You need a policy, not just an ACL. The question is not "can the system store this" but "should it."

Query quality versus context quantity. More data does not automatically produce better responses. I have tested this: dumping large sections of vault content into Claude's context window makes responses worse, not better. The AI gets lost in irrelevant details and loses the thread of the actual question. A curated weekly digest of five relevant notes may outperform 50 raw files thrown at the context window. The design challenge is MCP tools that surface the right context, not all context. This is why the vault indexer returns curated responses through purpose-built tools instead of exposing a generic "read any file" capability.

Staleness. A note updated last month has different freshness requirements than a calendar event from yesterday. A playbook written two years ago may be more relevant than a daily note from this morning. The indexer needs to handle incremental sync: watching file modification times and re-indexing only what changed, not rebuilding the entire index on every run. This is the same pattern the existing collectors use for deduplication, just applied to local files instead of API responses.

Why Self-Hosted Matters

This is not privacy theater. It is a practical observation about a category of data that most people will not put into cloud AI regardless of the privacy policy.

Medical context. Financial specifics. Relationship dynamics. Personal frameworks for navigating difficult decisions. Try getting a thoughtful person to upload all of that to a SaaS product. The privacy policy could be ironclad and the answer would still be no, because the risk tolerance for this category of data is effectively zero for most people.

Self-hosted removes the question. The vault indexer runs on my hardware. The SQLite database is on my disk. The MCP server responds to queries on a local socket.

And MCP itself is worth clarifying here: it is not "sending your data to Anthropic." The AI runs queries against local tools. The context it receives is what I expose through tool responses: structured, filtered, purpose-built. That is a meaningfully different threat model than uploading a vault to a SaaS product and hoping the terms of service hold.

What This Is Not

Brief intellectual hygiene before the closing.

This is not AGI in a box. An AI with access to my vault is still an AI: it does not understand my life, it pattern-matches against structured data about it. Useful, but categorically different from understanding. The vault indexer does not replace thinking. It replaces the manual work of digging up relevant context before thinking.

The vault indexer does not exist yet. The CalDAV collector does not exist yet. This post is arguing that these are worth building well, with explicit trust boundaries, curated retrieval, and the same security rigor applied to the existing system. Not claiming they are built.

Restraint applies to personal tooling the same way it applies to enterprise deployments. The point of the warehouse is not to make everything queryable. It is to make the right things queryable, and to be deliberate about the difference.

The vault knows who I am. The system just needs to learn how to read it.