Recursive Knowledge Governance

Written in collaboration with Claude (Opus) -- Anthropic

---

The Punchline First

Three systems. Three completely different domains. Same structural pattern.

I didn't plan this. I built a personal knowledge system to keep track of my own work. Separately, I developed a three-document governance framework for product strategy. Separately again, I designed an AI production assistant for unscripted television. On April 8, 2026, while talking about how my personal system should inform the TV product, I realized they're all the same architecture.

Same pattern. Three layers. Every scale.

---

The Three Systems

System 1: Personal Knowledge

I manage over twenty knowledge bases, thousands of memory entries, and a portfolio of active projects. Without structure, the cognitive load would bury me. Over months of iteration, a three-layer system emerged:

Layer 0 (Verbatim): An open-source tool called MemPalace: a ChromaDB-backed semantic archive built by Milla Jovovich and developer Ben Sigman, who arrived at the same problem from a completely different world. Jovovich got frustrated that AI memory systems decide what to remember instead of keeping everything verbatim -- the same frustration I had. Everything goes in. Nothing is lost. I adopted it because it solved the storage problem I was already wrestling with.

Layer 1 (Curated): A hand-maintained wiki loaded at the start of every session. Hot index. Topic files. Behavioral guidance. Not everything. Just what matters right now. I built this from scratch as part of a larger system called HYDRA, which manages daemon processes, entity coordination, and cross-project automation.

Layer 2 (Compiled): A knowledge compilation system inspired by Karpathy's idea that LLMs can maintain their own knowledge bases. Raw sources go in, an LLM compiles structured wiki articles, and those articles become queryable. I built the pipeline, the commands, and the integration layer. The core insight came from his public work.

Each layer serves a different need. Layer 0 answers "what did we decide three weeks ago?" Layer 1 answers "what am I working on right now?" Layer 2 answers "what patterns connect these twenty sources?"

System 2: Product Governance

I developed a three-document framework I call the Triad:

VISION.md (Future): What the product is and why it exists. Directional. Changes slowly.

SPEC.md (Present): What actually exists in code right now. Observable. Changes with every build.

BUILDING.md (Past/Bridge): How we got here. The decisions, pivots, and lessons that connect the vision to the current state.

The key property: any two documents illuminate the third. The gap between VISION and SPEC is the roadmap. The gap between SPEC and BUILDING is the next session's work. If you know where you're going and what you've already built, the current spec almost writes itself.

But the Triad alone isn't enough. It defines what and why, but it doesn't operationalize how and when. So I built an execution layer underneath it -- a four-level zoom system that cascades from strategy down to individual workstreams. More on that in a moment.

System 3: Production Operations

I work in unscripted television. My team runs a show in the 90 Day Fiancé franchise. The entire operation runs on a Google Sheet that pretends to be a calendar, a database, a cast tracker, a gear coordinator, and a crew availability board. The number one pain point: nobody updates it.

I'm building Lexicon, a production OS with an AI entity named Lexi. The architecture that's emerging has three layers:

Activity Log: Every message, every gear transition, every footage handoff. Verbatim capture from Telegram group chats, meeting transcripts, dashboard actions.

Visual Dashboard: The calendar, cast tracker, gear swim lanes. Curated operational state. What matters right now.

Lexi Intelligence: Compiled synthesis. "What's the latest on this cast member?" draws from internal production data and public web sources to give an answer nobody on the team could assemble quickly.

---

The Discovery

On April 8, 2026, while mapping how my personal knowledge system should inform Lexicon's architecture, I saw it. Each system had a layer that captured everything, a layer that surfaced what mattered, and a layer that synthesized meaning:

Three systems. Three domains. Same three layers. Same directional properties.

You're probably thinking: isn't any three-tier architecture the same pattern? Presentation, logic, data. Strategic, tactical, operational. The DIKW pyramid. Fair question. What makes this specific is the six properties that hold across all three instances -- and particularly the way information and authority flow in opposite directions.

