03 — Self-Evolution

The property that makes Zero different in kind, not degree: the system can author, run, verify, and version its own behavior — and run any past version at will. This doc states it in the present tense (it exists and is evolving) and is precise about what is shipped vs. what is the frontier. Depth lives in [../roadmap/versioned-runtime.md](../roadmap/versioned-runtime.md).

The claim, stated plainly

Zero's behavior is data in a store, written in a small language, executed by a thin engine. Because behavior is data, a model can write it. Because there is a deterministic outcome check (verify), a change can be accepted or rejected without a human reading it. Because every write is content-addressed and saved, any version can be run again at any time, and the live system is never put at risk. Put together, the system improves its own execution platform under a guarantee that behavior is preserved.

That is the whole idea: *the language and the engine are allowed to drift toward whatever a model finds optimal — even past human legibility — because* verify*, not a human reviewer, guards the outcome.*

The loop

Files: thing/evolve.action + thing/_evolve_*.action (loop, prompt, clean, dispatch, record, write). The dispatch router runs a whitelist — anything off it returns an observation error, never a crash. (thing/_evolve_dispatch.action)

Two modes — how updates are supplied in the same form they are received

The model receives the system as store structure — folders of .action/.data — and when it evolves behavior it writes back into that same structure, through the same hydration mechanism that delivered it. Authoring has two modes (__ev_mode):

• write — direct authorship (e.g. zero zero.evolve "goal"). Writes to the

live store immediately.

• propose — autonomous heartbeat with a human approval gate. Changes are

staged (e.g. under ~/zero.9.data/<object>/activity/); nothing goes live until a human approves. (thing/_evolve_write.action)

So the authoring surface and the distribution surface are the *same* surface — a proposed change, an approved change, and a hydrated class all flow through one store-shaped path.

Verification — the load-bearing pillar

functions/verify <action> <expected> [args] runs an action and compares its return value to the expected output: "1" on match, "" on mismatch *or error* (a thrown action fails verification). (functions/core/verify.cpp) This is the one piece that earns the right to let the language go weird — it is not a nice-to-have bolted on at the end, it is the thing that makes autonomous authorship safe.

thing.selftest → verify-evolve.sh proves a saved version reproduces its own era's output, with the live version untouched.

Run any version, any time

Every action write is already content-addressed: an immutable .versions/<sha>.snap plus a per-path log and {reason, parent} metadata.

• thing.runversion?sha=<hash> executes that version by hash, crash-proof, without

disturbing "current."

• thing.versions?action=<name> renders the full lineage as a native scene —

newest first, each with its reason, what it changed *from*, and a "run this version" button.

So the system always knows how an action went "from this to that," and any version is runnable at will, with versions kept internal to the system. (../roadmap/consolidation.md, track D)

The loop has a face

thing.loop is the per-thing evolution-loop page on the same native chat fabric as /<thing>/chat: each autonomous cycle is a message card (the thing's journal), with controls to run self-evolution (evolve), run the autonomous loop (live), or open the version lineage of either. thing.match is demand↔supply matchmaking through conversation — a thing's demands paired with the best local supplier, a thread opened — and the pick is crash-proof (try_call oracle), degrading to "no match" without a provider. All native scenes, all store content, no engine change. (../roadmap/consolidation.md, track E)

Honest status — built vs frontier

Built + verified:

• The schema window + load-time gate (Phase 1). (kernel/interp.h, loadchain.cpp)

• functions/verify, the deterministic outcome check (Phase 2). (verify.cpp)

• Content-addressed versions, run-any-version-by-hash, scene-native lineage.

• The evolution-loop page + matchmaking on the chat fabric.

• The crash-proof oracle interface (try_call).

The frontier (planned, dependency now shipped):

• An oracle-driven author step wired to a live provider.

• A _evolve-style driver that loops until verify accepts, unattended.

• Real migrations (vN→vN+1 transforms; the registry is a designed no-op today).

• Engine-version-per-schema selection, and data versioning (apply the same

version pattern to .data).

The substrate the loop runs on is built; the remaining work is store/DSL orchestration over existing primitives plus a wired provider — by design, no engine change. This is deliberate: the engine stays thin (code reduction is the north-star), and the intelligence lives in the store where it can change as fast as a model can verify it.

Why this is the moat

A competitor can copy a feature. To copy *this* they need the whole stack to line up at once: behavior-as-data, a tiny verifiable execution contract, content-addressed versioning, provider-abstracted intelligence, and a store that distributes all of it without releases. Each piece is simple; the leverage is their composition, and the discipline (push everything into the store, keep the floor shrinking) is the hard part to imitate.