COVENANT LABS · THE KERNEL · THE GRAPH INTERFACE
The graph interface
Conversation, context, and memory as an explicit, branchable graph the user owns.
K.1
Overview
The graph interface is the front of the operating system: the graph-based workspace Alfred runs, with memory included. Conversation, context, and memory are explicit, branchable, and owned by the user. A conventional chat is a single linear thread that fills with noise and eventually degrades. Here the graph itself is the memory system. Durable, inspectable, reversible.
No memory hacks. Memory is not stuffed into an ever-growing context window or retrieved through opaque RAG; it is explicit in the graph. The user prunes and branches, and the system stays aligned to the task at hand.
| LINEAR CHAT | THE GRAPH | |
|---|---|---|
| MEMORY | implicit, window-bound | explicit, durable, reversible |
| CONTEXT | accretes until it degrades | assembled deliberately |
| DEAD ENDS | pollute the thread | branched off and abandoned |
| LIFETIME | forgotten and deleted | evolves over time |
K.2
Nodes and branching
A workspace is a graph of nodes. From any node you can branch into a new direction, carrying the relevant context with you. Productive directions are kept. Dead ends are abandoned without polluting the rest of the graph.
K.3
Node pressure
Node pressure is a measure of the load on the model's attention within a node. It is a function of both context length and semantic divergence. Talking about one coherent topic is low pressure; zig-zagging across unrelated topics splits attention and raises it.
When pressure gets too high, the system prompts the user to branch instead of degrading silently. This directly targets the attention-scaling failures that cause long single-thread chats to hallucinate.
K.4
Artifacts as injectable context
Artifacts (documents, files, outputs) are first-class, injectable context and durable, immutable state. They do not live in the chat history. The user injects an artifact into context by selecting it and removes it by deselecting it, so context is assembled deliberately rather than accreting.
| SCOPE · NODE | bound to a single node |
| SCOPE · GRAPH | the graph's own artifact repository |
| SCOPE · GLOBAL | available across all graphs |
K.5
Commands
Command mode interfaces with the execution engine. A command uses the current node's context plus any selected artifacts to invoke an engine action.
| DISPATCH | the user selects which action a command maps to; the model does not guess among hundreds of possible behaviors |
| SCHEMA | the request is parsed into the engine's required schema; execution proceeds on the state captured at issue time |
| EXECUTION | no tool calls; fully decoupled from the chat loop, asynchronous; multiple long-running commands at once |
| RETURN | injection is selective; some results fold back into the node ("summarize this page and bring it back"), others complete without touching it ("summarize this thread and email it to Will") |
Deciding what to inject and what to discard is the core UX problem the graph interface solves.
K.6
One system with NOD3
The graph interface and NOD3, the execution engine, are two halves of a single system. The graph is where a person thinks, branches, and accumulates memory; the engine is where real work gets executed. Together they close the loop between reasoning and doing inside one interface, which is the core of the kernel experience.
The graph is the working context
Whatever node you are on, plus the artifacts you have selected, is the live context. A command hands that exact context to the engine. You are not re-explaining state or copying things between tools; the place you are thinking is the place work is dispatched from.
Commands become engine actions
A command is parsed into the hard schema an engine action requires, then executed. The user expresses intent and picks the action; the engine handles typed, signed execution underneath. The user never touches raw schemas or keys.
Asynchronous by design
Because the engine uses no tool calls, a command never blocks the conversation. You can fire one or several long-running commands and keep working in the graph while they run; results return when they are ready.
Results flow back into the graph
Some commands return context that folds back into the node, like a summary you want to keep building on. Others complete on their own and simply report done, like sending an email. The system decides what to reabsorb as memory and what to leave as a completed side effect, so the graph stays clean.
Scoped and safe
Each deployment holds scoped API keys to its execution engine deployment, so a user can only invoke the actions and workflows they are authorized for. The interface stays simple while the execution layer stays governed.
K.7
Deployment and storage
| DEPLOYMENT | one per user, each with its own database and memory system |
| DATABASE | SQLite per deployment; single file, fast, portable |
| HOT / COLD | live database in hot storage on the VM; regular encrypted backups to cold storage |
| ARTIFACTS | stored encrypted in S3-compatible cold storage; pulled into temporary hot storage when needed |
K.8
Status
Early prototype under active development. The hard architectural problems (graph memory, async command execution, engine coupling) are solved at proof of concept. Current work is on the ergonomics: how command runtime state is surfaced, what context is injected, and rendering non-JSON outputs (PDFs, images) returned by commands. Early access is rolling out to a small internal group for feedback.