---

The Invariant Properties

1. The top layer compiles. It synthesizes truth from raw data, changes slowly, and carries the highest authority. The compiled research output. The Triad. Lexi's intelligence layer.

2. The middle layer curates. It's the operational surface, changes frequently, and serves daily decisions. The wiki index. The roadmap. The calendar dashboard.

3. The bottom layer captures everything. It changes constantly. Nothing is lost. The verbatim archive. The ticket board. The activity log.

4. Authority flows down. Information flows up. This is the property that most surprised me. Raw data flows upward through the layers -- the verbatim archive feeds the compiler, field reports feed the dashboard. But authority flows in the opposite direction. When compiled truth changes, the cascade propagates downward through every lower layer. The top layer has veto power. A ticket that contradicts the vision gets rewritten, not the other way around. Two-way flow, one-way authority.

5. Each layer serves a different audience. The EP asks Lexi a question and gets a paragraph. The field coordinator checks the dashboard and gets a calendar. The assistant coordinator (AC) messages the group chat and adds raw data. Same truth, three zoom levels.

6. The system supports reconciliation. When layers drift out of sync, a reconciliation pass realigns them. Top rewrites middle, middle rewrites bottom. I don't know yet whether this process can be fully automated -- right now it's triggered manually, though the protocol itself can be executed by agents. That's an open question I'm still working through.

---

The Cascade

Here's where the governance instance gets specific. I call it the Triad-Exec Cascade.

The strategic layer is the Triad itself: VISION.md, SPEC.md, BUILDING.md. Beneath it, four zoom levels translate strategy into execution. Milestones derive from VISION phases. Tasks derive from milestones. Tickets derive from tasks. And checklists derive from tickets. Each level is computed from the one above it. Nothing at any level can contradict what sits higher.

When a VISION phase changes, the change cascades through every zoom level. A new direction rewrites milestones, which rewrites tasks, which rewrites tickets, which rewrites the checklist you're working from today.

I formalized this into a reconciliation protocol with 16 verification points. On April 8, after rewriting the entire Triad with a new vision and cascading it through all four levels, I ran the full verification. Sixteen out of sixteen passed. The codebase still built. All 227 tests still passed. Zero drift.

The reconciliation protocol is embedded within the governance layer it checks -- a self-referential loop that I find satisfying, though I'll note it's a consistency check, not a proof of correctness. It verifies that the documents agree with each other, not that they're right about the world.

---

Why the Google Sheet Fails

This framework explains exactly why flat tools fail at knowledge management.

My production team's Google Sheet tries to be all three layers in one surface. The monthly calendar is Layer 1, curated state. But it's also expected to be Layer 0 -- raw capture from the field, updated by ACs after shoots -- and Layer 2 -- compiled intelligence for the EP who asks "what's the status of this story arc?"

A flat spreadsheet cannot be three things. It can't capture everything (too tedious to update from the field), curate what matters (too noisy, buried in tabs), or compile intelligence (nobody has time to synthesize across 40 columns).

Three layers can. When Lexi sits in a Telegram group chat -- and this is the architecture I'm building toward, not something deployed yet -- field crew will update Layer 0 by doing their normal work. The dashboard compiles Layer 1 automatically. The EP asks Lexi a question and gets Layer 2 on demand. Nobody "updates the sheet." The system updates itself from the natural flow of work.

---

The Dogfood Pipeline

The most unexpected part of this discovery: the product architecture came from the builder's cognitive architecture.

I didn't design Lexicon's three-layer system from theory. I built a personal knowledge system, lived inside it for months, recognized its structural properties, and then projected them onto a different domain. The personal system became the product blueprint:

This suggests a principle: if you build tools for yourself honestly enough, they become tools for everyone else. By "honestly" I mean without premature abstraction, without optimizing for an imagined user, without designing from theory. The structural patterns that emerge from genuine daily use are more robust than anything designed top-down, because they survived contact with reality before they were ever named.

