wanderland-sota-assessment

Wanderland: State of the Art Assessment

A critical analysis of an AI-native knowledge graph that maps to fifty years of computer science

Executive Summary

Wanderland is not a documentation system that happens to execute code. It is a compiler-database hybrid where:

The source format is prose (markdown with fences)
The linker fetches data from external systems (AWS, JIRA, APIs)
The runtime is graph navigation with accumulated context
The output is whatever middleware decides to project

The architecture maps cleanly to established patterns from compilers, databases, and distributed systems—not by analogy, but by structural isomorphism.

The Compiler Model

Traditional Compiler

Source → Lexer → Parser → AST → Linker → Executable
                                   ↑
                          [fills in addresses]

Wanderland Compiler

Markdown → Tokenizer → AST → Resolver → Rendered Output
                              ↑
                     [fills in data from external world]

The linker phase is where Wanderland diverges from traditional document systems. When processing a fence like:

# fence with service=ec2, method=describe_instances
instances = boto3.client('ec2').describe_instances()

The system doesn't just store the code—it executes it and splices the result into the stream. This is relocation. The fence is a hole. The linker fills it with data fetched from the external world.

The Cache Levels Map to Compilation Stages

Compiler Stage	Wanderland Level	What Happens
Source	seed (L0)	Raw tokens in file
Preprocessed	sprout (L1)	Variables substituted
Compiled	stalk (L2)	Components expanded
Linked	data (L3)	Fences executed, external data fetched
Optimized	clouds (L4)	Middleware transforms applied

The progression is deterministic and reproducible. Given the same source and external state, you get the same output. This is compilation semantics applied to documents.

The Database Model

Query Plans as Streams

From spatial-database-engineering-patterns: a query plan is an instruction stream where operators are holes that get filled with data at execution time.

SELECT → [Filter] → [Join] → [Project] → Result
            ↑          ↑          ↑
         [rows]     [rows]     [columns]

Wanderland Documents as Query Plans

Document → [Fence₁] → [Fence₂] → [Include] → Rendered
              ↑          ↑           ↑
           [AWS]      [JIRA]      [Node]

The document IS the query plan. Fences are operators. Navigation is query execution. The renderer is the executor that fills holes and produces output.

The Vocabulary Unlock

Once you see this isomorphism, database research applies directly:

Database Concept	Wanderland Equivalent
Materialized view	Cached render at any level
Query optimizer	Cache level selection
Secondary index	FenceIndex (fence discovery by type/service)
Schema	Fence input/output contracts
Schema evolution	Provenance tracking with hash drift detection
EXPLAIN	`oculus_look` with format='graph'
Transaction log	Git history + provenance changelog

The Lebowski Architecture

The Rug Pattern

From lebowski-corollary: in distributed systems, you need exactly one source of truth. Everything else is derived opinion.

┌─────────────────────────────────────────┐
│  OPINIONS (middleware output)           │
│  "just, like, your opinion, man"        │
├─────────────────────────────────────────┤
│  DATA (fence execution output)          │
│  RUG #2 - sacred, immutable             │
├─────────────────────────────────────────┤
│  CONTENT (raw markdown)                 │
│  RUG #1 - THE source of truth           │
└─────────────────────────────────────────┘

Handing to The Dude

Once the stream is fully populated (all fences executed, all includes resolved, all variables substituted), you have a linked artifact. This is when you hand it to "the dude"—the next stage that consumes the populated stream.

The dude might be:

A renderer producing markdown
A middleware chain producing transformed JSON
An AI agent consuming structured context
A human reading documentation

The dude doesn't care how the stream got populated. The dude just abides.

The WAL/Kafka Pattern

Event Sourcing in Wanderland

The source file is append-only in spirit (git history preserves all states). Every modification is an event. The current state is a projection.

Event Log (git)     →     Current State (file)     →     Views (renders)
   immutable                 reconstructable              derived opinions

Middleware as Stream Processors

From middleware-pipeline-pattern: middleware runs at L3.5, after fence execution but before caching. This is Kafka consumer semantics:

Fence Output → [Normalizer] → [Cleaner] → [Extractor] → Cached Result
                   ↓              ↓            ↓
              (datetime→ISO)  (strip meta)  (project cols)

Each middleware is a stateless transformer. The pipeline is composable. Add/remove processors without changing the source or consumers.

Edge Middleware: Navigation as Event Stream

From edge-middleware: navigation transitions trigger middleware. Moving from node A to node B is an event that can:

Fire guards (authorization)
Execute on_enter/on_exit hooks
Transform context
Accumulate state in localStorage

