Execution Plane

A Complete Re-Think

BeacenAI’s Execution Plane (formerly zStation) is the execution primitive the platform is built on: a modular, policy-materialized runtime that assembles itself at boot, executes in memory, and leaves no persistent state behind. It spans the layers modern systems normally treat separately—OS, hypervisor, and user-space runtime—so environments can be constructed, governed, and rebuilt as a single unit.

Unlike monolithic distributions that accumulate drift, long-lived configuration, and unmanaged software, the Execution Plane is composed from loosely coupled modules and fused into a running image on demand. With a footprint that can be as small as 1/1000th a conventional Linux build, it behaves less like an installed operating system and more like an environment that is smart enough to build itself.

The system runs entirely in volatile memory with no reliance on local persistent storage, producing performance and consistency that disk-bound systems can’t reach. At the same time, it fully utilizes local devices—including graphics, audio, and peripherals—while remaining cryptographically controlled and policy-bound.

Stateless, Perishable, and Secure by Design:

The Execution Plane is a completely stateless platform. Each session is a brand-new instantiation of the operating environment, built fresh from policy and executed in RAM. The base system is read-only, sharply reducing traditional malware and ransomware attachment points.

This perishable computing model nullifies attack vectors that depend on persistence. Since endpoints are no longer a durable place to “live,” external threat exposure collapses. Internally, threats are constrained through limited kernel exposure, strict policy enforcement, and detailed logging and auditing. Unauthorized software execution is structurally blocked because environments are constructed from policy and cryptographically validated.

Disarming Threats:

• Malware and ransomware lose persistence. With no writable OS layer to attach to, durable compromise is dramatically harder.
• Insider risk is reduced through minimal local trust, strict policy composition, and complete auditing of what can execute.

Cloud Computing & Internet of Things (IoT):

The Execution Plane is not limited to desktops. Because it is modular, small, and policy-assembled, the same primitive applies to cloud server nodes, edge systems, and IoT deployments. It also supports reproducible development and deployment pipelines for CICD lifecycles—ensuring runtime environments remain consistent across all instances and enabling true elasticity without drift.

Execution Plane Construction and Boot

The diagram below depicts the order of operating elements installation. There are three phases of construction, with capability improving at each phase.

The boot phase provides core functionality. Modularity is key to Execution Plane construction, with all required boot elements as loosely coupled modules dynamically fused to form the running image. The requisite boot loader, kernel and root image comprise a verified base system.

Once the base system is booted, an inventory of all hardware present is compiled. A request is sent to the BeacenAI Control Plane (formerly vServer) to provide the required Platform Modules (PM) for that endpoint. This begins the Device Determination Phase. The Control Plane identifies and packages only the required device drivers and platform components, delivering them via secure encrypted protocol. The Execution Plane installs the drivers and performs any required kernel reconfiguration.

The balance of PMs are grouped into Graphics Engine, Window Manager, Desktop Experience, and Audio Modules. These modules can be defined by device type and/or Peer Group, providing end users with a specialized system customized for the device they are using. Only required drivers and associated software are present. The resulting system knows exactly what software is present and what should be executing at every step of the boot process.

Graphics Engine modules provide foundational graphics software, permitting administrator selection of type and version. These modules also fuse configuration requirements obtained from device modules. Window Manager modules define user interaction with the system. Desktop and tablet (touch-screen) systems have different requirements, so decoupling the window manager allows dynamic delivery appropriate to the system in use. Desktop Experience modules provide the user interface and can be tailored to both device and application.

At this point the end user is prompted with a login screen, beginning the Identity Determination Phase. From this point forward, system elements and workload access are delivered based on user identity and context. The user session is executed within a secure container, with identity and authorization governed by the BeacenAI Control Plane rather than trusted to the local runtime. Identity remains transparent to the local kernel by design.