The Sovereign AI Stack

A whitepaper on persistent, local-first AI architecture

John "Gio" Ray Rappa / Futureproof AV -- May 10, 2026

Abstract

Every AI memory solution ships the same broken assumption: that a folder of markdown files is a database. It isn't. Markdown is configuration. For actual memory -- queryable, traversable, scalable -- you need a database. But for sovereignty, portability, and human readability, you need markdown as the canonical record.

This paper presents an architecture that resolves the tension: markdown stays sovereign and syncs freely between machines, while derived databases provide the query layers that make AI memory actually work. The system splits across two nodes -- one that captures, one that curates -- connected by plain-text sync, not cloud services.

The result is an AI system with true persistent memory, voice transcription, semantic search, a structured knowledge graph, and cross-session continuity -- all running locally, all under your control.

1. The Problem

1.1 The "Second Brain" Confusion

The AI-with-memory space inherited a confused metaphor. Tiago Forte's "Second Brain" methodology (2017) taught people to organize knowledge in note-taking apps. When Claude Code shipped CLAUDE.md (2025), builders assumed it was the same thing -- a place to store everything the AI should know.

It isn't. CLAUDE.md is a .bashrc for your AI. It tells the system how to behave, what projects exist, what protocols to follow. It is configuration, not storage.

The distinction matters because configuration and data have fundamentally different scaling properties:

• Configuration is small, hand-edited, loaded in full every session. It works at 2,000 words. It breaks at 10,000.
• Data is large, machine-written, queried selectively. It works at any scale if you have a proper index.

When people dump both into markdown files, they hit a predictable ceiling: the context window fills with irrelevant information, queries require grepping through dozens of files, relationships between entities are invisible, and nothing scales past a few hundred documents.

1.2 Five Failure Modes of Markdown-as-Memory

1. No queryability. "Find what I said about project X three months ago" requires reading every file sequentially.
2. No relationships. "Who works on what? What connects to what?" is invisible in flat files.
3. Scale ceiling. At 200+ documents, the AI either loads too much context (slow, expensive, noisy) or misses relevant information.
4. No schema enforcement. Memory entries drift in format, making programmatic access brittle.
5. No concurrent-access safety. Multiple sessions or machines writing to the same files create silent corruption.

1.3 The Cloud Trap

The obvious fix -- cloud-hosted memory services -- solves queryability but creates new problems:

• Data sovereignty lost. Your life knowledge lives on someone else's server.
• Vendor lock-in. Switching providers means rebuilding your entire memory layer.
• Latency and availability. Cloud services go down. Local files don't.
• Cost scaling. As memory grows, so does the bill.

2. The Thesis

Markdown is canonical. Databases are derived. The system is distributed.

Three principles that resolve the tension:

1. Sovereignty through plain text. Every piece of knowledge exists as a human-readable markdown file on your disk. This is the source of truth. It syncs via simple file-transfer protocols (Syncthing, rsync). No proprietary format, no API dependency.

2. Queryability through derived indexes. SQLite FTS5 for full-text search. Vector embeddings for semantic search. A knowledge graph for relationships. These are all derived from the markdown -- delete any database and rebuild it with one command. Zero data loss.

3. Resilience through distribution. Two machines, two roles. A capture node (always-on, receives inputs, transcribes voice, logs conversations) and a curator node (interactive, synthesizes knowledge, maintains the graph, runs the AI sessions). Connected by plain-text sync, not shared databases.

3. Architecture

3.1 The Two-Node Model

    CAPTURE NODE (always-on server)        CURATOR NODE (laptop)
    --------------------------------       ---------------------------
    Telegram bot                           Claude Code (interactive)
    Voice transcription (whisper.cpp)      Obsidian vault
    Video ingestion (yt-dlp)              Semantic search index
    Capture log (daily markdown)           Knowledge graph
    SQLite FTS5 index                      Cross-session memory
    Syncthing (outbound)                   Automated agents (cron)
                                           Syncthing (inbound)
                    |                               |
                    +--- plain-text markdown sync ---+

The capture node is cheap, headless, always listening. It turns inputs (messages, voice notes, links, video) into structured markdown. The curator node is where the AI lives -- it reads those captures, synthesizes them into durable knowledge, and maintains the query layers.

3.2 The Five Memory Tiers

Each tier has a distinct query method because each stores a different kind of knowledge. Trying to serve all five through one mechanism (markdown grep, or a single vector DB) is why existing solutions break.

3.3 Data Flow

Inbound (capture):

Input -> Bot receives -> Hook fires -> capture-log writes markdown
      -> whisper transcribes (if voice) -> SQLite FTS5 updates
      -> Syncthing pushes to curator node (~60 seconds)

Session (curation):