navigate(A → B) → [middleware₁] → [middleware₂] → render(B, context')

The graph becomes a state machine where edges are transitions and middleware defines the transition logic.

The AI-Native Dimension

Why This Matters for AI

Traditional systems separate:

Documentation (for humans)
Code (for machines)
Data (for storage)

Wanderland unifies them:

Documentation IS code (fences execute)
Code IS documentation (prose explains)
Data IS both (embedded in the stream)

For AI agents, this means:

No format translation - The context is already in a form AI can consume
Executable specifications - "What it does" and "how it does it" are the same artifact
Provenance tracking - AI can verify what's been human-reviewed
Natural composition - Agents navigate the graph like humans read documents

The MCP Integration

Every fence can be a tool. The graph is a tool catalog. Navigation discovers capabilities. Execution invokes them.

# This fence IS the tool definition
# Execute it via MCP: oculus_execute_fence("my-tool")
result = do_something()

No separate tool registration. No external API definitions. The documentation of the tool IS the implementation of the tool.

Comparative Analysis

vs. Traditional Documentation (Confluence, Notion)

Wanderland: Documents execute, compose, have provenance
Traditional: Documents are static, require external tooling, drift from reality

vs. Literate Programming (Jupyter, Org-mode)

Wanderland: Graph structure, bidirectional navigation, unified query interface
Literate: Linear documents, one-way execution, notebook-centric

vs. Knowledge Graphs (Neo4j, Obsidian)

Wanderland: Nodes contain executable code, middleware transforms output
Traditional KG: Nodes contain data, queries return data

vs. Workflow Engines (Airflow, Temporal)

Wanderland: Workflows defined in prose, navigation is execution
Traditional: Workflows defined in code/YAML, separate from documentation

vs. API Gateways (Kong, Envoy)

Wanderland: Middleware in prose, transforms at render time
Traditional: Middleware in code, transforms at request time

The Innovation

The innovation isn't any single component. It's the structural unification:

One stream format (markdown with fences)
One linking strategy (fetch from external world at fence execution)
One mutation layer (middleware transforms at L3.5)
One query interface (MCP tools / graph navigation)
One provenance system (hashes that track drift)

Everything else—documentation, automation, AI context, human workflow—is a projection of this unified substrate.

Limitations and Tradeoffs

Performance

Not optimized for high-throughput data processing
Fence execution adds latency vs. cached static content
Graph navigation slower than indexed database queries

Complexity

Conceptual overhead: compiler + database + distributed systems mental models
Debugging requires understanding multiple abstraction layers
Not immediately obvious to newcomers

Scope

Best suited for operational knowledge, not transactional data
Not a replacement for actual databases, actual compilers, actual workflow engines
A unification layer that sits above specialized systems

External Validation

Perplexity AI literature review, 2026-01-01

Paper Deep Dives

xKG: Executable Knowledge Graphs for Replicating AI Research

October 2025, arXiv:2510.17795

Graph Schema

Three node types in a hierarchical multi-relational structure:

Node Type	Contains	Purpose
Paper Nodes (𝒩_P)	Metadata, links to techniques/code	Root container
Technique Nodes (𝒩_T)	Self-contained concepts, definitions, sub-components	Academic knowledge
Code Nodes (𝒩_C)	Implementation σ, test script τ, documentation δ	Executable units

Two edge types:

Structural: technique → technique (architectural dependencies)
Implementation: technique → code (concept-to-execution link)

What Makes It Executable

Three-step automated construction:

Technique Extraction - LLMs deconstruct papers into hierarchical technique trees
Code Modularization - Retrieved snippets go through "iterative self-debugging loop to verify executability"
Knowledge Filtering - Techniques without working code get pruned

Provenance

Full traceability from code → GitHub repo → arXiv paper
Explicit blacklisting to avoid data leakage
Graph structure preserves origin chain

Wanderland Comparison

xKG	Wanderland
Extracts from existing artifacts (papers + GitHub)	Authors directly as primary substrate
Code Nodes contain (implementation, test, docs)	Fences contain executable code inline
technique→code edges link concepts to execution	Prose→fence relationship within single node
Automated construction pipeline	Human-AI collaborative authoring
Read-only knowledge base	Read-write executable substrate

Key difference: xKG is an extraction system that builds graphs FROM artifacts. Wanderland is an authoring system where the graph IS the artifact.

Renaissance of Literate Programming in the Era of LLMs

February 2025, arXiv:2502.17441

Core Argument

Traditional literate programming (Knuth) hasn't been fully leveraged for LLM-assisted development. The authors propose Interoperable Literate Programming (ILP) - combining code with natural language documentation to help LLMs better understand and generate code.

Key Contributions

ILP Document Structure - Structured approach for interweaving prose and code that LLMs can parse
Prompt Engineering Method - Documentation format that guides LLMs toward better code generation
Benchmark Results - Tested on RepoBench with Scheme and Python, showing improvements for large-scale projects

The Gap They Identify

LLMs struggle with "complex interdependencies and extensive size of modern codebases." ILP addresses this by making the narrative explanation machine-parseable alongside the code.

Wanderland Comparison

ILP	Wanderland
Prose guides code generation	Prose IS the code (fences execute)
Documentation format for LLM consumption	Documentation format that IS computation
Helps LLMs write better code	LLMs operate the existing executable graph
Focus on code generation	Focus on knowledge management + execution

Key difference: ILP is about helping LLMs generate code better. Wanderland is about making the documentation itself the executable substrate - there's no separate "code" to generate.

Docs2KG: Unified Knowledge Graph Construction from Heterogeneous Documents

June 2024, arXiv:2406.02962

The Problem

"80% of enterprise data resides in unstructured files" - emails, PDFs, web pages, spreadsheets. Current approaches are domain-specific or require pre-designed schemas.

Pipeline Architecture

Dual-path processing:

Image Converter - Deep learning for layout analysis → segments into texts, images, tables with bounding boxes
Markdown Converter - Structural parsing → enables XPath-style queries

Document-specific parsers:

PDF: Routes based on metadata (scanned vs. generated)
Web pages: BeautifulSoup + markdownify
Excel: pandas + imgkit → Image Converter
Email: Python email library → segment into text, HTML, attachments

Graph Schema

Two relationship categories:

Intra-modal (within document):

Structural: has-child, before, after
Semantic: same-time, focus, supported-by, explain

Inter-modal (cross-document):

Sentences → tables/figures via explain, same-time

Node hierarchy: documents → pages → paragraphs → sentences + images + tables

Wanderland Comparison

Docs2KG	Wanderland
Extracts structure FROM existing documents	Imposes structure AT authoring time
ETL pipeline builds graph	Graph IS the authoring substrate
Read-only extraction	Read-write executable medium
Dynamic schema from document structure	Fences define executable contracts
External process constructs graph	Document saves trigger provenance

Key difference: Docs2KG tries to RECOVER structure from documents that weren't written with structure in mind. Wanderland IMPOSES structure at authoring time - the graph isn't extracted, it's authored.

Loops: Leveraging Provenance and Visualization for Notebook Analysis

VIS 2024, Utah Visualization Design Lab

Publication | GitHub

The Problem

Computational notebooks have "challenges with code quality, recall, and reproducibility" because their linear structure conflicts with iterative analysis practices.

What Loops Does

A JupyterLab extension that:

Captures provenance - Automatically tracks notebook history
Visualizes evolution - Shows notebook changes over time
Highlights differences - Compares versions across code, markdown, tables, visualizations, images
Traces impact - Shows how modifications cascade through dependent analyses

Provenance Tracking

Monitors changes across entire notebook lifecycle
Enables reconstruction of analysis journey
Identifies what changed between states
Makes analytical process transparent

Wanderland Comparison

Loops	Wanderland
Tracks notebook cell provenance	Tracks document + fence provenance
Visualizes version differences	Hash-based drift detection (🔴→🟡→🟢)
Notebook-centric (single file)	Graph-wide (whole corpus)
Provenance for reproducibility	Provenance for human verification
Post-hoc visualization	Inline status indicators

Key difference: Loops visualizes provenance AFTER the fact for reproducibility research. Wanderland embeds provenance INTO the substrate for continuous verification - the stoplight is always visible.

MCP: Model Context Protocol and Agentic Workflows

November 2024 - present, Anthropic → Linux Foundation

Specification | Anthropic Announcement

What MCP Is

Open standard for AI systems to integrate with external tools, systems, and data sources. Uses JSON-RPC 2.0 for communication. Inspired by Language Server Protocol.

Architecture

Host Application (VS Code, web app, etc.)
    ├── Agent Component (AI intelligence)
    └── MCP Client Component (server communication)
            ↓
    MCP Server (provides tools, resources, prompts)

Tool Definition

MCP defines tools with:

Structured descriptions (inputs/outputs)
Execution semantics
Security boundaries

Tools are "arbitrary code execution" - descriptions are untrusted unless from trusted server.

2025 State

Adopted by OpenAI (March 2025)
Donated to Linux Foundation's Agentic AI Foundation (December 2025)
Thousands of community-built servers
SDKs for all major languages
De-facto standard for agent-tool integration

Wanderland Comparison

Standard MCP	Wanderland MCP
Tool definitions separate from docs	Fence IS the tool definition
Server provides tools to agents	Graph IS the tool catalog
Register tools in server code	Write fence, tool exists
Docs describe what tools do	Docs ARE what tools do
Sync docs with implementation	No sync needed - same artifact

Key difference: Standard MCP maintains separation between "the tool" and "docs about the tool." Wanderland collapses this - the fenced code block IS the tool, IS the documentation, IS the implementation. No second representation to keep in sync.

Position Relative to Current Research

"Wanderland's assessment describes an AI-native, executable knowledge graph substrate that is very close to (and in a few places ahead of) current state-of-the-art work on executable knowledge graphs, literate programming with provenance, and MCP-based agentic workflows."

Key Comparisons

Research Area	Current SOTA	Wanderland Position
Executable Knowledge Graphs (xKG)	Extract code from papers/GitHub, wire together for replication	Author and maintain executable graph directly as primary substrate
Literate Programming + Provenance	Notebook-centric provenance tracking	Whole corpus as versioned multi-stage compilation pipeline
Docs2KG Pipelines	Recover structure from static documents via ETL	Impose computable structure at authoring time
MCP Tool Ecosystems	Separate tool definitions from docs, keep in sync	Fence definition IS the tool, no second representation

The Inversion

"Wanderland's unification layer—markdown as the one stream format, fences as operators, middleware as the single mutation layer, and graph navigation as the query interface—aligns with this trajectory but inverts the stack: knowledge work lives in the executable doc graph, and specialized systems (APIs, infra, workflows) are just things the fences point at."

Ahead of Current Research

The stoplight provenance system (🔴→🟡→🟢) with hash-based drift detection:

"The 'unverified virtual fences' and stoplight-style provenance are a concrete, deployed embodiment of what many contemporary papers are still exploring in narrow domains like research replication or data science notebooks."

Reference Papers

xKG: Executable Knowledge Graphs for Replicating AI Research
Literate Programming + LLMs: Renaissance of Literate Programming in the Era of LLMs
Docs2KG: Unified Knowledge Graph Construction from Heterogeneous Documents
MCP Agentic Workflows: Building Agentic AI Workflows with MCP
Notebook Provenance: Loops: Leveraging Provenance and Visualization

Conclusion

Wanderland is a proof by construction that:

Documents and programs are structurally isomorphic
The compile/link model applies to knowledge management
Database query semantics apply to document rendering
Distributed systems patterns (event sourcing, CQRS) apply to prose

The bet is that operational simplicity outweighs performance cost for knowledge work. You trade peak throughput for unified reasoning. You trade specialized tooling for composable primitives.

Fifty years of computer science didn't need to be reinvented. It needed to be recognized as applicable to a domain (documentation/knowledge) that historically ignored it.

The rug really does tie the room together.

Assessment Date: 2026-01-01 Assessor: Claude (Opus 4.5)

North

slots:
- slug: structural-isomorphism-thesis
  context:
  - The theoretical foundation this assessment builds on
  - SOTA assessment builds on structural isomorphism thesis

East

slots:
- slug: streams-all-the-way-down
  context:
  - The realization that sparked this architecture
  - SOTA assessment references streams insight
- slug: spatial-database-engineering-patterns
  context:
  - Database patterns that apply to document processing

West

slots:
- context:
  - The distributed systems principle underlying the cache architecture
  - SOTA assessment references Lebowski architecture
  slug: lebowski-corollary
- context:
  - Paper references SOTA assessment for detailed comparisons
  slug: wanderland-paper

South

slots:
- slug: middleware-pipeline-pattern
  context:
  - Implementation of the WAL/middleware layer
- slug: edge-middleware
  context:
  - Navigation as event stream with middleware transforms

Provenance

Document

Status: 🔴 Unverified

Fences

wanderland-sota-assessment-traditional-compiler-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-wanderland-compiler-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-wanderland-compiler-fence-1

Status: 🔴 Unverified

wanderland-sota-assessment-query-plans-as-streams-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-wanderland-documents-as-query-plans-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-the-rug-pattern-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-event-sourcing-in-wanderland-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-middleware-as-stream-processors-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-edge-middleware-navigation-as-event-stream-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-the-mcp-integration-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-north-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-east-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-west-fence-0

Status: 🔴 Unverified

wanderland-sota-assessment-south-fence-0

Status: 🔴 Unverified

↑ northstructural-isomorphism-thesis

↓ southmiddleware-pipeline-patternedge-middleware

→ eaststreams-all-the-way-downspatial-database-engineering-patterns

← westlebowski-corollarywanderland-paper