Here is the pipeline in action: on April 8, I sat down to figure out how my personal wiki system should inform Lexicon's architecture. Within an hour, the three-layer mapping was on the table. Within four hours, the entire Lexicon Triad was rewritten, the exec layer cascaded through four zoom levels, and a 16-point verification confirmed zero drift. The product redesign came directly from the personal system's structural DNA -- not by analogy, but by projection. I recognized the shape because I'd been living inside it.

I think the dogfood-to-product pipeline is actually the most important finding here -- more important than the pattern itself. The pattern is a description. The pipeline is a method. But I don't have enough data points yet to defend it as more than a strong hunch. One builder, three systems, one discovery. I need to see it replicate before I call it a principle.

---

Applying the Pattern

If you wanted to apply this to your own domain -- say, running a restaurant, managing a research lab, or coordinating a distributed engineering team -- here's how I'd think about it.

Identify your three layers. What's the compiled truth that changes slowly and has the highest authority? In a restaurant, maybe it's the menu and brand standards. What's the operational state that changes daily? The prep list and reservation book. What's the raw capture where nothing should be lost? Every ticket, every server note, every customer complaint.

Establish directional authority. The menu governs the prep list, not the other way around. When the chef changes the menu, the prep list rewrites. But information flows upward: customer complaints (Layer 0) bubble up through the operational layer and eventually change the compiled truth (the menu).

Define reconciliation triggers. What events cause the top layer to change? A bad quarter. A new chef. A seasonal shift. When those triggers fire, cascade downward.

Make capture automatic. Layer 0 should populate from natural work, not manual entry. If people have to choose between doing their work and updating the system, the system loses every time.

---

Attribution and Lineage

I want to be precise about what I built and what I adopted, because getting this right matters to me.

I built the HYDRA daemon system, the MEMORY.md wiki architecture, the Triad governance pattern, the Triad-Exec Cascade protocol, and Lexicon with the Lexi entity from scratch. The Consciousness-as-Filesystem research framework that underpins the per-entity memory pattern is also my work.

I adopted MemPalace (github.com/milla-jovovich/mempalace), built by Milla Jovovich and Ben Sigman -- a ChromaDB-backed verbatim archive that holds the highest score on the LongMemEval benchmark among free tools. It solved the Layer 0 storage problem I was already working on, and the fact that an actress and a developer arrived at the same architectural conclusion from a completely different starting point makes the pattern more interesting, not less. The Knowledge Compiler concept was inspired by Andrej Karpathy's work on LLM-maintained knowledge bases -- specifically his demonstrations of using language models to compile and maintain documentation. I built the full pipeline with 21 knowledge bases, 7 commands, and a Telegram ingest system.

The novel contribution is not any single layer. It's the recognition that these three layers form a structurally analogous pattern across personal cognition, product governance, and team operations. The same properties. The same directional flows. The same reconciliation mechanics. Different domains, same architecture.

I arrived at this by building honestly for myself and then noticing the shape.

---

What This Means

Knowledge doesn't live at one zoom level. A CEO needs compiled intelligence. A manager needs curated status. An operator needs granular detail. Same truth, different resolution.

The recursive pattern gives everyone the right view without anyone maintaining separate systems. One truth, multiple lenses, automatic derivation. The cascade ensures consistency. The reconciliation protocol ensures honesty. And the open question -- whether this holds beyond three domains and one builder -- is what makes it worth writing about rather than just using.

I didn't set out to discover a universal pattern. I set out to stop drowning in spreadsheets and context switches. The pattern emerged from building, not from theorizing. And it works because it was tested against reality at three different scales before it was ever written down.

The triad is a seed. The cascade is how it grows. And the shape it grows into is the same one every time.

---

Eddie Belaval is the founder of id8Labs, building professional tools for the AI era. He works in unscripted television production and builds AI systems that replace spreadsheets with intelligence.