Session starts -> Hook injects last session context + capture digest
              -> AI reads new captures, triages against goals
              -> Relevant content filed to vault / knowledge graph
              -> Session ends -> /close triggers full save + sync

Sync (bidirectional):

/close fires -> Pull captures from server (safety net)
            -> Snapshot server data (backup before overwrite)
            -> Push knowledge graph + vault + search index to server
            -> Re-index semantic search on server

3.4 Session Continuity

The "blank slate" problem -- AI starts every session with no memory of the last -- is solved through three mechanisms:

1. Session close protocol. A structured save at end of every session writes conclusions, diary entries, project status updates, and a handoff summary.
2. Session start hook. Injects the last session's handoff summary + any new captures that arrived while offline.
3. Cross-session memory service. Maintains conclusions and patterns that persist without manual filing.

The result: every session inherits context from the last. The AI knows what it did yesterday, what came in overnight, and what's next.

4. Design Decisions

4.1 Why Not One Machine?

A laptop sleeps. A server doesn't. Captures arrive 24/7 -- voice notes from the car, links from the phone, ideas at 3am. If the AI only runs when the laptop is open, inputs queue with no processing. The capture node ensures nothing is lost.

4.2 Why Not Sync Databases?

Binary database files (SQLite, vector indexes) don't diff cleanly. Syncthing and rsync handle text beautifully -- character-level deltas, conflict detection, no corruption. Database files create merge conflicts, locking issues, and silent corruption under concurrent access.

The rule: sync the markdown, derive the database locally. Each machine builds its own indexes. If an index corrupts, delete and rebuild from the canonical text.

4.3 Why Not a Single Knowledge Graph for Everything?

A knowledge graph excels at structured relationships (who works on what, what connects to what, what was true when). It's terrible at full-text search over raw conversations, and expensive for semantic similarity queries.

Each query tier exists because it solves a different retrieval problem:

• "What did I say about X?" -> FTS5 keyword search over captures
• "What's conceptually related to Y?" -> Vector semantic search over vault
• "Who connects to what project?" -> Knowledge graph traversal
• "What patterns has the AI noticed?" -> Cross-session memory retrieval

4.4 Why Local-First?

• Speed. Local SQLite query: <1ms. Cloud API call: 200-500ms.
• Availability. Works on a plane, in a dead zone, during an outage.
• Cost. No monthly bill that scales with memory size.
• Sovereignty. Your life knowledge stays on your hardware.
• Longevity. Markdown files written today will be readable in 30 years. Cloud services average 5 years before shutdown or breaking API changes.

5. Comparison with Existing Approaches

6. Operational Characteristics

Recovery time from failure:

• Capture node dies: rebuild from synced markdown (<30 min)
• Curator node dies: rebuild from synced markdown + last backup (<1 hour)
• Any derived index corrupts: delete and rebuild (one command, <60 seconds)
• Knowledge graph corrupts: restore from pre-sync snapshot (automatic backup exists)

Scaling properties:

• Captures: linear with time, queryable via FTS5 at any volume
• Vault: linear with curation effort, semantic search stays sub-second to ~10K docs
• Knowledge graph: grows with entities/relationships, graph queries remain O(edges) not O(docs)

Cost:

• Hardware: any old laptop as server ($0 if repurposed)
• Software: all open source (Claude Code, Syncthing, whisper.cpp, SQLite, Obsidian)
• AI compute: existing Claude subscription
• Cloud services: zero (or optional for cross-session memory only)

7. Conclusion

The AI memory problem isn't a tooling gap -- it's a category error. People are using configuration files as databases, then wondering why they can't query them. The fix isn't a better markdown tool. It's recognizing that canonical records (markdown) and query layers (databases) serve different purposes and should be architected accordingly.

This stack resolves the tension: sovereign plain-text files that sync freely between machines, with derived databases providing the query power that makes AI memory actually functional. Local-first, distributed, recoverable, and scalable -- without surrendering your data to anyone.

The architecture is the product. The specific tools are replaceable.

Postscript, September 2026

This paper has aged four months, which in this field is a full season. Three things happened.

In June, a US export-control directive forced the worldwide suspension of a frontier cloud model overnight; every workflow built on it stopped. Centralized is revocable, and that argument is no longer theoretical.

The memory service used in this architecture posted state-of-the-art results on three independent long-term-memory benchmarks while using a median 5 percent of available context, and the industry began converging on temporal knowledge graphs as the default agent-memory shape, the same structure this stack has run since day one.

And the two-node model described here grew a third node, a GPU machine for local inference, without changing a line of the thesis: markdown stayed canonical, databases stayed derived, the new node subscribed to the same plain-text sync. Architectures that survive growth unchanged are the ones worth writing down.

John "Gio" Ray Rappa / Futureproof AV -- 2026