06 — FAQ

The answerable bundle: the questions an engineer, a buyer, or a skeptic will ask, with answers grounded in the rest of this folder. Grouped by who's asking.

What it is

Q. In one sentence, what is Zero? A shapeless software substrate — closer to an OS than an app — that becomes what the moment demands by assembling itself on demand from versioned blocks held in stores, on any device, with behavior shipped as capabilities and evolved by models under deterministic verification.

Q. Is it an operating system, an app, or a framework? Closest to an OS, but it is none of the three in the usual sense. It is a *substrate*: a tiny engine whose only innate power is to execute action-files, plus everything-else delivered as data from stores. It can be a boot-up OS at one end and a single app at the other — the same engine, different door and profile.

Q. Is this just an AI agent framework? No. Agents run *on* a substrate; Zero is the substrate. The engine predates and is independent of the LLM — intelligence is a *routed provider* behind one interface, and every capable device can run fully local. Remove the model and the engine still executes; add it and the system can author and evolve itself.

Q. What does "shapeless" actually mean? The engine ships with no screens, features, or opinions. It is effectively a "hello world" that can execute action-files and fetch more of them. What it *is* at any moment is decided by the data folder it's pointed at and the stores it hydrates from — "what it is, is what it is at that time."

How it works

Q. What's an "action file"? A plain-text .action file; the filename is the action name and the body is a short list of statements (return, if/ifnot, foreach, a native call, or a call to another action). One file, one function. (02-architecture.md §2)

Q. What's a "folder / thing / class"? Why are they the same word? A class is a folder: .action files are its methods, .data is its state, parent = is single inheritance. An *object* (a "thing") is an instance whose data names its class. Each folder is a self-contained, reusable, composable block. (02-architecture.md §3)

Q. How do folders "cross-connect"? Three ways: inheritance (parent =), explicit action calls between classes, and the oracle (LLM) brokering matches at runtime — e.g. thing.match pairs a thing's demands with the best local supplier and opens a conversation. (02-architecture.md §7)

Q. Where does behavior live, and how is it updated? In stores — directory trees cached locally and backed by a remote HTTP base. A class the machine lacks is pulled once and is local thereafter (copy-on-hydrate). Updating behavior is a store update, not a release; a reload is the latest. (02-architecture.md §4)

Q. How small is the engine, really? ~2,400 lines of C++ across ~23 files, ~80 native primitives, dependency-light (libcurl

• system crypto). Nothing application-specific is compiled in. (02-architecture.md §1)

Q. Is it fast enough if it's an interpreter? There are two engines for one schema: the tree-walker, and compiled C++ views that the store ships per-class, per-platform, loaded on demand. Hot classes run as native code; zero __bench measures it and ZERO_NO_COMPILED=1 A/B-tests it. (02-architecture.md §5)

Versioning & self-evolution

Q. What does "versioned DSL and engine" mean? The engine declares a schema window [min, max]; a class can carry a .schema marker; a load-time gate refuses-above ("update the engine"), migrates-below, or runs-in-window. No flag day — every node makes forward progress. (02-architecture.md §6)

Q. Does it really evolve itself? Yes — and it is honestly staged. Shipped: the verification pillar (functions/verify), content-addressed versions, run-any-version-by-hash, the evolution-loop page, and the crash-proof oracle interface. Frontier: wiring the oracle author-step to a live provider and an unattended driver that loops until verify accepts. The substrate is built; the remaining work is store/DSL orchestration, no engine change. (03-self-evolution.md)

Q. If a model rewrites the code, how do you trust it? You don't trust the model — you trust the outcome check. verify runs an action and compares its result to a known-good expected value; a change is kept only if it provably preserves behavior. That's what lets the language drift toward whatever a model finds optimal, even past human legibility. (03-self-evolution.md)

Q. Can a bad change brick a device? Authoring has a propose mode (human-gated staging) and a write mode. Every write is content-addressed and the live version is never disturbed by running an old one; any prior version is re-runnable by hash. (03-self-evolution.md)

