One starting point, infinite structures — the deployment shapes

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

shapes the *one* substrate already takes, and — load-bearing — that each shape is a

posture + profile + which action renders the floor, never engine code. Read

[VISION.md](VISION.md) and [SELF-DELIVERY.md](./SELF-DELIVERY.md) first. Status:

mixed and honest per shape below. The universal floor is built and verified this session;

the others are built mechanisms documented as deployment patterns.

The one idea

Define one starting point — the public floor everyone lands on (including you) — and

from it *step into deeper structures* without the substrate ever changing. The public launch,

your private app behind it, a sealed payment terminal, an offline appliance: not different

products, the same engine wearing a different face, decided by *who is asking* and *what

the device is for*. The arrangement is data; the floor is fixed.

Every shape below answers the same two questions with store content alone:

• Posture — who may reach which action (access / access_public / access_owner,

evaluated live and fail-closed: _core/_gate.action, kernel/access.cpp).

• Profile — what this device *is* (door + installed capabilities + intelligence route:

ARCHITECTURE, "Capability profile").

Shape 1 — Public floor for all, private app behind it (built + verified)

The floor is the launch version EVERYONE lands on at / — including you — no login. From

it you step into your private app (the full current experience): recognised people (you +

the shares you verify) walk straight in; a visitor meets the sign-in door. The public floor

and the private app are two faces of one node — you live on the floor and enter the app

deliberately; outsiders never reach the app.

Mechanism (store only):

• home/content.action — claimed node → _scene_default (the floor), for everyone.

• home/_scene_default.action — the floor: a chat-first starting screen (ChatGPT / Claude /

Gemini style) that surfaces the existing chat app — its composer POSTs q to /chat

(the carry chat already handles). Plus "📁 My things" (opens your current app — the

folder of everything you have) and, for a signed-out visitor, sign-in / invite.

• home/_drawer.action — the floor's OWN menu (Home · Chat · Reels · My things · sign in/out),

so the menu system itself changes between the two arrangements; the private app keeps the full

node menu, and an anonymous visitor gets no drawer (the floor stays clean).

• home/dash.action — the private app: the full dashboard (twin, things, store, node tools),

rendered through the one view pipeline with the full menu.

• home/defaults.data — access_public = index content (the floor is open to all). dash is

neither public nor owner-only, so it falls to the member tier: _recognized (owner +

verified shares) walk in, a visitor hits sign-in. access_owner = mind brain connect keeps

the deep owner actions gated; everything else stays member, fail-closed.

Verified on the live engine (embed-test, web door = anonymous; CLI = owner):

You live on the floor by default, so there is nothing extra to "preview" — to see the visitor

experience exactly, open / in a logged-out browser, another device, the web door, or via a

share link to someone you have not verified.

The split is the gate doing its job — no engine change. The security rule held: carve out,

never flip the base. Only / (the floor) and the already-public sign-in / invite / verify

flow (trust) are open; the private app and everything else stay member-gated, fail-closed.

Shape 2 — Verified vs. default (lenses)

One entry, different *depth* by identity. The floor is one shell; *which things

are visible or enterable* differs by who is looking. The owner enters their space; a

verified peer sees shared things; a stranger sees the welcome and a way in. This is the

lens model: a scoped projection of a thing, expressed as a thing, carrying access

posture and no data of its own — and it needs no engine primitive because grants are

read live per request and every read is gated fail-closed.

• Mechanism + proof: [lenses.md](./lenses.md) (kernel/access.cpp, kernel/resolve.cpp).

• Chrome already adapts: thing/_tabbar.action shows Home + Chat to everyone, the owner-only

tab only if _has_role owner.

• "Verification only ever unlocks talking to others" — on your own node you are always owner;

the verify graph gates cross-network calls only (trust/AUTH.md).

Status: the substrate is built and proven zero-change; the lens *convention* (a lens

base, a public "guest" support twin so the floor's Chat/I are live for anonymous visitors)

is the next authoring step, not engine work.

Shape 3 — Offline / sealed appliance (built mechanism)

Pack the store with the app and it needs to connect nowhere. The class library — all

behavior — is a plain filesystem tree, so it bakes into the shell and the engine boots with

no network. Ideal for fitted, untampered, locked-down settings.

• Baked store: mobile/android/seed.sh — *"bake the store into the APK so the engine

boots with NO network; on first launch the shell copies assets/store_seed/ into the

node's zero.9.stores."* iOS mirrors it: Resources/store_seed → ZeroApp.seedStore.

• Hydration is missing-only: functions/fs/hydrate.cpp — *"No-op when the dir already

exists or no remote is set."* A fully-present store never touches the network; unset the

remote base and it is offline by construction.

• Sealed = local door + profile. A kiosk/handheld uses a local (owner-trusted) door and

a capability profile that pins exactly what it is. Intelligence can pin local-only, no

egress (ARCHITECTURE, "Intelligence"), so a privacy/payment device never calls out.

Untampered — the honest requirement: "offline" is built; "untampered" additionally wants

integrity on the baked store (a signed/pinned seed so a swapped folder is detectable).

The trust/verification primitives exist (trust.verify, signed edges) and the versioned

runtime stamps lineage; wiring seed-integrity into provisioning is a deployment step, not an

engine change. Native capabilities remain shell-bound (Law 3) — a sealed device can do

anything expressible over the capabilities it was built and provisioned with.

Shape 4 — Single-purpose node (built mechanism)

A screen that only collects payments — no iroh, no model, no mesh. Because the engine is

the *only* floor and everything else is a capability, a node can install one store and

nothing else.

• Mesh/iroh is a capability, not the floor — omit it and the node simply never makes

cross-network calls; trust verification only gates *that*, so a non-networked node needs

no trust graph at all (trust/AUTH.md).

• Intelligence is a provider, not a dependency — oracle can be absent or delegated; an

incapable device installs none of it (VISION, "Intelligence is a provider").

• The profile is the whole difference — door, start, capabilities, native,

oracle.* (ARCHITECTURE, "Capability profile"). A flagship and a payment terminal run the

*same app*; the profile is the only difference.

Status: every ingredient (door model, capability profile, public posture, scene

rendering) is built; "payment terminal" is then a profile + a store + a public floor scene —

authoring, not engineering.

The common spine

Every shape above is the same three store-level dials, never engine code:

That is why the substrate is versatile "for any generation": a new deployment is a new

arrangement of dials over an unchanged floor.

Where to go next

• [SELF-DELIVERY.md](./SELF-DELIVERY.md) — why the substrate delivers all of this using

only itself.

• [lenses.md](./lenses.md) — scoped projections (Shape 2), with the zero-change proof.

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

• [VISION.md](VISION.md) — the three laws; the capability profile.

• home/content.action, home/_scene_default.action, home/_drawer.action,

home/dash.action, home/defaults.data — Shape 1, as shipped.