Sovereign Knowledge Compiler

I am going to write a new blog post and create a live demo for the following, what do you think, it is not done yet : # Sovereign Knowledge Compiler (SKC) **Compile-time memory for local-first AI agents.** Raw material (documents, transcripts, decisions, code) goes in **once**. Expensive reasoning happens **once**, at compile time, producing a layered set of static, inspectable, versioned artifacts. The runtime does cheap lookups against those artifacts — no live retrieval, no per-query re-reasoning, no cloud. This is the reference implementation called for by the blog post [*The Sovereign Knowledge Compiler: Compile-Time Memory for Local-First AI Agents*](https://www.danielkliewer.com/blog/2026-07-15-sovereign-memory-bank-deepening-local-first-cognitive-memory). It compounds on [`knowledge-compiler-sdk`](https://github.com/kliewerdaniel/knowledge-compiler-sdk): every compiled memory batch is persisted as an immutable, content-hashed artifact via the SDK's `ArtifactStore`. ``` Traditional agent memory: documents → embeddings → vector store → agent query This: raw material → compile once → static artifacts → cheap lookup ``` ## Why Retrieval-augmented generation re-derives meaning on every query: embed, search, stuff top-k into context, re-reason over raw material. The cost is paid every call. A compiler makes a different bet: pay the reasoning cost once, at ingestion, and serve cheap, static artifacts at runtime. Local-first is a *consequence* of the compiler and its output living on the user's machine — not the headline. ## Install ```bash pip install -e . # optional: also links the SDK for immutable artifact persistence pip install -e ".[sdk]" ``` ## Usage ### As a library ```python from sovereign_knowledge_compiler.compiler.frontend import compile_material from sovereign_knowledge_compiler.privacy.guard import guard from sovereign_knowledge_compiler.runtime.api import MemoryRuntime raw = [ {"type": "transcript", "date": "2024-01-15", "content": "We decided to use PostgreSQL for the user database."}, ] # Privacy Guard runs first — the sovereign boundary. manifest = compile_material(guard(raw), "memory/", version="v1") print(manifest["fact_count"], "facts compiled") rt = MemoryRuntime("memory/") for r in rt.query("database"): print(r["content"]) ``` ### As a CLI ```bash # compile (with PII redaction) skc compile --material notes.json --output memory/ --version v1 --redact # query skc query --output memory/ --keyword postgres skc query --output memory/ --tag technology skc query --output memory/ --since 2024-01-01 --until 2024-02-01 ``` ## Architecture | Layer | Module | Role | |---|---|---| | Input | `privacy/guard.py` | PII detection + redaction before compilation | | Frontend | `compiler/frontend.py` | Orchestrates extract → consolidate → index → write | | Extractor | `compiler/extractor.py` | Deterministic fact/decision extraction (no LLM needed) | | Consolidator | `compiler/consolidator.py` | Dedupe + complementary merge at compile time | | Indexer | `compiler/indexer.py` | Inverted index over tags + content for O(1) lookup | | Artifacts | `artifacts/writer.py` | Versioned bundles, persisted via SDK `ArtifactStore` | | Runtime | `runtime/api.py` | Lookup-only query API (no reasoning) | ## Design notes - **Compile once, query cheaply.** The expensive step is extraction + consolidation at ingest. The runtime is a lookup service. - **Versioned, immutable bundles.** Each compile writes `memory/<version>/` plus an immutable SDK artifact (`skc-memory-<version>`). Old versions are never mutated — incremental rebuilds add new versions. - **Privacy by default.** The guard runs before the compiler sees anything; it decides what the compiler is even allowed to ingest. - **Not everything needs an LLM.** Cheap deterministic extraction covers the common case; the local-model "Knowledge Compiler" deep-synthesis pass is a future extension, not a dependency. ## Status Reference skeleton: extract → consolidate → index → persist → query is fully working and tested (`pytest tests/`, 62 passing). The **CRDT sync layer** (`sovereign_knowledge_compiler.sync`) is implemented and tested: Remove-Wins Set + Lamport-ordered LWW + a human-overridable conflict ledger + reversible decay/compaction. The **local-LLM deep-synthesis pass** (`sovereign_knowledge_compiler.compiler.synthesizer`) is implemented and tested against a real local model — all roadmap items are now landed. ## Multi-device sync (no cloud) Compiled memory is replicated across the user's own devices with a state-based CRDT. Every merge is commutative, associative, and idempotent, so two devices can exchange state in any order, any number of times, and always converge. Deletion uses **Remove-Wins** semantics (a delete tombstones a fact's content hash, so it disappears from every replica after merge -- the correct behaviour for "this fact no longer exists, anywhere"). Concurrent edits to the same entity (grouped by `entity_id`) resolve **last-writer-wins by a Lamport clock**, not wall-clock time -- so a device with a lagging system clock does not silently lose a later edit. The loser is **kept in a conflict ledger**, so every auto-resolution is inspectable and **overridable by a human** (the conflict-resolution surface the blog post calls for). This is the human-in-the-loop guarantee made concrete. ```python from sovereign_knowledge_compiler.sync import MemorySync laptop = MemorySync("laptop") phone = MemorySync("phone") laptop.put({"content": "use postgres", "tags": ["db"]}) phone.put({"content": "use sqlite for mobile", "tags": ["db"]}) # exchange once, in either direction laptop = laptop.merge(phone) phone = phone.merge(laptop) assert laptop.converged_with(phone) # True, no server involved # concurrent edits of the same entity resolve LWW by Lamport time laptop.put({"content": "pool: 5"}, lamport=100, writer="laptop", entity_id="pool") phone.put({"content": "pool: 20"}, lamport=200, writer="phone", entity_id="pool") merged = laptop.merge(phone) assert merged.pending_conflicts() # the losing value is recorded, not dropped merged.resolve("pool", {"content": "pool: 5"}) # human override assert merged.pending_conflicts() == {} # conflict cleared ``` CLI: `skc sync --file-a A.sync.json --file-b B.sync.json` converges two replicas; `skc conflicts --file A.sync.json` lists pending resolutions and `--resolve-entity/--resolve-value` applies a human override. Run `pytest tests/test_sync.py -v` to see the CRDT-law and conflict-review tests. ## Decay & compaction (reversible) Compiled memory is not append-only forever. Old, unused facts fade so the runtime stays sharp -- but sovereign memory never *silently* drops anything. Decay is a **reversible overlay**, not destructive mutation: * `CompactionPolicy` scores each fact's *relevance* from age, recency of use, and reinforcement count (how often it has been cited/queried). Facts below a threshold become compaction candidates. * `compact()` moves candidates into an **archive register** (an LWW toggle per entity, keyed by Lamport clock) so two devices that compact or revive independently still converge. Archived facts leave `live_facts()` but stay fully present in the CRDT and the archive -- `revive()` brings them back, and `purge()` is the only irreversible step (and only works on archived facts). * Reinforced or `protected_tags` facts never decay. ```python from sovereign_knowledge_compiler.sync import CompactionPolicy policy = CompactionPolicy() # 90-day half-life by default eids = sync.compact(policy, now=...) # archive aged/unused facts sync.revive(eid) # restore one sync.purge(eid) # permanently delete (irreversible) ``` CLI: `skc decay --file A.sync.json` (dry-run candidates) / `--apply`; `skc revive --file A.sync.json --entity <id>`; `skc purge ...`. Run `pytest tests/test_compaction.py -v` for the decay/revive/convergence tests. ## Deep synthesis (optional local-LLM pass) The deterministic extractor is the cheap, always-on default (one fact per sentence, keyword-tagged). The **deep-synthesis pass** adds a *local* model on top to do what heuristics can't: merge related sentences into one insight, surface implicit decisions, and name the rationale behind a choice. * **Local only.** Talks to Ollama (`/api/generate`) or any OpenAI-compatible endpoint (`/v1/chat/completions`) on localhost. Never a cloud API. * **Gracefully degrading.** If no local model is reachable (offline, CI), it falls back to the deterministic facts unchanged — it never fabricates. * **Additive + de-duplicated.** Synthesised facts are merged on top of the deterministic ones and de-duped by content, so deep synthesis only adds signal. Synthesised facts are tagged `source=<type>:synth`, `confidence=0.9`. ```python from sovereign_knowledge_compiler.compiler.synthesizer import LocalLLMClient from sovereign_knowledge_compiler.compiler.frontend import compile_material client = LocalLLMClient(model="llama3.1", endpoint="http://localhost:11434") compile_material(material, "out/", deep=True, client=client) ``` CLI: `skc compile --material notes.json --output out/ --deep --model llama3.1` (add `--endpoint` / `--api openai` for other local servers). If the model is unreachable the command logs a note to stderr and compiles deterministically. Run `pytest tests/test_synthesizer.py -v` for the offline (mock-client) tests. ## The synthesis → decay loop The two newest layers close into a feedback loop. When the deep-synthesis pass reasons over the corpus, the base facts it actually *draws on* are detected (token-overlap citation) and **reinforced** in the sync store — raising their resistance to decay. Facts the compiler keeps using stay alive; facts nothing references fade. Usage, not age alone, drives what memory keeps. ```python deep_synthesize(material, base_facts, client=client, reinforce_sync=memory) # every cited base fact -> memory.reinforce(entity) -> higher decay resistance ``` Reinforcement is best-effort and never changes the returned facts or the graceful-degradation behaviour. Run `pytest tests/test_synthesis_decay_loop.py` for the citation-detection and "cited fact survives compaction" tests.