Where it runs

Q. What platforms run today? Shipping on macOS; built on Linux, Windows, Android, iOS; running on Raspberry Pi / ARM and in Docker. Same engine library everywhere. (04-deployment-targets.md)

Q. Does it really run on microcontrollers / as a boot OS? Not yet — that's the aspirational end of the range and we say so plainly. What makes it credible: the engine is tiny, dependency-light, and statically linkable (the same property that put it in a sandboxed mobile app). Today: edge devices to servers. Designed to scale down to microcontrollers and up to a boot OS. (04-deployment-targets.md)

Q. How does one install become different things on different devices? A capability profile declares what a device is (door, start page, DSL capabilities, native capabilities, oracle routing). A weak handheld and a flagship phone run the same app; the profile is the only difference. (02-architecture.md §10)

Trust, identity, security

Q. Can the app do anything it wants on my device? No. It *executes actions*, and what an action can do is exactly: capabilities installed × OS permissions granted × grants authorized — three independent gates, none of them "because the app felt like it." (../VISION.md, Law 2)

Q. What's my identity? A recoverable Zero-ID (ZeroKey): a P-256 wallet whose scalar *is* your ID, shown as a recovery key, importable on any device — the same ID everywhere, never two. (02-architecture.md §9)

Q. How does remote access work without exposing my home? A mesh over a blind relay that forwards ciphertext only, encrypted endpoint-to-endpoint against a key the name directory pins rather than authenticates — confidentiality against the relay, not end-to-end encryption to a verified peer (../remote-access.md §5). Local doors are owner-trusted loopback; the web door is anonymous until a passkey proves a capability, and sessions are cryptographically proven, not asserted. (02-architecture.md §8, ../remote-access.md)

Q. Do I depend on your servers, or a particular AI vendor? Neither is required. Stores cache locally; the mesh relay is blind; intelligence is a routed provider that always has a fully-local fallback. We own the routing, you rent (or self-host) the model.

Commercial

Q. Who pays, and for what? Buy-then-build. The engine is the razor (cheap/open, wants to be everywhere); the blades are capability stores (buy a vertical base, build your cases on top, marketplace cut), per-node presence (each device is a billable node), and managed mesh/support. (05-investor-pitch.md)

Q. Who's the first customer? Edge & device fleets — retail, logistics, warehouses, field ops, hospitality: anyone running many devices that each need to be a different thing. One install, re-provisioned by profile, behavior from a store, no per-device app release. (05-investor-pitch.md)

Q. Why won't the cloud/AI incumbents just do this? The hard part is the discipline, not the parts: keeping the engine a tiny universal floor and pushing *everything* into a release-free store, plus a verifiable self-evolution loop and a recoverable-identity mesh. Incumbents are structurally inclined to fatten the platform and lock the model — the opposite of the bet. (05-investor-pitch.md)

Q. What's the moat? The composition of behavior-as-data + verifiable execution + content-addressed versioning

• provider-abstracted intelligence + release-free distribution + recoverable-identity mesh

— compounded by a self-evolution flywheel. (05-investor-pitch.md)

Skeptic's corner

Q. Isn't a self-rewriting system inherently unsafe? The safety *is* the verification gate plus content-addressed, re-runnable versions and a human-gated propose mode. Behavior change without a passing outcome check is rejected.

Q. Isn't "becomes anything" a euphemism for "does nothing well"? The concrete surfaces (office, storefront, scanner, terminal, assistant) are specific products built from composable blocks; "becomes anything" is the *delivery* property, not a refusal to be good at the specific thing. The wedge is deliberately narrow.

Q. What's actually shipped vs. a slide? See [08-status.md](08-status.md) — a single honest table. We mark CI-written-but-not- yet-confirmed (32-bit ARM) and frontier (autonomous author-step) explicitly rather than rounding up.