#+TITLE: The OpenCortex Vision — A Strategic Blueprint
#+AUTHOR: Amero
#+FILETAGS: :strategy:roadmap:vision:
#+STARTUP: content

* The Vision: A Neuro-Symbolic Lisp Machine

OpenCortex is not merely another AI agent. It is an attempt to build something deeper — a sovereign computing environment where the agent and its operator share the same language, the same data structures, and the same memory. It is a return to the dream of the Lisp Machine, updated for the age of neural networks.

The core insight from months of discussion with Gemini is this: the future of personal AI is not about bigger models, but about smarter architecture. We do not need an AI that guesses. We need an AI that reasons — backed by hardware that enforces safety, and software that grants its operator absolute sovereignty over their data.

This document captures the philosophical foundations, technical architecture, and strategic roadmap that emerged from those conversations. It is written for the engineer who will build it, the user who will trust it, and the future historian who will ask: "Why didn't the world run on Lisp?"

* Philosophy: Why This Matters

** The Sovereignty Imperative

Every other AI agent runs on a stack of dependencies — Python packages, npm modules, pip installs, conda environments. When the maintainer walks away, the stack rots. When the company shuts down, your data dies in their database.

OpenCortex is different. It runs on SBCL alone. The kernel is Lisp. The skills are Lisp. The memory lives in Org-mode files you already own. There is no database to migrate, no schema to update, no lock-in to escape. Your data is a folder of text files. It survives app updates, platform switches, and decades of use.

This is not nostalgia. This is engineering pragmatism. The simplest stack is the most maintainable stack.

** The Deterministic Safety Promise

Modern AI agents are terrifying. They pipe LLM output directly into your terminal. If the model hallucinates, it can delete your files or push secrets to GitHub. Safety is added as an afterthought — a wrapper around a dangerous core.

OpenCortex splits the brain into two parts:

1. The Creative Brain (LLM): Understands your notes, suggests actions, generates code.
2. The Strict Guard (Lisp): Before the AI is allowed to touch a file or run a command, a mathematically strict set of rules intercepts the proposal. It verifies the action is safe and permitted. If the AI hallucinates, the guard blocks it.

This is not "guardrails" in the marketing sense. This is hardware-level type checking — impossible to bypass, because the logic is embedded in the execution path.

** The Homoiconic Advantage

Lisp is the only major language where code and data have the same representation. In Python, the AST is a foreign object — the agent can inspect it, but not treat it as something it owns. In Lisp, the agent can read its own code the same way it reads a text file. It can parse its skills, understand their structure, and modify them at runtime.

This is not a party trick. This is the foundation for a self-improving agent. The agent can fix its own bugs, refine its own strategies, and grow more capable without human intervention.

** The Neuro-Symbolic Synthesis

Pure neural AI is a black box. Pure symbolic AI is a straitjacket. The future is both together — a hybrid where the neural engine handles pattern recognition and the symbolic engine handles reasoning.

The 10-80-10 Architecture:
- 10% Neural (Input): A fast model translates messy human language into a structured query.
- 80% Symbolic (Reasoning): A rigid logic engine runs against a Knowledge Graph, checking consistency, enforcing rules, verifying truth.
- 10% Neural (Output): A model turns cold facts back into warm, natural language.

This is not theoretical. It is the architecture of the human brain — System 1 (neural intuition) and System 2 (symbolic reasoning) — rendered in silicon and Lisp.

* Bits Leading to v1.0.0

Before we achieve SOTA parity, we must lay the groundwork. These are the incremental improvements that make the later versions possible.

** Self-Editing and Self-Improving

The agent must be able to modify its own code. Not just fix syntax errors — but learn from outcomes. When the agent encounters a failure, it should analyze why, update its strategy, and try again.

Key implementations:
- Paren-balancing for syntax errors (deterministic)
- LLM-guided surgical fixes (probabilistic)
- Memory snapshots before every edit for safe rollback
- Hot-reload skills without restarting the agent

This is the foundation of autonomy. An agent that cannot edit itself is a tool. An agent that can is a partner.

** The Symbolic Bouncer

The Bouncer is not a static wall. It is a learning system.

1. HITL Exception: When the LLM proposes an unrecognized action, the Bouncer suspends the thread and writes to Org-mode. A human reviews, changes BLOCKED to APPROVED.

2. Lisp Rule Synthesis: When approved, the system generalizes the parameters, compiles a new safety rule, and applies it to future requests.

3. Shadow Mode: The Bouncer runs in "trial mode" — simulating execution, observing side effects, teaching itself patterns.

4. Formal Property Verification: SystemVerilog-style assertions ensure updates are rejected at the hardware level if they violate core invariants.

** Memory Safety

State rot is the enemy of long-running agents. We implement:
- Atomic snapshots for instant recovery
- Transactional rollbacks for safe undo
- Compaction events that extract facts to Org-mode and wipe active context
- Semantic isolation between tasks to prevent contamination

** The MCP Strategy

We do not wrap OpenClaw. We build a native Lisp MCP Host.

The rationale: OpenClaw forces a Node.js runtime alongside the Lisp image. That's performance tax and bloat. A native host runs in the same memory space — no serialization, no IPC overhead, direct structural introspection.

Strategy: "Native Host, Universal Client" — connect to existing MCP servers without rebuilding their tools. Get ecosystem compatibility while keeping orchestration pure Lisp.

