05 — Investor Pitch

The narrative, at two altitudes: a north-star with an "all of software" ceiling, and a beachhead with a nameable first buyer and a demo you can run today. Funders back the wedge and price the vision; we carry both, and we are honest about the seam. Numbers in [brackets] are placeholders for you to fill — they are the only things in this doc not grounded in the code.

The one-liner

Zero is the OS for the AI age — a tiny shapeless substrate that becomes any software, on any device, with behavior shipped as capabilities instead of releases, authored and evolved by models under deterministic verification.

The problem

Software today is built the way it was built before AI: by hand, frozen at ship time, and siloed per device.

• Hand-built and slow to change. Every new behavior is a code change and a

release. Every new device is a port.

• Frozen. The moment software ships, it stops adapting; it can't reshape itself

to who's using it or what they need right now.

• Siloed. A warehouse runs one stack on its handhelds, another on its counters,

another in the back office, another for customers — N apps, N teams, N release trains, none of them aware of each other.

AI can now *write* and *adapt* software faster than humans can ship it. But it's being bolted onto the old shape — a chatbot stapled to a frozen app. The bottleneck isn't the model anymore. It's that software still has a fixed shape.

The insight

If you make software shapeless — a tiny engine plus behavior held as *data* in a store — three things collapse into one:

1. Changing behavior stops being a release. It's a store update; a reload is the

latest.

2. Adapting to context stops being a feature. The same install *becomes* what the

moment demands — office, storefront, scanner, terminal, assistant — decided at runtime by who's asking, where, and why.

3. An AI can own the software lifecycle. Because behavior is data with a

deterministic outcome check, a model can author, version, run, and verify it — keeping a change only when it provably preserves behavior.

Do that on one universal floor that runs from edge devices to servers, and "new apps" become "new classes," not new downloads. That is the leverage.

What we built

A working substrate, not a deck. The honest split is in [08-status.md](08-status.md); the headline:

• A ~2,400-line engine whose only innate job is to execute versioned action-files.

Everything else — UI, routing, features — is data in a store. (Verified: the same binary becomes a different engine when pointed at a different core.)

• One install, many devices. Shipping on macOS; built on Linux, Windows, Android,

iOS; on Raspberry Pi / ARM and in Docker. Same engine, thin native shells, a *capability profile* that decides what each device is.

• Behavior ships from a store, hydrated on demand, cached locally, never a release.

Even *speed* (compiled native views) ships this way, per-class, per-platform.

• Intelligence is a routed provider — on-device model, your own API key, or a peer

node over an encrypted mesh — never one hardcoded brain, always able to fall back to fully local.

• The system evolves itself, under a deterministic verification gate, with every

version content-addressed and re-runnable. *It exists, and it is evolving itself.*

Why now

• Models crossed the threshold where they can author and adapt software reliably —

but only if the software has a shape they can safely write. Zero is that shape.

• The floor got cheap. A dependency-light engine now links into a sandboxed mobile

app, a Pi, a server, and a desktop from one codebase. Five years ago this was a research project; now it's an engineering one.

• The old model is visibly straining. Per-device app sprawl, release friction, and

"AI features" bolted onto frozen apps are everyone's pain. The market is primed for a substrate that makes them go away.

The wedge — edge & device fleets

This is where we land the first checks, because it's where the most is built and the buyer is nameable.

• Who: organizations running fleets of devices that each need to be a different

thing — retail, logistics, warehouses, field ops, hospitality. Handhelds, counters, kiosks, back-office desktops, TVs.

• The pain we kill: today they run a different app stack per device class, each with

its own release train. We give them one install that becomes a scanner, an order desk, a payment terminal, or an assistant — re-provisioned by changing a *capability profile*, with behavior pushed from a store. No app release to change what a device does.

• The demo: one binary, three profiles, three completely different devices, live —

then change a behavior in the store and watch it appear without a redeploy.

