Skip to content

systems/console-os

Topic

From the PointSav Documentation

os-console is the human-facing surface of the PointSav platform — a Command Ledger that connects to one Totebox and renders its state to the operator. It does not store data and does not run services; it is a high-fidelity terminal purpose-built around keyboard-driven operator flow. The reference point is the Bloomberg Terminal: a single keyboard, a small set of function keys, and a relentless focus on the operator's context. The binary is written from scratch in Rust for sub-50-millisecond cold start and a 15-megabyte footprint. This article covers how os-console runs, the F-key surface, the rendering stack, and the two operating modes.

[edit]How it runs

os-console ships as a single executable. On the host operating system — Windows, macOS, or Linux — it acts as a Virtual Machine Monitor: it uses the host's native virtualisation API to create a small, isolated VM in RAM and boots an seL4 environment inside it.

Host Native VMM API
Windows Windows Hypervisor Platform (WHPX)
macOS Hypervisor.framework
Linux KVM

The operator thinks they opened an application. What they have done is spun up a hardware-isolated secure environment in roughly 50 milliseconds. When the application closes, the secure memory is wiped. Nothing touches the host hard drive. The security model relies on hardware-bound pairings rather than usernames or passwords.

[edit]The F-key surface

The interface organises every entity's reality into a fixed set of pillars. Each pillar is a function key:

Key Pillar Service
F1 HELP [[app-console-input
F2 PEOPLE [[service-people
F3 EMAIL [[service-email
F4 CONTENT [[service-content
F5 MINUTEBOOK service-minutebook — deep records
F6 BOOKKEEPER service-bookkeeper — the financial ledger
F12 INPUT MACHINE app-console-input — the human-in-the-loop ingestion gateway

F12 is mandatory per SYS-ADR-10. The Input Machine is the only surface through which raw external files can enter a Totebox. Files dropped into F12 have execution permissions stripped, are tagged against the operator's Chart of Accounts, and are routed to F5 or F6.

[edit]The rendering stack

os-console is not a TUI inside a host terminal. It is a standalone graphics application that happens to display text. The stack is owned end-to-end and shares its design philosophy with the broader PointSav design system:

Layer Component Notes
Window pointsav-window Custom Win32 / Cocoa / X11/Wayland wrapper
GPU pointsav-gpu WGPU (Vulkan / Metal / DX12 abstraction); licence embedded in binary
Text pointsav-text Signed Distance Field (SDF) glyph renderer [^1]; infinite-zoom fidelity
Layout pointsav-layout Recursive row/column grid in roughly 500 lines of Rust
Widget logic Forked from ratatui core Logic only; ratatui's renderer replaced by the WGPU pipeline

The result is a terminal interface with variable-weight headers, bloom effects, and smooth scrolling — while remaining purely keyboard-driven and rendering at the fidelity required by ISO 19650 [^2] document-state suffixes.

[edit]Direct mode and aggregate mode

os-console operates in two modes determined by what it pairs with:

Mode Pair Use case
Direct One [[totebox-os Totebox]]
Aggregate One [[os-orchestration os-orchestration]] (which aggregates many Toteboxes)

Both modes use the same os-console binary. The aggregator does not require a different Console. The complexity lives in os-orchestration.

[edit]Single, unified, universal

os-console is one product. There is no "Home" edition and no "Pro" edition. An individual hosting one Totebox uses the same Command Ledger as the administrator of a Reporting Issuer aggregating hundreds. Commercial differentiation is determined by the presence or absence of os-orchestration, never by a tiered Console. The six-tier sovereignty model governs how commercial tiers are structured across the platform.

[edit]See also

  • totebox-os — the Totebox archive that os-console connects to and renders
  • app-console-input — the F12 Input Machine; deep coverage of the mandatory ingestion gateway
  • diode-standard — why commands flow in one direction through the established pair
  • os-family-overview — the five OS surfaces and how os-console fits among them
  • deployment-patterns — how os-console appears in each of the six canonical deployment configurations
Edit this page · View source