GXST OS

The dominant consumer operating systems are converging on an architecture that is incompatible with operator sovereignty: behavioral data is collected by default, surfaced to remote services, and used to personalize an experience whose configuration the operator does not own. The sovereignty-preserving alternatives — Qubes OS, GrapheneOS, NixOS, Arch, the BSDs — preserve the user's right to inspect and modify the system, but ask the user to be the integrator. The result is a forced choice between convenient personalization without sovereignty and sovereignty without personalization. Neither option serves the operator who wants both — a system that adapts to who they are without surrendering custody of the data that adapts it.

A second class of unmet need is multi-device coherence. An operator with a desktop, a laptop, a phone, and an embedded device under their authority currently lives in four distinct identity surfaces. State, preferences, files, and notifications are bridged by cloud services whose business model presumes egress. Sovereign alternatives to those bridges exist (Syncthing, Nextcloud, self-hosted matrix, WireGuard meshes), but they are built on top of distinct base operating systems whose configurations diverge over time. There is no sovereign substrate that treats device fleet membership as a first-class architectural property.

A third class of need is fleet deployment by non-technical operators. A parent who wishes to provide a sovereign computing environment for their child, or a caregiver who wishes to do the same for an elderly parent, currently has no path that does not require either becoming a system administrator or accepting the loss of sovereignty implicit in dominant consumer platforms. The space between "I will install Qubes for my mother" and "I will give my mother an iPad" is empty.

Stated as a single design problem: specify a sovereign operating system whose configuration is derived from the user's observed behavior, whose installation propagates coherently to every device that user owns, and whose deployment can be performed by a non-technical administrator on behalf of others without loss of personalization or privacy. GXST OS is the design we propose for that problem.

Boundary conditions (non-negotiable)

The following constraints govern every architectural decision below:

• Local by default. All behavioral data, all profile derivation, all configuration generation, all rendering — local to the operator's hardware. Cloud is an opt-in compatibility shim, never a runtime dependency.
• The operator owns the configuration. The compiled OS configuration is a readable artifact the operator can inspect, version, share, fork, or discard. Personalization is not a black box.
• Multi-device is foundational, not bolted-on. A single-device deployment is a special case of a fleet of size one — not a separate deliverable.
• Hardware honesty. Where bootloader locks or proprietary firmware prevent OS replacement, GXST OS provides a companion application surface rather than pretending to install where it cannot.
• Constitutional carve-outs. Security defaults, update policies, cryptographic primitives, and other safety-critical parameters are explicitly excluded from personalization. Personalization operates above the trust boundary, never beneath it.

GXST OS is layered into thirteen components. The lower five layers reuse infrastructure already produced by OVRIN Labs for the sovereign-runtime stack; the upper eight are new construction whose specification is the substantive content of this document.

Layer 12: Fleet Manager                     [new]
Layer 11: Sync Fabric                       [new]
Layer 10: Propagation Engine                [new]
Layer  9: Functional Mapping                [new]
Layer  8: World Generator                   [new + SIGIL geometry library]
Layer  7: Profile Engine                    [new]
Layer  6: Intake Engine                     [new]
Layer  5: Knowledge Surface                 [adapted: Oteka]
Layer  4: Semantic Intelligence             [existing: Lorengine]
Layer  3: Agent Orchestration               [adapted: Zeno]
Layer  2: Display / Compositor              [existing: Phalanx]
Layer  1: System Foundation                 [existing: Pneuvade + ovr-* daemons]
Layer  0: Hardware Abstraction              [Linux LTS kernel, unmodified]

2.1 Foundation reuse (Layers 0–5)

The architecture deliberately accepts the mainline Linux long-term-support kernel without modification. The objective is sovereignty over the operator's experience, not sovereignty over driver code; inheriting the kernel's hardware-abstraction surface is the rational economy.

Above the kernel, the existing OVRIN runtime substrate — Pneuvade as PID 1, the ovr-* family of system daemons, the Phalanx Wayland compositor, the Zeno agent host, Lorengine as the in-process semantic engine, Oteka as the knowledge-navigation surface — is reused with adaptations. The reuse is substantive: roughly 154,000 lines of audited Zig and Rust already exist as the foundation for these layers, much of which is independently shippable as standalone tools and serves GXST OS as a side effect of its primary use.

