Zero is not an app. It is what it is when it is.

A seed document. Read it before you build on the mobile / universal apps, and add to it as the idea grows. It is written for the next agent (human or model) so the *why* survives the *what*.

The one idea

Zero is not an application. It is a universal substrate — closer to an operating system than to an app — that becomes what the moment demands.

One install. The same engine on the same device is:

• your employee's office when they sign in to work,

• an e-commerce storefront when a customer visits them,

• an order desk for the person fulfilling those orders,

• a parcel scanner on a warehouse handheld,

• a payment terminal at a counter,

• a living-room assistant on a TV.

Not different apps. The same engine, becoming a different thing — decided at that time, by *who* is asking, *where* they are, and *what* they came to do.

It is universal not only in availability (it runs on every device) but in capability and identity (it is whatever it must be, when it must be it). *What it is, is what it is at that time.*

Why this is even possible

Because of what Zero already is (see [zero9-store-architecture] and the engine): a tiny C++ tree-walking interpreter of a filesystem-tree DSL.

• A class is a folder; .action files are its methods; .data is state;

inheritance is parent =. The whole class library — *all behavior* — lives in the store, refreshed by store.push. Updating behavior is not a release.

• The engine is dependency-light (~4,400 LOC, libcurl + system crypto) and

already builds with a static dispatch table (no dlsym) — so it links into a sandboxed mobile app, not just a server.

• The desktop app proved the shape: it is not an app, it is a door. A thin

native shell (window + webview + engine) — *everything it shows and does is zero executing actions on this machine as a real node.* See desktop/main.mm.

The mobile apps are that same door, on every other device. Nothing about "becoming" is new machinery — it is the store + identity + the door, carried to the phone, the TV, the terminal, the handheld.

The three laws (design invariants — do not break these)

1. The engine is the only universal floor. Everything else is a capability.

Intelligence (the LLM), screen control, scanning, payments — none of these are "the app." Each is a *thing / class / action*, installed per device, at the time it is needed, by what that device is *for* and what it *can do*. A flagship phone installs the model-manager and runs a local model; a TV or a parcel scanner installs none of that. We do not decide what a device is — the capability profile and the store do. See [mobile/ARCHITECTURE.md].

2. We execute actions. We do not "do things." The construct that *the app can

do anything on the device* is explicitly not ours. We ship an execution substrate; what it can do is exactly: the capabilities installed × the OS permissions granted × the zcap grants authorized. Three independent gates, none of them "because the app felt like it." A screen-control or payment capability is *present* only when the store installed it, the OS granted the permission, and a grant authorized the act.

3. Behavior comes from the store; the native floor comes from the shell.

DSL capabilities (classes/actions) arrive from the store and light up instantly — no app release. *Native* capabilities (on-device inference, Android Accessibility, camera/scanner) are compiled into the shell and can only be added by an app update. The capability profile is the contract between them: the store *requests* a capability; it lights up if the installed shell can back it, else the app asks to update. Be honest about which tier a feature lives in.

Intelligence is a provider, not a dependency

The oracle primitive (the LLM) is provider-abstracted. We own the *interface* and the *routing policy* — never a single model, and never a single external brain as the *only* path. oracle resolves, per device profile, to one of:

• local — an on-device runtime (an existing library, e.g. llama.cpp; models

are plain GGUF *data*, App-Store-legal, downloaded from the open ecosystem),

• bring-your-own remote — the *user's own* subscription or API key (their

ChatGPT, their Claude, their key),

• a peer node on their mesh — the TV borrows the desktop's brain over iroh.

A capable device runs local; an incapable device (TV, low-power, a payment terminal) delegates. Every capable device can always fall back to fully-local, so the product never *requires* someone else's model to function. That guardrail is the whole point: own the routing, rent the model.

What "trillion-dollar" actually requires (the bet)

Not features. The substrate. If the same install can *become* any business-facing or personal surface, on any device, with behavior shipped from a store and intelligence routed per device — then every employee, every customer, every handheld, every counter is one node in one mesh, and new "apps" are new *classes*, not new downloads. That is the leverage. Protect it: resist every temptation to make the shell special-case a feature that belongs in the store, or to bake a capability the profile should choose.

Where to go next

• [roadmap/consolidation.md] — the settled track map: per-platform release

(incl. Raspberry Pi / 32-bit ARM), compiled-view distribution, the versioned runtime, and the built-vs-planned status of every track. Start here for the whole shape.

• [roadmap/versioned-runtime.md] — how the substrate evolves itself: a

versioned schema + engine + migrations + verification, designed so an LLM can author/version/run/verify and improve its own execution platform.

• [mobile/ARCHITECTURE.md] — how the two shells, libzero, capability

profiles, the oracle provider, and device-control-as-actions fit together.

• [mobile/BUILD.md] — building libzero per platform and the app shells.

• desktop/main.mm — the desktop door, the shell pattern the mobile shells mirror.

• kernel/embed.h / kernel/embed.cpp — zero_serve(), the in-process engine.

[zero9-store-architecture]: ../ (see the engine + store design) [roadmap/versioned-runtime.md]: roadmap/versioned-runtime.md [roadmap/consolidation.md]: roadmap/consolidation.md [mobile/ARCHITECTURE.md]: mobile/ARCHITECTURE.md [mobile/BUILD.md]: mobile/BUILD.md