01 — What Zero Is

In one sentence

Zero is a shapeless software substrate — closer to an operating system than to an app — that has no inherent form and becomes what the moment demands by assembling itself, on demand, from versioned building blocks held in stores.

In plain English

Most software is a *thing*: a fixed application, written by hand, frozen the day it ships, and bound to one device or platform. To change what it does, someone writes more code and ships a new release. To run it somewhere new, someone ports it.

Zero starts from the opposite end. On its own it is almost nothing — a tiny program whose single innate power is to execute action-files. It has no screens, no features, no opinions. It is, in effect, a "hello world" with one superpower: it can run instructions written in a small language, and those instructions can pull in *more* instructions from the outside world.

So Zero constructs itself. Point it at a description of what it should be, and it fetches exactly the pieces it needs — the behavior, the data, the look — assembles them into a running thing, does the job, and keeps only what that job required. The same install, on the same device, can be an employee's office when they sign in, a storefront when a customer visits, a scanner on a warehouse handheld, or an assistant on a TV. Not different apps — the same engine becoming a different thing, decided at that moment by *who* is asking, *where* they are, and *what* they came to do.

The pieces it assembles from are folders. Each folder is a self-contained block: some actions (what it can do) plus some data (what it knows). Folders reuse each other's actions, and they cross-connect on demand — brokered, when needed, by an LLM (running locally, via your own key, or borrowed from a peer device). Each folder is, in effect, a small intelligent thing. Compose them and you can build anything; and the library of folders only ever grows.

Two more properties make it unusual:

• It evolves itself. Given a goal, Zero can author new actions, run them, and

verify the outcome against a known-good result before keeping the change — and every version is saved, so any past version can be run again at will. The system improves its own execution platform, and a deterministic check (not a human reviewer) guards correctness.

• It hardens as it grows. The edges change at a rapid pace — that is the point.

But Zero's own core is on a deliberate path of code reduction: the kernel converges, shrinks, and resists change, because everything that *can* live in the store is pushed out of the engine. The floor gets smaller and more permanent over time; the world above it gets richer.

In mechanism (the precise version)

Zero is a thin C++ tree-walking interpreter of a filesystem-tree DSL. The whole system rests on a handful of facts that are true in the code today:

1. The kernel is the irreducible floor. main() parses one request of the form

<object>.<action>, loads exactly one seed action (boot), and runs it. Everything else — locating the object, loading its class chain, routing, rendering — is self-hosted in the DSL. The native engine is ~2,400 lines with ~80 built-in primitives. (kernel/main.cpp)

2. Action-files are the unit of behavior. An action is a plain-text .action

file; the filename is the action's name and the body is a short list of statements (return, if/ifnot, foreach, a native call functions/<name>, or a call to another action). (kernel/exec_statement.cpp)

3. A folder is a class is a block. .action files are its methods, .data is

its state, and parent = gives single inheritance. A class library — *all behavior* — lives in stores, not in the binary. (functions/core/loadchain.cpp)

4. Stores deliver the world on demand. A class the machine lacks is pulled once

over HTTP and is local from then on (copy-on-hydrate). One cache serves every home, folder, and user. (kernel/remote_store.h)

5. The DSL and the engine are versioned together. The engine declares a schema

window [kSchemaMin, kSchemaMax]; a class can carry a .schema marker; a load-time gate refuses-above / migrates-below / runs-in-window. No flag day — borrowed from how browsers and Kubernetes version their APIs. (kernel/interp.h, functions/core/loadchain.cpp)

6. Intelligence is a provider, not a dependency. The oracle primitive (the LLM)

resolves per device to local (llama.cpp + GGUF), bring-your-own key, or a peer node over an encrypted mesh — never one hardcoded brain, always able to fall back to fully local. (../VISION.md, "Intelligence is a provider")

7. It runs everywhere from one library. The same engine (zero_serve()) is a

child process on desktop and an in-process call on mobile, behind a thin native shell that is "not an app — a door." (kernel/embed.h)

What Zero is *not*

• Not an app, and not an app framework. It ships no fixed product surface.

• Not "the AI." The model is a routed provider behind one interface, never the

engine and never a required external brain.

• Not a system that "does things" on your device. It *executes actions*, and what

an action can do is exactly: capabilities installed × OS permissions granted × grants authorized. Three independent gates. (../VISION.md, "The three laws," Law 2)

The tension to hold (read this carefully)

Zero is built to change at a rapid pace at the edges and to settle and resist change at the core, simultaneously. These are not in conflict — they are the same design choice seen from two ends:

• Behavior, data, look, and even speed (compiled views) ship from the store, and

can change as fast as a model can author and verify them. No release required.

• The engine is held to a north-star of *code reduction*: anything that can be

pushed into the store is pushed out of the binary, so the floor converges toward a small, stable, near-permanent core.

The result is a system whose surface area is effectively unbounded and whose trusted base is deliberately tiny and shrinking. That is the whole bet — and the rest of this folder is about why it is possible and what it is worth.