2.2 The intake-to-derivation pipeline (Layers 6–7)

The differentiating mechanism of GXST OS is the Intake Engine, which observes the operator's behavior on their existing system for a bounded period — a working hypothesis is one to four weeks — and produces a structured profile that drives the rest of the system's configuration.

Intake operates in two layers. The system-telemetry layer uses kernel-level eBPF probes to observe I/O patterns, memory pressure, scheduling preferences, network heuristics, and power-state behavior. These signals drive low-level system tuning whose correct values for an operator's actual workload differ measurably from distribution defaults. The identity-inference layer observes higher-order signals: content consumption patterns, creative-output topology, communication structure, workflow sequencing, temporal rhythm, aesthetic preferences, and the distance between who the operator is and who they wish to become. This second layer is the harder problem and the more consequential one.

All intake data is local. All distillation is local. Raw signals are progressively reduced through short-term, long-term, and profile-level representations, and the lower-level data is cryptographically destroyed once the higher-level profile is stable. There is no telemetry channel out of the operator's hardware, ever.

The Profile Engine consumes the distilled PersonProfile and emits the configuration manifests for every layer above and below it: a Pneuvade service graph, an ovr-pkg package manifest, a Phalanx brand-token set, a Zeno agent personality and tool inventory, a Lorengine corpus policy, and a seed for the World Generator. The output is a declarative artifact — readable, diffable, version-controllable. The operator can inspect the compiled configuration, edit it, regenerate it, or roll back to a previous version in the same way a NixOS user manages configuration.nix.

2.3 The world layer (Layers 8–9)

