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 provisioned with a three-directory skeleton (
app-console-input/,assets/,ledger/) and registered with the orchestration layer at creation, enabling lifecycle tracking across active, suspended, and archived states. - 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
Correction (2026-08-02): os-totebox's real Cargo.toml has zero dependencies — no seL4, nothing — and os-totebox/src/lib.rs is NetBSD 10.1 guest-image-builder metadata for a VM running OLMo 7B inference, unrelated to microkernel isolation. This matches this repo's own earlier-confirmed finding (cleanup-log.md, 2026-07-18) that os-totebox and os-console are plain Rust/tokio with no seL4 dependency. Separately, the "three-directory skeleton (app-console-input/, assets/, ledger/)" claim below doesn't match real provisioning either — app-console-input is an independent standalone crate, not a per-archive subdirectory template, and no provisioning script creates this exact skeleton. Flagged, not resolved — needs re-hedging to planned/intended language.
Each Totebox runs as an independent unit backed by the seL4 microkernel's hardware isolation guarantees. No container shares a ledger directory with any other container. A compromise in one container's asset directory does not propagate to sibling containers, because there is no shared mutable state at the ledger layer.
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 provisioned with a three-directory skeleton — app-console-input/, assets/, and ledger/ — and registered with the orchestration layer at creation time. The orchestration layer tracks container state across its operational lifecycle: active, suspended, or archived. 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
- console-os — the Command Ledger that operators use to interact with orchestrated archives
- Fleet aggregator — the fleet-level OS aggregator for multi-entity commercial deployments