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. 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 asset-segregation 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 host shape

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

The unikernel target is the design goal. 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:

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