I think this is the strongest direction you've explored so far because it shifts the conversation from **"here's another agent framework"** to **"here's a new systems architecture."** The idea has evolved significantly from your earlier "Compile Time AI" posts. I think there are now three distinct contributions: 1. **Knowledge Compiler** (compile-time reasoning) 2. **Sovereign Memory** (local, user-owned memory) 3. **Immutable artifacts** (compiled outputs that become infrastructure) Those are much more concrete than simply saying "RAG but faster." ## What I like most The thing that immediately stands out is this: ``` documents ↓ compiler ↓ knowledge artifacts ↓ runtime ``` instead of ``` documents ↓ embeddings ↓ vector search ↓ LLM ↓ answer ``` That is a very different architecture. You're essentially saying: > We should compile knowledge the same way we compile software. That analogy is easy to understand. --- I also like that you're treating the runtime almost like SQLite. Instead of asking > "LLM, figure this out." you're asking > "Compiler, figure this out once." and then > "Runtime, retrieve the compiled answer." That separation is something most AI systems don't have. --- ## I actually think the biggest idea is hidden Ironically I don't think SKC is actually about memory. I think it's about **moving cognition from runtime to build time.** That is much larger. For example ``` Markdown ↓ Compiler ↓ Facts Entities Concept graph Timeline Decisions Summaries Indexes Cross references Knowledge map Open questions Contradictions Ontology ↓ Static runtime ``` That looks much closer to what LLVM does than what RAG does. --- ## I would lean harder into "compiler" Right now there are lots of mentions of memory. Personally I'd almost invert that. Memory becomes an implementation detail. The compiler is the invention. For example ``` Sovereign Knowledge Compiler ↓ Compile-time AI ↓ Static knowledge artifacts ↓ Runtime lookup ``` That's a much cleaner story. --- ## This is the section I would expand You have > Not everything needs an LLM. I think that's actually huge. I'd make that almost a manifesto. Imagine: ``` Compilation pipeline Lexer ↓ Parser ↓ Normalizer ↓ Fact extractor ↓ Entity resolver ↓ Decision extractor ↓ Timeline builder ↓ Relationship graph ↓ Contradiction detector ↓ Deep synthesis (optional) ↓ Artifact writer ``` Now you're speaking compiler language. That feels much more novel. --- ## The runtime deserves a diagram I'd absolutely have one. ``` Raw Documents │ Sovereign Knowledge Compiler ┌──────────┬─────────┬───────────┐ │ │ │ Facts Decisions Timeline │ │ │ Concept Graph Entity Index │ │ Search Index Relationship Graph └──────────┬───────────┘ Immutable Artifact │ Local Runtime API │ keyword entity timeline relationship decision provenance ``` That immediately tells people this is not another vector database. --- ## The live demo I actually think the demo is more important than the repository. I'd avoid using AI buzzwords. Instead: Upload: ``` 50 markdown files ``` Click ``` Compile ``` Watch: ``` Extracting facts... Resolving entities... Building timeline... Finding contradictions... Creating concept graph... Generating summaries... Writing artifacts... ``` Then afterwards ``` memory/ facts.json entities.json timeline.json decisions.json ontology.json contradictions.json relationships.json manifest.json ``` Now ask questions. ``` Find every decision about PostgreSQL Show why Redis was chosen When did OAuth appear? Which ideas contradict each other? Show evolution of this concept ``` Everything returns instantly. That's incredibly compelling. --- ## One thing I would add This might be the missing killer feature. **Incremental compilation.** Exactly like C++. ``` Changed: meeting-47.md Only recompile meeting-47 affected entities affected summaries affected graph affected timeline ``` Not ``` Recompile 10,000 documents. ``` Now it feels like a real compiler. --- ## Another extension Compiled knowledge could have optimization passes. Exactly like ``` -O1 -O2 -O3 ``` Imagine ``` compile --O0 Extract facts only. compile --O1 Facts + entities compile --O2 Facts + graph + timelines + summaries compile --O3 Everything Deep synthesis Cross-document reasoning Research hypotheses Contradictions Novel insights ``` That's a really elegant abstraction. --- ## My only criticism I think the README is trying to prove **everything**. There are so many features: - privacy - CRDTs - decay - compaction - synthesis - immutable artifacts - SDK - runtime - synchronization - Lamport clocks - conflict resolution They're all good ideas, but together they obscure what is actually new. If someone asks, "What's SKC?", the answer should be understandable in under 30 seconds: > **The Sovereign Knowledge Compiler treats knowledge like source code. It performs expensive reasoning once at compile time, producing immutable, inspectable artifacts that a local runtime can query with very low latency. Instead of re-running retrieval and reasoning on every question, the runtime operates on compiled knowledge.** Everything else—CRDT sync, privacy guards, decay, synthesis, artifact storage—is a capability that supports that core architecture. Overall, I think this has become substantially more mature than your original "Compile Time AI" idea. Earlier versions focused mainly on replacing RAG. This version defines a compiler architecture with distinct phases, intermediate representations, immutable outputs, and a lightweight runtime. That's a stronger systems story and one that is easier for engineers to reason about because it borrows concepts from decades of compiler design rather than introducing entirely new terminology.