• Why it survives diligence: the multi-platform shells, the capability-profile model,

the store hydration, the three-gate permissioning, and the device-control-as-actions are real today (see [02-architecture.md](02-architecture.md), [04-deployment-targets.md](04-deployment-targets.md)).

The other markets are the same engine, later — they are expansion vectors, not a re-platform:

• Self-evolving software platform — sell the loop itself to AI-forward orgs and dev

platforms (highest ceiling; the autonomous-author step is the frontier).

• Personal sovereign AI — a recoverable identity, your data in your own home,

intelligence local or BYO, over an encrypted mesh (bottom-up adoption).

• Horizontal licensing — companies run their own private mesh + capability stores

(biggest TAM, longest cycle; this is the north-star's commercial form).

Business model — buy-then-build

Our own thesis, applied to ourselves:

• The engine is the razor. Tiny, cheap or open — it *wants* to be on every device.

Distribution, not price, is the goal here.

• The blades are the stores and the nodes.

• Capability stores — buy a curated base (a vertical: warehouse, payments,

storefront) and build your business cases on top of it. We sell/curate the base and take a cut of the marketplace.

• Per-node presence — every device that becomes a node in the mesh is a billable

unit. Fleets scale the account naturally.

• Managed mesh / support — private relays, fleet provisioning, SLAs for orgs that

don't want to run their own.

Buy-then-build is the core power: a customer acquires the substrate + a base capability set, then builds — or lets the system evolve — the rest, instead of commissioning bespoke software per device.

The moat

• Composition, not a feature. Behavior-as-data + a verifiable execution contract +

content-addressed versioning + provider-abstracted intelligence + release-free store distribution. Each piece is simple; making them line up at once is the hard part.

• The discipline. "The engine is the only universal floor; everything else is a thing

in the store." A competitor who can't hold that line ships a fat engine and loses the leverage. We enforce it as a design law. (../VISION.md)

• The self-evolution flywheel. The more the store grows and the more the system

verifies and improves its own classes, the wider the gap — and it's all distributed without releases.

• Identity + mesh. A recoverable Zero-ID that is the same everywhere, with an

blind-relay mesh encrypted endpoint-to-endpoint, is a defensible network primitive most app-layer

competitors don't have. (Stated as it is: key discovery is directory-pinned, not

authenticated, so the property today is confidentiality against the relay — ../remote-access.md

§5. The attestation that would close it is specified and unbuilt.)

Status & traction

• Engineering: substrate working and verified across the tracks in

[08-status.md](08-status.md); macOS shipping, multi-platform built, versioned runtime Phases 1–2 done, self-evolution loop live with the author-step as the frontier.

• Stage: in testing, preparing for launch. [fill: pilots / design partners / LOIs]

• Team: [fill: founders, prior work, why you]

• Raise: [fill: amount, use of funds — most of it should buy the wedge: 1–2

lighthouse fleet deployments + the capability stores that prove buy-then-build]

Risks & how we hold them

• "It's an agent framework." No — agents run *on* substrates; we are the substrate

they run on, and it predates the LLM (the LLM is a routed provider, not the engine).

• Horizontal = no buyer. Mitigated by leading with one concrete wedge and one

lighthouse deployment, not the abstract vision.

• Self-evolution maturity. We present it honestly staged: the verification pillar and

versioning are shipped; the unattended author loop is the frontier. We don't overclaim.

• Microcontroller / boot-OS reach. Framed as a credible destination (tiny,

dependency-light, statically linkable), not a current capability.

• Model dependence. Defused by design: provider-abstracted, always able to fall back

fully local — we own the routing, rent the model.

The ask

[fill: $X to reach Y] — concretely: [N] lighthouse fleet deployments, the first curated capability stores, and the wired autonomous-author step, on a [Z]-month runway to [milestone].

One line to leave them with: *Every other company is making the model smarter. We're making software shapeless — so the smarter model has something it can actually reshape.*