os-totebox is the archive layer of the PointSav family: one isolated, kernel-level vault per entity. It stores the records, runs the services that process them, and exposes nothing else. An entity is whatever needs a separate set of books — a person, a corporation, a real property, a project, a household. Each entity has its own os-totebox. Toteboxes do not share files, do not share users, and cannot see each other. They communicate only through the Diode, and only on command from os-console or os-orchestration. This article covers the services inside, the WORM discipline, the host shape evolution, the compute tiers, and the freely transferable design.

What lives inside

Each os-totebox hosts a fixed set of services:

The WORM discipline

os-totebox writes raw payloads directly to append-only block storage. There is no delete operation in the code path. [^1] A compromised service cannot overwrite history because the verb does not exist at the storage interface. This is the architectural enforcement layer for processing integrity and the WORM ledger discipline.

Every institutional record lives as an inert flat file — Markdown, YAML, or CSV — that requires no proprietary runtime to read decades later. A .yaml ledger or .csv register is universally readable by any text editor, on any hardware, in any decade. Data migration cost falls toward zero: the operator always holds the source in a form no proprietary software can lock. The WORM storage architecture and ledger architecture articles describe the technical implementation.

The host shape

os-totebox is designed to evolve across four phases as the seL4 substrate matures:

The unikernel target is the design goal. [^2] The end-state has no SSH, no shell, no Bash, no Python interpreter — only one compiled binary fused to hardware drivers. An operator recompiles the vendor source in the monorepo and reboots the cloud node with the new image; there is no shell to log into.

Compute tiers

os-totebox adjusts its behaviour to available hardware, following the model-tier discipline that governs SLM usage:

Freely transferable

Every os-totebox instance is intended to ship as a single disk image (.img or .vmdk). The operator picks it up and moves it between cloud providers, a private server, or bare-metal at their own facility. There is no host operating system underneath that holds the keys. This is the Sovereign Addendum's intended commitment in physical form: the running instance remains the operator's property in any environment.

See also

• os-family-overview — where os-totebox fits in the eight-OS family
• console-os — the Command Ledger that connects to os-totebox and presents its state
• os-orchestration — the fleet aggregator that queries many Toteboxes at once
• diode-standard — the unidirectional protocol through which the Totebox communicates
• sel4-microkernel-substrate — the kernel underpinning os-totebox's isolation guarantees
• machine-based-auth — how pairing governs access to a Totebox
• worm-ledger-design — the append-only storage discipline enforced by os-totebox