* v1.0.0: SOTA Parity

The goal: An agent competitive with commercial agents — Claude, Cursor, ChatGPT.

This is not about matching features. It's about proving the architecture works. The cognitive engine must be bulletproof. The safety invariants must hold under pressure. The agent must be able to:
- Handle multi-step engineering tasks
- Use tools reliably
- Maintain context across sessions
- Recover from errors gracefully
- Pass standardized benchmarks (SWE-bench, etc.)

The "parity" is not in the brand — it's in the capability.

* v2.0.0: Lisp Tools and GUI

Once the brain is proven, we give it a face.

** The Qt/QML Decision

We do not use WebView. It introduces a C++ dependency and memory overhead. We use Qt via EQL5 — a bridge that compiles Lisp directly into Qt binaries.

Why Qt/QML:
- Cross-platform native (Desktop + Mobile)
- Declarative — matches Lisp generation model
- Touch-native for mobile
- No IPC overhead (Lisp compiles to binary)

This is the "thin GUI" layer. It displays what the Lisp brain produces. It does not contain business logic.

** The Emacs Cannibalization

v2.0.0 is when OpenCortex begins to replace Emacs, not just run inside it. The agent becomes the process. The TUI evolves into a full interface. Org-mode buffers become the display layer for the agent's thoughts.

The "cannibalization" is not hostile. It's evolution. Emacs was always a Lisp Machine — we are completing its metamorphosis.

** Marketing Phrase

"OpenCortex isn't an app you run. It's an OS you live in."

* v3.0.0: The Symbolic Engine

This is where the neuro-symbolic architecture becomes real.

** The Knowledge Graph

We integrate VivaceGraph — a Lisp-native graph database with built-in Prolog. This is not an external database we connect to. It's part of the address space.

The symbolic engine maintains:
- Facts and relationships (Knowledge Graph)
- Rules and constraints (Prolog)
- Formal proofs (ACL2)

When the neural engine generates a response, the symbolic engine verifies it. When the neural engine claims something is true, the symbolic engine checks the chain of reasoning.

** The DSL Approach

We do not build a new engine. We build domain-specific languages.

Using Lisp macros, we create languages for specific domains:
- Legal compliance rules
- Medical protocols
- Financial constraints
- Project management workflows

The LLM bootstraps these DSLs — reading seed data, generating first drafts, refining with human feedback.

** Marketing Phrase

"OpenCortex doesn't just answer your questions. It proves its answers are correct."

* v4.0.0: The Lisp Machine

This is the final form. A computer where every level — from hardware to application — speaks Lisp.

** The Tagged Architecture

We move from simulation to silicon.

Using RISC-V as a carrier, we add custom extensions:
- Tagged memory (top 8 bits of every word = type)
- Hardware-enforced type checking (zero-overhead)
- Trap on type mismatch

This is not emulation. This is a CPU that understands Lisp at the gate level.

** The Hybrid Path

We don't build a Lisp Machine in isolation. We pair it with a neural accelerator.

The Tenstorrent p150 (664 TFLOPS) handles the heavy matrix math. The FPGA/ASIC handles the symbolic reasoning. They share a memory space. The Lisp core governs what the neural engine can and cannot do.

This is "Lisp as Governor" — not as the math engine, but as the orchestrator of computation.

** The FPGA Path

Before ASIC, we prototype on FPGA:
- Xilinx KCU105 for full PCIe integration
- Terasic DE10-Nano for learning

The journey: Verilog → RISC-V core → Tagged ALU → PCIe bridge → Self-hosting Lisp

** Marketing Phrase

"The first computer since the Symbolics that truly belongs to you."

* Cross-Cutting Themes

** The Technical Principles

1. *Lisp as Governor*: Use Lisp for orchestration, safety, introspection. Let specialized hardware handle dense math.

2. *Macro-Tags over Full Tags*: Tag tensors, not individual weights. 100% type safety with 0% memory overhead.

3. *S-expressions as Compiler Input*: Use Lisp for architecture description. Generate optimized code for target hardware.

4. *Hardware-Enforced Safety*: Tagged memory at silicon level — impossible to bypass.

5. *Hybrid Architecture*: Neural for intuition, Symbolic for reasoning, Lisp for governance. Each does what it does best.

** The Competitive Differentiators

| Feature | OpenCortex | Others |
|---------|-----------|--------|
| Language | Pure Common Lisp | Python/TypeScript |
| Memory | Org-mode files | SQLite/ChromaDB |
| Self-Modification | Native | Unsupported |
| Safety | Deterministic Bouncer | Probabilistic guardrails |
| Dependencies | SBCL only | pip/npm/conda |
| Data Ownership | 100% yours | Vendor lock-in |

** The Philosophical Stance

We are not building a chatbot. We are not building a copilot. We are building a sovereign computing environment — a digital home where your thoughts, your data, and your agent live together in plain text files you own.

The industry builds AI that runs in the cloud, on someone else's hardware, with someone else's models. We build AI that runs on your machine, in your language, governed by your rules.

This is not a product. It is a philosophy made manifest in code.

* References

- [[file:chats-with-gemini.org][Full Chat Transcripts]]
- [[file:../projects/passepartout/README.org][OpenCortex README]]
- [[file:../projects/passepartout/docs/ROADMAP.org][OpenCortex Roadmap]]