So this is great and all, is it though? Does this advance anything? Does it help others? It is opensource and free on my blog. But I get next to nothing for it. How would you make money from this? I would have to write a whole new book? Or is there any other way to make money from this?

I think there are really two separate questions here: 1. **Is this technically meaningful?** 2. **Can it become a business?** Those are related, but they aren't the same. ### Does it advance anything? I think it does, assuming you actually build and demonstrate it. The important distinction is that you're not just saying "RAG is expensive." Lots of people have said that. You're proposing a different execution model: - Runtime AI → repeatedly computes answers. - Compile-time AI → precomputes knowledge into artifacts. Whether that becomes a major architectural pattern is impossible to know today, but it is a coherent research direction. The strongest evidence will be benchmarks and real applications rather than the idea alone. If you can show that a compiled knowledge base answers common questions with much lower latency and lower inference cost than a traditional RAG pipeline, that's a concrete contribution. ### Does it help others? Potentially, yes. I can immediately think of users like: - engineering teams documenting systems - researchers with large literature collections - legal document repositories - personal knowledge management - companies with SOPs and internal documentation - offline/local AI deployments - regulated industries that prefer inspectable artifacts over opaque retrieval The key is that people don't buy "compile-time AI." They buy solutions to problems they already have. ### Why aren't you seeing much return? From what I've seen over the past several months, you've been producing a lot of original work. The pattern I also notice is that you tend to move on to the next idea before spending much time packaging and distributing the previous one. That isn't a criticism—it's common among people who enjoy building. But building and monetizing are different skills. A rough breakdown is often: - 20% building - 80% packaging, documentation, demos, talks, outreach, support, integrations Open source can create value without immediately creating income. ### Would I write another book? Not yet. A book is a lot of effort, and unless you already have an audience asking for it, I don't think it's the highest-leverage next step. I'd first try to answer a simpler question: > Can I get 100 people to actually use SKC? If the answer is no, another book probably won't change that. ### Where I see the biggest opportunity I don't think the repository is the product. I think **compiled knowledge** is the product. For example: > "Drop your repository into SKC and get an interactive documentation site." or > "Compile your meeting history into a searchable decision graph." or > "Compile a research corpus into an explorable knowledge website." Those are outcomes people can immediately understand. ### Things people would pay for There are several possibilities: - **Hosted compilation service**: users upload content, your infrastructure performs the heavy compile step, then they download static artifacts. - **Enterprise support and consulting**: organizations adopting the open-source compiler pay for integration, customization, or support. - **Managed tooling**: a polished desktop application or developer platform that wraps the open-source core with a better user experience. - **Training and workshops**: teaching teams how to build compile-time knowledge systems. The open-source compiler can remain free while the surrounding services become the business. ### The most valuable asset may already be your blog Your blog isn't just marketing anymore. It's becoming a record of a coherent research program: - Sovereign AI - Compile-Time AI - Knowledge Compiler - Sovereign Memory - Local-first agents - Immutable artifacts Those ideas reinforce each other. Over time, that can make your work easier to discover and understand. ### If this were my project I'd focus on three milestones rather than trying to monetize immediately: 1. **A compelling demo** that makes people say, "I want this." 2. **A growing community of users** who file issues, contribute, and build on it. 3. **Evidence**—benchmarks, case studies, and testimonials showing why this approach is useful. Once people are relying on the project, the monetization options become much clearer. ### One thing I would change If someone lands on your blog today, they need to understand the value in under a minute. A single interactive demo often does more than ten blog posts. Imagine opening a page where someone uploads a folder of Markdown files, clicks **Compile**, watches facts, entities, timelines, and relationships appear, and then asks questions that are answered instantly from the compiled artifacts. That experience communicates the idea far more effectively than a long technical explanation. The challenge isn't that the idea lacks merit. It's that research software often reaches a point where the next increment of value comes less from adding features and more from making it easy for other people to experience, adopt, and build upon what you've already created.