COVENANT LABS · THE KERNEL · NOD3
NOD3
The execution engine. Where intent becomes typed, signed, executed work.
K.1
Overview
NOD3 is the execution engine of the sovereign AI operating system. It turns objectives into verified, typed, composable actions and runs them on a signed trust boundary. An agent here is not an opaque conversational process. It is a structured set of typed actions with explicit contracts, and the engine is what selects, composes, and executes them.
Because the execution model is discrete and typed, every decision the system makes is inspectable: what it planned, what it attempted, what it concluded.
K.2
Primitives
| PRIMITIVE | DEFINITION |
|---|---|
| ACTION | The smallest primitive. A typed, signed, pre-compiled unit of work with an explicit contract: schemas, method, path, timeouts. Actions are registered to the engine and run only in approved, compiled form. |
| OBJECTIVE | A composition of actions negotiated and compiled into an executable workflow. Objectives are planned before they run. |
| WORKFLOW | A compiled objective. Everything composes, so a whole workflow can collapse into a single action and be reused. |
K.3
Execution model
No tool calls
The engine does not rely on model-triggered tool calls, a common failure mode in other agent systems. Actions are invoked through a hard schema, which removes a whole class of misfires and makes execution fully asynchronous: work is dispatched and runs in parallel where dependencies allow, rather than blocking a chat loop.
Plan before executing
Higher-order agents build a dependency graph of what must happen and in what order, then coordinate sub-agents through explicit interfaces rather than unstructured prompt delegation.
Compile, execute, record
An objective is negotiated, compiled, and executed, and every outcome is written to an execution ledger: the lineage of what succeeded, what failed, what has already been solved.
K.4
Objective negotiation (actor-critic)
The engine negotiates objectives through an actor-critic loop. Today the user is the critic, with the model assisting. The roadmap moves toward making negotiations legible enough in plain English that an LLM critic can reliably catch bad compositions, evolving toward a hybrid user/LLM critic model.
Until that hardening lands, the safe default is to deploy pre-compiled actions and hand out keys that can only invoke them. This avoids catastrophic failures from over-delegating objective creation to the model.
K.5
One system with the graph interface
NOD3 is the execution substrate beneath the graph interface, and the two are built to feel like a single system. The graph is where the user thinks and keeps memory; the engine is where intent becomes executed work. The handoff between them is the core of the kernel experience.
Intent in, execution out
A command issued from the graph interface arrives at the engine as the user's intent plus the selected action and the current graph context. The engine parses it into the action's hard schema, compiles, and runs it. The user expresses what they want; the engine guarantees it runs as a typed, signed, approved action.
Non-blocking by construction
Because there are no tool calls, execution is decoupled from the conversation. A user can dispatch several long-running objectives and keep working while the engine executes them in parallel, each against the state captured when it was issued.
Results return as context
The engine returns structured results that the graph interface either folds back into the graph as durable memory or treats as a completed side effect. The execution ledger keeps the full lineage, so the surface stays inspectable: what was planned, attempted, and concluded.
One surface, governed underneath
The graph interface stays simple and human; the engine stays typed and governed. Scoped API keys mean a user can only invoke the actions they are authorized for, so the friendly interface never widens the trust boundary.
K.6
Deployment topology
| TIER | UNIT | ROLE |
|---|---|---|
| 01 | CUSTOMER | The tenant boundary and authority domain. |
| 02 | ENGINE DEPLOYMENTS | One or more privileged deployments, scoped per team or division. |
| 03 | GRAPH WORKSPACES | Per-user consumers connected through scoped API keys. |
The engine is a privileged system. Only a system administrator or key holder operates it; graph workspaces are consumers connected via scoped API keys. It is backed by Postgres and needs no artifact storage beyond backups.
Separating engine deployments per team contains failure and limits blast radius: a compromise or bad command in one team's deployment cannot reach another's. If Betty in HR runs the wrong command, only HR is affected.
K.7
Security model
The signing and trust boundary is documented separately: a root key, derived per-action keys, signed registration, and invocation verified against the engine's public key. Only holders of the root key can register actions, and only engine-signed requests can invoke them. The action surface needs only the engine's public key.
K.8
Status and roadmap
Operational model proven; first secured deployments in progress. Near term: an action builder so teams can author and publish their own actions and workflows safely, stronger objective-negotiation critics, and the security-model hardening path (per-action key provisioning, replay protection, KMS/HSM, result signing).