Diff: systems/os-family-overview.es
From 7c9194a to 7c9194a
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "The OS family — eight operating systems, one substrate" | title: "The OS family — eight operating systems, one substrate" |
| slug: os-family-overview | slug: os-family-overview |
| category: systems | category: systems |
| type: concept | type: concept |
| quality: complete | quality: complete |
| status: active | status: active |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| language_protocol: PROSE-TOPIC | language_protocol: PROSE-TOPIC |
| last_edited: 2026-05-15 | last_edited: 2026-05-15 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: os-family-overview.es.md | paired_with: os-family-overview.es.md |
| short_description: "PointSav builds eight purpose-built operating systems that share a common seL4 + Rust substrate. Each does one job, contains no features it does not need, and communicates through a common Diode-based protocol discipline." | short_description: "PointSav builds eight purpose-built operating systems that share a common seL4 + Rust substrate. Each does one job, contains no features it does not need, and communicates through a common Diode-based protocol discipline." |
| cites: [] | cites: [] |
| --- | --- |
| PointSav builds eight purpose-built operating systems that share a common [[sel4-microkernel-substrate|seL4 microkernel]] substrate, a common Rust language discipline, and a common [[diode-standard|Diode]]-based communication protocol. Each OS does one job and contains no feature it does not need. The family ranges from a human-facing terminal to a sovereign cloud appliance, yet every member compiles from the same kernel and speaks the same protocol. This article covers the eight members of the OS family, the substrate they share, how they compose into [[deployment-patterns|deployments]], and the Diode discipline that governs command flow across all of them. | PointSav builds eight purpose-built operating systems that share a common [[sel4-microkernel-substrate|seL4 microkernel]] substrate, a common Rust language discipline, and a common [[diode-standard|Diode]]-based communication protocol. Each OS does one job and contains no feature it does not need. The family ranges from a human-facing terminal to a sovereign cloud appliance, yet every member compiles from the same kernel and speaks the same protocol. This article covers the eight members of the OS family, the substrate they share, how they compose into [[deployment-patterns|deployments]], and the Diode discipline that governs command flow across all of them. |
| ## The eight operating systems | ## The eight operating systems |
| | OS | Role | Operated by | | | OS | Role | Operated by | |
| |---|---|---| | |---|---|---| |
| | [[console-os\|`os-console`]] | Universal human terminal — the Command Ledger | The operator at the keyboard | | | [[console-os\|`os-console`]] | Universal human terminal — the Command Ledger | The operator at the keyboard | |
| | [[totebox-os\|`os-totebox`]] | Sovereign vault and service host — the data archive | An entity (person, corporation, property) | | | [[totebox-os\|`os-totebox`]] | Sovereign vault and service host — the data archive | An entity (person, corporation, property) | |
| | [[os-orchestration\|`os-orchestration`]] | Fleet aggregator — multi-archive view for commercial operators | Enterprise administrator | | | [[os-orchestration\|`os-orchestration`]] | Fleet aggregator — multi-archive view for commercial operators | Enterprise administrator | |
| | [[infrastructure-os\|`os-infrastructure`]] | Compute substrate that hosts the others | Fleet administrator | | | [[infrastructure-os\|`os-infrastructure`]] | Compute substrate that hosts the others | Fleet administrator | |
| | [[os-network-admin\|`os-network-admin`]] | Network control plane — routing, pairing registry, mesh policy | Network architect | | | [[os-network-admin\|`os-network-admin`]] | Network control plane — routing, pairing registry, mesh policy | Network architect | |
| | [[mediakit-os\|`os-mediakit`]] | Public web appliance — marketing, wiki, compliance newsroom | Reporting Issuer or SMB | | | [[mediakit-os\|`os-mediakit`]] | Public web appliance — marketing, wiki, compliance newsroom | Reporting Issuer or SMB | |
| | [[os-privategit\|`os-privategit`]] | Sovereign source and design hosting | PointSav internal and customer | | | [[os-privategit\|`os-privategit`]] | Sovereign source and design hosting | PointSav internal and customer | |
| | [[os-workplace\|`os-workplace`]] | Sovereign desktop with native Rust apps | Community and SMB customer | | | [[os-workplace\|`os-workplace`]] | Sovereign desktop with native Rust apps | Community and SMB customer | |
| ## Why eight, not one | ## Why eight, not one |
| Conventional operating systems try to be everything: accounting, email, secure browsing, video editing. The result is a large attack surface and constant feature drift. PointSav inverts the model: every OS is small, single-purpose, and replaceable. If a deployment does not need a fleet aggregator, it does not include `os-orchestration`. If it has no public website, it does not include `os-mediakit`. Each OS is a piece of precision plumbing, not a platform. | Conventional operating systems try to be everything: accounting, email, secure browsing, video editing. The result is a large attack surface and constant feature drift. PointSav inverts the model: every OS is small, single-purpose, and replaceable. If a deployment does not need a fleet aggregator, it does not include `os-orchestration`. If it has no public website, it does not include `os-mediakit`. Each OS is a piece of precision plumbing, not a platform. |
| ## The shared substrate | ## The shared substrate |
| All eight operating systems share the same foundational layer: | All eight operating systems share the same foundational layer: |
| | Layer | Component | Purpose | | | Layer | Component | Purpose | |
| |---|---|---| | |---|---|---| |
| | Kernel | [[sel4-microkernel-substrate|seL4 microkernel]] | Mathematically verified hardware isolation | | | Kernel | [[sel4-microkernel-substrate|seL4 microkernel]] | Mathematically verified hardware isolation | |
| | Language | Rust (memory-safe; no garbage collector) | All `system-*`, `service-*`, and `os-*` code; C/C++ banned at L3 and above | | | Language | Rust (memory-safe; no garbage collector) | All `system-*`, `service-*`, and `os-*` code; C/C++ banned at L3 and above | |
| | Drivers | sDDF (seL4 Device Driver Framework) | Direct hardware access without runtime bloat | | | Drivers | sDDF (seL4 Device Driver Framework) | Direct hardware access without runtime bloat | |
| | Protocol | PointSav Protocol (PSP) | Capability-based binary protocol; tunnels through TLS and VirtIO at the edge | | | Protocol | PointSav Protocol (PSP) | Capability-based binary protocol; tunnels through TLS and VirtIO at the edge | |
| | Trust | `service-pairing` | Hardware-bound cryptographic pairings; no usernames, no passwords | | | Trust | `service-pairing` | Hardware-bound cryptographic pairings; no usernames, no passwords | |
| | Audit | Append-only ledger (planned) | Tamper-resistant event record that cannot be disabled by an administrator | | | Audit | Append-only ledger (planned) | Tamper-resistant event record that cannot be disabled by an administrator | |
| | Transferability | Sovereign Addendum (planned) | The running instance remains the operator's property in any cloud provider | | | Transferability | Sovereign Addendum (planned) | The running instance remains the operator's property in any cloud provider | |
| ## How they compose into deployments | ## How they compose into deployments |
| The minimum viable deployment is one operator running `os-console`, connected to one `os-totebox` hosted in the cloud. The Console is the keyboard and screen; the Totebox is the vault and the worker. | The minimum viable deployment is one operator running `os-console`, connected to one `os-totebox` hosted in the cloud. The Console is the keyboard and screen; the Totebox is the vault and the worker. |
| The largest deployment is hundreds of `os-totebox` instances spread across on-premises, leased, and cloud `os-infrastructure` nodes, governed by one `os-network-admin`, and aggregated through `os-orchestration` for executive review. Both extremes use the same binaries. Scale is a configuration matter, not a code fork. | The largest deployment is hundreds of `os-totebox` instances spread across on-premises, leased, and cloud `os-infrastructure` nodes, governed by one `os-network-admin`, and aggregated through `os-orchestration` for executive review. Both extremes use the same binaries. Scale is a configuration matter, not a code fork. |
| The six canonical compositions are covered in detail in [[deployment-patterns]]. | The six canonical compositions are covered in detail in [[deployment-patterns]]. |
| ## The Diode discipline | ## The Diode discipline |
| Across all eight, command flow is unidirectional. `os-console` and `os-orchestration` can issue commands to the others. The others emit [[sovereign-telemetry|telemetry]] upward — never commands in the reverse direction. This constraint is enforced at the [[diode-standard|Diode]] protocol level, not by policy. A compromised public-facing `os-mediakit` instance cannot reach back into a corporate `os-totebox` because the code to do so is absent from the binary. The [[sovereign-airlock-doctrine|sovereign airlock]] principle describes why absent code is the only reliable enforcement mechanism. | Across all eight, command flow is unidirectional. `os-console` and `os-orchestration` can issue commands to the others. The others emit [[sovereign-telemetry|telemetry]] upward — never commands in the reverse direction. This constraint is enforced at the [[diode-standard|Diode]] protocol level, not by policy. A compromised public-facing `os-mediakit` instance cannot reach back into a corporate `os-totebox` because the code to do so is absent from the binary. The [[sovereign-airlock-doctrine|sovereign airlock]] principle describes why absent code is the only reliable enforcement mechanism. |
| ## See also | ## See also |
| - [[console-os]] — the Command Ledger terminal; human-facing surface | - [[console-os]] — the Command Ledger terminal; human-facing surface |
| - [[totebox-os]] — the sovereign vault and service host | - [[totebox-os]] — the sovereign vault and service host |
| - [[os-orchestration]] — the fleet aggregator for commercial deployments | - [[os-orchestration]] — the fleet aggregator for commercial deployments |
| - [[sel4-microkernel-substrate]] — the shared seL4 kernel and why PointSav adopted it | - [[sel4-microkernel-substrate]] — the shared seL4 kernel and why PointSav adopted it |
| - [[diode-standard]] — the Diode protocol that governs unidirectional command flow | - [[diode-standard]] — the Diode protocol that governs unidirectional command flow |
| - [[deployment-patterns]] — the six canonical deployment configurations | - [[deployment-patterns]] — the six canonical deployment configurations |
| - [[six-tier-sovereignty-matrix]] — how the `os-*` family fits the broader six-tier model | - [[six-tier-sovereignty-matrix]] — how the `os-*` family fits the broader six-tier model |
| - [[machine-based-auth]] — hardware-bound pairing across all OS members | - [[machine-based-auth]] — hardware-bound pairing across all OS members |