The most ambitious architectural commitment of GXST OS is that the user-facing surface of the operating system is itself generated from the profile. The World Generator is a five-stage pipeline: world concept (a structured-output prompt to a local language model produces a coherent metaphor — spatial paradigm, mood register, material language); world grammar (proportional rules derived from the SIGIL Engine's brand-construction library, which transfers from logo geometry to environmental geometry); asset generation (procedural geometry — wave-function-collapse for layout, L-systems for organic elements — combined with local diffusion models for textures); functional binding (every operating- system primitive is mapped to a corresponding world-affordance); and compilation (the runtime artifact is a deterministic function of the profile, allowing the same profile to regenerate the same world on a different device).

Rendering is performed by a sovereign Vulkan stack written in Zig, targeting 60 fps at 1440p on mid-range consumer hardware. The choice not to depend on Unreal, Unity, or Godot is governed by the same sovereignty principle that governs the rest of the stack: the rendering substrate is part of the trust boundary.

The Functional Mapping layer is the bidirectional event bridge between the operating system and the generated world. A file on disk corresponds to an object in the world; opening it is a world action. A search query is a world event; the result set is a world response. The mapping must satisfy four hard rules: spatial consistency (the same object always appears in the same place); progressive disclosure (the default surface is calm, spectacle is reserved for the environment); an instant-access flat overlay (an escape hatch back to a conventional desktop is always available); and two-speed navigation (close-range manipulation plus long-range traversal).

2.4 The propagation layers (Layers 10–12)

The Propagation Engine is the architectural answer to the multi-device problem. Once the primary device has compiled its configuration, the Propagation Engine produces installable images for every secondary device under the operator's authority. The image variants are bounded — desktop, laptop, phone, server, embedded, networking, companion — and each is assembled from the same configuration manifests, parameterized by hardware class. Cross-compilation is performed by Zig's native cross-compile infrastructure, so the primary device produces images for architectures it does not itself run.

The Sync Fabric binds the resulting fleet over a WireGuard mesh. Device discovery is local (mDNS) by default with an optional self-hosted relay for remote synchronization. File state is reconciled through conflict-free replicated data types; notifications, clipboard contents, and activity continuations are routed peer-to-peer. Device identity is established by per-device Ed25519 keypairs; fleet membership is verified by a fleet-local certificate authority that the operator owns. There is no third-party identity provider, ever.

The Fleet Manager is the administrative surface for non-technical operators. Its design property is cryptographic enforcement rather than policy enforcement: a supervised device cannot install unapproved software because the necessary signing keys are absent from that device, not because a policy file requests that it not. This shifts the trust model from "assume good-faith compliance with rules" to "make non-compliance mathematically infeasible." Per-demographic surfaces (children, elderly, adults) inherit different defaults but share the same enforcement substrate.

2.5 Relationship to other OVRIN systems

GXST OS is a composition target for OVRIN's existing components rather than a parallel project. Lorengine appears as Layer 4. Pneuvade and the ovr-* daemons appear as Layer 1. Phalanx appears as Layer 2. Zeno (post-pivot, in its Elixir/OTP form) appears as Layer 3. Oteka appears as Layer 5. SIGIL Engine's geometric library appears as the proportional substrate of Layer 8. Each of these systems retains independent shippability outside GXST OS; their composition into a sovereign personal operating system is a downstream consequence of having built each of them honestly in isolation.

This section states the staged commitments the design publicly accepts. Each phase has a single demonstration milestone whose passage gates the next.

Phase 0 — Foundation validation

The objective is to boot real consumer hardware from an OVRIN-produced image with the existing compositor providing a usable desktop. The milestone is sustained operator use: a working day completed entirely on the foundation stack, with no fallback to a conventional distribution. This phase consumes existing components rather than producing new ones; it tests integration, not invention.

Phase 1 — Intake and profile derivation

The objective is to run the Intake Engine on the operator's current system, distill a profile, derive a configuration, and apply that configuration to a Pneuvade-built image. The milestone is derived configuration that captures at least seventy per cent of the operator's actual preferences without explicit instruction. This is the existential validation point: if behaviorally-derived configuration cannot beat reasonable defaults, the entire premise of the system is wrong and the design must be revised before further investment.

Phase 2 — World generation

Three sub-phases, each with its own milestone:

• Phase 2a — Generated themes. The Profile Engine drives the visual presentation of Phalanx and Oteka. No three-dimensional rendering. Milestone: the operator prefers the generated theme to the default.
• Phase 2b — Two-dimensional spatial desktop. SIGIL geometry produces navigable node layouts; the Functional Mapping connects layout interactions to operating- system events. Milestone: the operator completes a representative workflow faster on the spatial desktop than on a conventional one.
• Phase 2c — Three-dimensional world. The full Vulkan rendering pipeline; procedural environment generation; high-fidelity functional mapping. Milestone: the demonstration the design is ultimately about.

A decision gate is placed between 2b and 2c. If 2b is not demonstrably better than a conventional desktop, the design does not proceed to 2c; the project falls back to its Phase 1 + Phase 2a configuration as its delivered system. This gate is a structural commitment to honesty about whether the spatial premise survives contact with real use.

Phase 3 — Multi-device propagation

The Propagation Engine produces images for secondary devices; the Sync Fabric binds them. Milestone: a laptop boots a generated image and reaches a synchronized state with the primary desktop in under five seconds.

Phase 4 — Fleet deployment

The Fleet Manager exposes the administrative surface. Milestone: a non-technical family member uses their device for a representative session without opening a terminal.

The minimum viable demonstration

The earliest defensible implementation is the composition of Phase 0, Phase 1, and Phase 2a: a bootable system that observes the operator's behavior, derives a configuration, and applies a personalized visual presentation. Stated as an operator-facing criterion: install this, wait a fortnight, and the system will reshape itself to fit you. Everything beyond this is the long-arc commitment whose feasibility is gated by the milestones above.

A research-grade document is improved by stating its open questions plainly rather than concealing them. The following are the questions GXST OS does not yet answer, in approximate order of consequence.

4.1 Does behavioral derivation beat defaults?

The Phase 1 milestone is an existential test. There is no body of empirical evidence demonstrating that an operating-system configuration derived from a few weeks of behavioral observation produces a more livable system than the configuration a thoughtful distribution maintainer would produce as the default. The thesis that it does is plausible but unproven. The phase is structured so that the test arrives early and cheaply.

4.2 Where is the line between calm and spectacle?

The world layer must be ambitious enough to justify the architectural cost and restrained enough that the operator can still find their files. The four hard rules in §2.3 are the design's current best attempt to draw that line, but they are not yet validated against real use. A design that produces spectacle without restraint will be rejected by the operators who most need sovereignty; a design that produces restraint without spectacle will fail to differentiate.

4.3 Profile longitudinal stability

The intake produces a profile from a bounded observation window. The operator's behavior, identity, and aspirations evolve. The system must accommodate evolution without forcing a full re-intake, and without surfacing the discomfort of a system that no longer reflects who the operator has become. The design does not yet specify the re-derivation cadence, the diff format between profile versions, or the operator-visible presentation of profile evolution.

4.4 Sync correctness without cloud

Conflict-free replicated data types are a partial answer to peer-to-peer state reconciliation, but the full surface — file sync, notifications, clipboard, activity continuation, application-state migration — is not yet specified. Distributed state without a coordinator is an active research domain; GXST OS inherits the open problems of that domain.

4.5 The locked-bootloader honest boundary

Mobile devices whose bootloaders cannot be unlocked are excluded from full installation. The companion-application surface is a concession to that reality, not a triumph over it. The design accepts the concession; it does not yet specify how much of the GXST OS experience is recoverable through a companion app, nor how the boundary is communicated to the operator without disappointment.

4.6 Rendering performance at the long tail

The 60-fps-at-1440p target is reasonable for mid-range consumer hardware in the 2027–2028 window. It is silent about the hardware that operators actually own — older laptops, integrated graphics, ARM single-board computers. The design does not yet specify the graceful-degradation behavior for systems below the target.

4.7 The intake observation period

One to four weeks is a working hypothesis. The actual minimum sufficient observation period is unknown. Too short produces a thin profile and a poor derivation; too long produces a friction during onboarding that the design cannot afford. The empirically defensible window is research-pending.

4.8 Cross-cultural identity inference

The identity-inference layer infers archetype, aesthetic preference, and aspiration from behavioral signals whose interpretation is culturally situated. A system trained against the operator's working assumptions about identity may reproduce those assumptions and fail other populations. The design has not yet specified how the inference layer is bounded against cultural specificity.

These questions are not weaknesses of the design; they are the design's research surface. Resolving them is the substantive work of the next several years.

The intellectual context of GXST OS is best read through five reference classes. The treatment below is brief; each class deserves its own follow-up document.

Sovereign-OS predecessors — Qubes OS, GrapheneOS, Tails. These projects established the rigour of sovereignty through hardening: process isolation, hardware- attested integrity, traffic confinement. They do not personalize, and they explicitly do not generate user-facing form from observed behavior. GXST OS inherits their threat model and their seriousness while opening a new axis they do not address.

Declarative-configuration predecessors — NixOS, Guix. These projects established that an operating system can be a function of a readable, version-controlled specification. GXST OS adopts this principle wholesale; the Profile Engine's output is, in spirit, a generated configuration.nix. The departure is the source: NixOS asks the operator to write the configuration; GXST OS derives it from observation.

Dominant consumer personalization — Apple Intelligence, Microsoft Recall, ChromeOS. These systems have demonstrated that there is real demand for an operating system that adapts to who its user is. They have also demonstrated that the dominant deployment models cannot deliver that adaptation without surrendering the operator's data to remote services. GXST OS treats their adoption as evidence of demand and their constraints as the structural opportunity.

Game-level user-experience precedents — SteamOS, console operating systems generally. These projects have demonstrated that an operating system whose user-facing surface is closer to a game than to a traditional desktop can be adopted at scale. They also demonstrate the cost: SteamOS is highly polished for a single use case (gameplay) and does not generalize. GXST OS proposes generalization through generation rather than through hand-crafting.

Sovereign cognitive-augmentation horizon — Zero Ultra (Citium). GXST OS and Zero Ultra are independent horizons that share an architectural commitment to local execution and operator-owned identity. Where Zero Ultra is the inward-turned application of sovereign infrastructure (the Exocortex), GXST OS is the outward-turned application — the substrate that hosts everything the operator does on a computer. They are designed to compose; neither requires the other to ship.