The Sovereign Knowledge Compiler Explorer: A Recipe for Compiling Knowledge Into a Static, Living Artifact

The Sovereign Knowledge Compiler Explorer: A Recipe for Compiling Knowledge Into a Static, Living Artifact

Most "knowledge apps" are interpreters wearing a UI. You ask a question, they embed it, hit a vector store, pull top-k chunks, and ask a model to re-reason the answer — on every single query. The reasoning cost is paid again and again, and nothing compounds.

The Sovereign Knowledge Compiler Explorer is the opposite. It is a static website — 82 prerendered pages, served from a CDN — that contains no model at runtime. When you open a concept, the page already knows what it is, what it depends on, and where to go next. The reasoning that produced that page happened once, at compile time, and was frozen into files.

→ Live demo: skce-explorer.vercel.app → Source: github.com/kliewerdaniel/sovereign-knowledge-compiler-explorer

This post is a recipe. Treat the project like a lab experiment you are reconstructing. Below is exactly what was built, why each piece exists, and how you — human or AI — can rebuild it from your own corpus. No API keys. No cloud inference. Just a corpus, a compiler, and a static site.

How the idea evolved

This did not appear fully formed. It is the fifth step in a line of reasoning that has been running on this blog for a week.

• 2026-07-11 — Compiling Human Knowledge Into Static Semantic Artifacts. The seed idea: a knowledge compiler that parses a corpus, builds intermediate representations, runs passes, and emits static, versioned artifacts — so the runtime does cheap lookups instead of re-reasoning.
• 2026-07-12 — Compile-Time AI: Knowledge Compiler Architecture. The architecture crystallized: deterministic passes first, model-assisted passes second (and gracefully degrading when no model is present), content-hashed outputs, and a hard honesty rule — the build fails loudly on invalid or cyclic prerequisite graphs rather than inventing confidence.
• 2026-07-14 — The Recursive Research Compiler SDK. The compiler became a reusable SDK: a typed intermediate representation (ConceptNode, RelationshipEdge), a pass registry with a Kahn-scheduled DAG, and a batching strategy for large corpora.
• 2026-07-15 — I Compiled My Blog Into a Decision Graph. The first visual proof: 153 posts → 1,513 facts, 436 decisions, a live 3D graph. Compiling memory beat retrieving it. But that demo read a single dataset.json and leaned on a heavier runtime.
• 2026-07-16 — This post. The Explorer. Take the compiler, point it at a declared corpus (not just scraped prose), and emit a curriculum — a structured, prerequisite-ordered map of concepts — then serve it as a fully static, prerendered site with zero runtime inference. The artifact is not just visualized; it is navigable as a website.

The thread is unbroken: reason once, emit static, let the runtime be cheap, keep it sovereign and inspectable. The Explorer is the version where "static artifact" means "a website a human can read and descend through," not just "a JSON file a graph reads."

What it is

The Explorer is two layers:

1. A compile-time curriculum compiler (pure Python, no heavy dependencies). It reads a corpus of declared concept specs and blog posts, builds a typed intermediate representation, runs deterministic passes, and emits a content-hashed curriculum artifact — concept store, search index, learning paths, and graph views.
2. A static Next.js explorer app that consumes that artifact. Every concept page is prerendered at build time. Navigation, the knowledge graph, search, and learning paths are all computed from the artifact. Nothing calls a model when you read it.

The compiled result, deterministically, from 43 declared concept specs + 4 blog posts:

Zero gaps means the compiler proved the prerequisite DAG is acyclic and every concept is reachable — a guarantee no RAG system gives you.

