Totebox orchestration

Totebox Orchestration is the coordination layer that provisions, monitors, and manages multiple Totebox archive instances within a single PointSav deployment. When an operator maintains separate archives for contracts, financial records, and correspondence, the orchestration layer ensures each container keeps its own isolated ledger, runs its own integrity verification pass, and reports health status through a unified monitoring surface — without allowing any container to share mutable state with another. For a regulated operator, this means a compromise in one domain cannot propagate to records held in another.

Key Takeaways

• Each Totebox runs as an independent unit. No container shares a ledger directory with any other — a compromise in one container cannot propagate to siblings because there is no shared mutable state at the ledger layer.
• Integrity verification runs as scheduled checksum audits across all managed containers. Results land in a consolidated audit record; any mismatch surfaces at the orchestration level before reaching the operator.
• A new container is registered with the orchestration layer at creation, enabling lifecycle tracking across active, suspended, and archived states. The specific per-container directory layout is still being finalized.
• Totebox Orchestration makes it possible for a regulated operator to maintain separate, independently isolated archives for different record types — contracts, financial records, correspondence — managed through a single unified health surface.

Container isolation

Each Totebox runs as an independent unit. Today that independence is filesystem-level: no container shares a ledger directory with any other, so a compromise in one container's asset directory does not propagate to a sibling through shared mutable state. Hardware-enforced isolation — the intended end state, where each Totebox runs as its own seL4 protection domain — is a design goal, not the deployed model; the currently running os-totebox is a conventional Rust/tokio process with no seL4 dependency, as the os-totebox article describes in detail.

Integrity verification

The orchestration layer schedules periodic checksum audits across all managed containers. Results are written to a consolidated audit record. Any checksum mismatch raises a flag at the orchestration level before surfacing to the operator.

Provisioning and lifecycle

A new Totebox container is registered with the orchestration layer at creation time. The orchestration layer tracks container state across its operational lifecycle: active, suspended, or archived. app-console-input is a separate, standalone crate rather than a directory this provisioning step creates. The deployment patterns article describes how Totebox Orchestration appears in each canonical fleet configuration.

See also

• Sovereign vault and service host — the operating system running inside each managed Totebox
• Totebox archive — the fundamental unit of data storage being orchestrated
• os-infrastructure — PPN node operating system — the compute substrate hosting the Totebox instances
• os-console — the Command Ledger — the Command Ledger that operators use to interact with orchestrated archives
• Fleet aggregator — the fleet-level OS aggregator for multi-entity commercial deployments