Fleet aggregator
os-orchestration exists today as a registered, empty scaffold crate — its entire source is a placeholder status function, with no aggregation logic behind it. Everything this article describes is the intended design, not a shipped feature.
os-orchestration is planned as the commercial-tier operating system intended to let a single operator see, query, and command many Totebox archives at once. Where os-console connects to one os-totebox, os-orchestration is intended as the hub between an operator's Console and a fleet of Toteboxes — what an executive would view to see the position of every property in a portfolio, every entity in a holding company, or every project in a development pipeline, in a single unified answer to "what is the state of the entire estate, right now?" This article covers the intended design: what os-orchestration is planned to do, what it is designed to deliberately not do, how aggregation is intended to work, the commercial features planned for it, and when it would be deployed. None of this is built yet — see the correction above.
What it is designed not to do
os-orchestration is designed not to store raw records — to be stateless. The intent is that it would pull metadata from Toteboxes, synthesise a unified view, and present it through os-console, with raw data never leaving its Totebox. Under this design the aggregator would see only what the Totebox is permitted to expose.
This boundary is intended to be structurally important: even if os-orchestration were compromised, the underlying Toteboxes would remain sealed, since the aggregator is not meant to hold keys to the archives.
Where it is planned to sit in the product line
| Component | Role | Licence model (planned) |
|---|---|---|
os-console |
Operator-facing terminal | AGPL-3.0-or-later source; free BETA today |
os-totebox |
Data archive per entity | FSL-1.1-ALv2 source-available now; converts to Apache-2.0 after 2 years; free BETA today |
os-orchestration |
Fleet aggregator (planned) | Proprietary per the monorepo LICENSE file's own directory table — though the crate's own Cargo.toml SPDX header currently states FSL-1.1-ALv2, an unresolved mismatch between the two declarations |
The commercial line is intended to be drawn at the aggregator. The Console and the Totebox are intended to be free and freely transferable. The Orchestration aggregator is planned as the paid product — an individual operator managing one entity would never need it.
How aggregation is intended to work
The design intent is for os-orchestration to connect to Toteboxes through a capability-based protocol tunnelled through standard TLS at the edge — no specific protocol name is committed to code today. Inside the tunnel, the intended flow is:
- The aggregator would send a signed capability object granting permission to read a specific row of a specific Totebox for a fixed time window.
- The Totebox would verify the capability, run the query internally, and emit only the result — never the raw record.
- The aggregator would combine results from many Toteboxes into a single unified view.
If built as designed, promise pipelining and zero-copy memory mapping are intended to make the experience feel local even when Toteboxes are distributed across multiple regions.
The commercial features (planned)
Three capabilities are planned to be reserved exclusively to os-orchestration:
| Feature | What it is intended to enable |
|---|---|
| Aggregation | Reading metadata from multiple Toteboxes simultaneously |
| Multi-tenancy | Serving multiple operators against the same underlying fleet |
| Complex viewports | Cross-archive dashboards — portfolio rollups, cross-entity reconciliation, executive summaries |
These features are intended to be intentionally absent from the open os-console codebase — planned to live in the os-orchestration codebase and nowhere else, once built.
The Diode discipline (planned)
The design calls for os-orchestration to be able to issue commands downstream to the Toteboxes it manages, with Toteboxes unable to issue commands back up. The aggregator is intended to itself be a Diode subject: receiving commands only from os-console, never from a Totebox. This is designed to make lateral movement structurally impossible — a compromised Totebox would not be able to use the aggregator as a bridge to the operator's Console. The Totebox Orchestration article covers the coordination layer's provisioning and lifecycle management.
When it would be deployed
os-orchestration is planned as a commercial product for multi-entity operators. Single-entity operators managing one Totebox would not need it. Multi-entity operators — real-estate portfolios, public companies with subsidiaries, family offices with multiple holdings — would be the intended customer once the cognitive load of running separate Consoles against individual Toteboxes justifies the aggregator.
See also
- console-os — the Direct vs. Aggregate mode distinction; os-console pairs with os-orchestration in Aggregate mode
- Sovereign vault and service host — the archives being aggregated
- Diode standard — the unidirectional command discipline that governs the aggregator
- Machine-based authorization — how pairings secure aggregator-to-Totebox connections
- Deployment patterns — how os-orchestration appears in commercial deployment configurations
- OS family — eight operating systems, one substrate — the eight-OS family and how os-orchestration fits