Delivered only by itself — the proof is the running system

A seed + thesis document. Written for the next agent (human or model). It captures the

claim that closes the project: the platform delivers every app — and itself — using

nothing but actions on the one engine. Read [VISION.md](VISION.md) first (the *why*);

this is the *what-is-now-true*. Status: observed, not aspirational — the proof is this

repository, running. Every claim below points at a file you can read or a request you

can make. The honest seam (what is proven vs. what is mere accretion) is stated at the end.

The one idea

There is one universal floor — a few-thousand-line C++ interpreter that does exactly one

thing: execute versioned action-files. Everything else a person ever sees — the home

screen, a storefront, a clinic, the docs you are reading, the build that ships the app, the

sign-in that admits you — is a thing in the store: a folder of .action (methods) and

.data (state), interpreted at request time.

The closing claim is not "Zero *can* deliver apps." It is stronger and it is already true:

Zero delivers every category of software, including itself, using only itself —

and nothing else. There is no second mechanism. No special-cased feature in the

engine, no out-of-band runtime, no app that is "real code" while the others are data.

That is why there is nothing left to prove at the level that mattered. The thing that had

to be shown — *one substrate can be all software, delivered by that same substrate* — is

shown, by construction, in the folders next to this one.

Why "only itself" is literally true (the proof, not a hope)

The engine's own bootstrap is an action. kernel/main.cpp sets the request as member

data, loads ONE action — boot — and runs it. _core/boot.action then says, in its own

words, *"This action replaces the body of the old C++ main()… All in the DSL."* It loads

the rest of the engine's actions exactly the way a user class is loaded

(functions/loadactions). The engine discovers *what it is* by interpreting actions. So

even the floor presents its own logic as store content — the substrate is self-described.

The store IS every app. Walk the repository: there is no apps/ of "real programs"

beside a store of "mere config." The store folders *are* the programs. Every category of

software that exists has already been delivered here as actions over the one floor:

Each is the same shape — a folder, .action, .data, parent =. None of them taught the

engine a new word. The "App Store" and the apps in it are one substrate, refreshed by

hydration, not by a release.

Immune because it is all actions

The reason this can be opened to everyone — *"it can do literally anything"* — without the

floor being at risk is that what apps do never reaches the floor. Three facts make the

substrate invariant under everything authored on top of it:

1. Behavior is interpreted data, never linked code. Dispatch is a static name→pointer

registry (kernel/registry.cpp, generated by kernel/gen_registry.sh; embedded via

kernel/embed.cpp) — *not* dlsym of downloaded symbols. A class arriving from the

store is read and interpreted; it is never loaded as native code. (This is also exactly

what makes the engine notarizable on iOS.) An app cannot smuggle in machine code.

2. The DSL cannot widen the door. The shell sets the door (desktop/mobile/tv =

owner-trusted loopback; anything else = anonymous web). The DSL cannot change it — *a

store refresh can never turn a private door public* (kernel/identity.cpp,

kernel/dispatch.cpp; VISION "The door"). Access itself is fail-closed and evaluated on

every read (kernel/access.cpp, kernel/resolve.cpp).

3. Native power is gated three independent ways. A native primitive (camera, screen

control, payments, on-device inference) is present only when the capability was

installed, the OS granted the permission, and a zcap grant authorized the act

(VISION Law 2). The store can *request*; only the shell can *back* it.

So the floor is the same floor no matter what runs on it. "Do anything" means *anything

expressible as actions over the capabilities this device actually has* — and that bound is

not a limitation bolted on; it is the immunity. We execute actions; we do not "do

things."

What "nothing left to prove" honestly means

• Proven, by construction: that one substrate can *be* every kind of app, and that the

substrate *delivers* all of them — including its own bootstrap, its own docs, and its own

build/ship pipeline — *using only itself.* The repository is the QED.

• Not a proof, just accretion: the *breadth and polish* of any individual vertical

(clinic, government, …) and the planned phases of self-evolution

([versioned-runtime.md](./versioned-runtime.md), Phases 3–6) and the per-platform shells

(see [consolidation.md](./consolidation.md)). These are *more classes* and *more

finish* — never a new mechanism. Adding them does not prove the thesis again; it exercises

it.

That distinction is the whole point: once "all software is classes on one floor" is true,

shipping the next app is no longer research. It is authoring.

The evolution strategy that works forever

Why this does not age out:

• A new app is a new class, not a release. Capability ships from the store by

hydration; a reload *is* the latest app (ARCHITECTURE, "Update model"). There is no

version of the product to outgrow — only more folders.

• The floor does one thing, so it has nothing to make obsolete. It executes versioned

actions. Everything that could rot — UI frameworks, app logic, business rules — lives

above it as replaceable data.

• The language is allowed to drift toward whatever an LLM writes best, safely. The

versioned runtime lets schema and engine evolve on stamped axes with migrations on read

and an *outcome check* that earns the right to let the language go weird

([versioned-runtime.md](./versioned-runtime.md)). The reader of the language need not

stay human.

• It runs where there is no network and no one to trust. The store bakes into the app

(mobile/android/seed.sh, iOS Resources/store_seed → seedStore) and hydration is a

no-op when the folder is present (functions/fs/hydrate.cpp), so a sealed/offline

appliance is the same substrate with a thinner profile (see [deployments.md](./deployments.md)).

One floor, for any device, any deployment, any generation — because the floor is the only

thing that is fixed, and it was made deliberately small enough to never need to change.

Where to go next

• [deployments.md](./deployments.md) — the shapes this one substrate already takes: the

universal default floor, verified-vs-default lenses, offline/sealed appliances, single-

purpose nodes.

• [VISION.md](VISION.md) — the three laws this rests on.

• [lenses.md](./lenses.md) — who sees which face, with zero engine change.

• [native-rendering.md](./native-rendering.md) — one scene, every viewer draws itself.

• [versioned-runtime.md](./versioned-runtime.md) — how the substrate evolves itself.

• _core/boot.action — the engine's own main(), written as an action.