The architecture, in one diagram

        corpus/                         compiler/                      apps/explorer/
  ┌──────────────────┐          ┌──────────────────────┐        ┌──────────────────────┐
  │ specs/*.yaml     │          │ ir.py  (typed IR)    │        │ lib/curriculum.ts    │
  │ blog/*.md        │ ───────► │ passes_framework.py  │ ─────► │   (browser fetch)    │
  └──────────────────┘          │ cli.py → emit        │   cp   │ app/** (prerendered) │
                                 └──────────────────────┘        └──────────────────────┘
                                            │                               ▲
                                            ▼                               │
                                   public/curriculum/  ◄───────────────────┘
                                   (gitignored, regenerated at build)

The key move: the compiler and the app are decoupled by a static file boundary. The compiler writes JSON; the app reads JSON. Neither imports the other. That boundary is what makes the whole thing reproducible and sovereign — you can swap the compiler, the corpus, or the frontend independently.

The recipe (reconstruct it yourself)

0. Prerequisites

• Python 3.9+ (the compiler uses only the standard library — no pip install).
• Node 22+ (for the Next.js app).
• A corpus. Start with a handful of YAML concept specs; add prose later.

1. Define a typed intermediate representation

Everything flows through one contract. ConceptNode carries id, title, kind, summary, contract (what_is_it / why_exists / how_it_works / edge_cases), prerequisite_ids, tags, abstraction_level, source. RelationshipEdge carries source, target, type, weight. The IR is the stable anchor — change the UI or the passes, but never break the contract, or the build refuses.

2. Write a pass framework with a real scheduler

Passes declare their inputs and outputs as edge types (KIND_PREREQ, KIND_RELATED, …). A scheduler topologically sorts them (Kahn's algorithm) so a pass never runs before its inputs exist. If the graph of passes has a cycle, the build fails loudly. This is the "honesty guard": the system cannot produce a silently-wrong artifact.

3. Make the core deterministic; let the model degrade

Pass 01–08 run with no model: ingest, normalize, extract-from-specs, link, infer prerequisites, optimize the curriculum, emit. A model is optional enrichment (pass 03 can distill facts from blog prose if a local LLM is available). If none is present, the build still succeeds and emits the declared curriculum. Determinism first; inference second.

4. Emit content-hashed artifacts

The emitter writes concept-store.json, search-index.json, learning-paths.json, and graph-views/*.json. Each file is hashed into a manifest.json. Content-addressing means a changed corpus produces changed hashes — you can see exactly what a corpus edit moved, and you can diff artifacts in git (even though the build output itself is gitignored).

5. Build the static frontend that only reads

The Next.js app has two loader paths:

• Server components read the artifact from disk at build time (fs) to prerender every concept page.
• Client components fetch the same JSON at runtime from /curriculum/ — but only for the interactive graph and search. No model. No API route.

Crucially, the frontend is a consumer, not a participant. It cannot alter the knowledge; it can only navigate it.

6. Regenerate the artifact inside the build

The artifact is gitignored (it is derived, not source). So the build script runs the compiler first, then next build:

python3 -m compiler.cli build --corpus corpus --out build --version v1
cp -R build/v1/. public/curriculum/
npx next build

This is the single most important deployment detail: on Vercel, the corpus and compiler travel with the app, and the artifact is rebuilt from them at build time. Nothing is hand-authored; the site is the compiled corpus.

7. Deploy as a normal Next.js app (not a static export)

A subtle but real trap: output: "export" + trailingSlash makes Vercel mis-serve the root (/ 404s). The fix is to drop the static export and let Vercel serve the app natively — all pages are still prerendered via generateStaticParams, so read-time is still zero-inference, but routing works. Set the project Root Directory = apps/explorer so Vercel finds next in the right package.json.

What it teaches

• The loop is the product. The Explorer is the loop — corpus → compiler → artifact → site — made visible. Open any concept and you are reading the output of a pipeline that ran once.
• Compiling beats retrieving. There is no vector store, no top-k, no per-query LLM call. The reasoning cost was amortized across every future reader.
• Honesty is a build failure, not a footnote. Invalid or cyclic prerequisite graphs abort the build. The app shows real edge counts, not synthesized confidence.
• Sovereignty is a file boundary. The corpus is yours, the compiler is local, the artifact is static and versioned. No cloud call is required to read your own knowledge.

Try it

1. Clone the repo.
2. Run ./build.sh (or bash apps/explorer/scripts/build.sh). It compiles the bundled corpus and builds the site into apps/explorer/.next.
3. Open skce-explorer.vercel.app. Start at the root concept. Click a prerequisite. Descend.
4. To make it yours: edit apps/explorer/corpus/specs/*.yaml, rerun the build, redeploy. Your knowledge becomes a website.

The compiler that built this post's demo is open source. The corpus that fed it is in the repo. The recipe is above. Reconstruct it, point it at your own writing, and watch your arguments become a map you can walk.

The loop is the product. This is what it looks like when the loop compiles itself into something a human can read.