See the Bastion project page for the implementation status sidebar, component breakdown, and project log.
What exists
Bastion currently boots on real x86-64 hardware through UEFI, on a hand-written assembly machine core. Above that floor, the kernel is being rewritten out of Rust and into Vulkgryph (.vg), its own controlled language, which has its own compiler and x86-64 code generator.
The image under proof today is narrow on purpose. It links seventeen .vg services — the scheduler, paging, the allocator, the APIC timer, PCI configuration and ACPI tables — and uses a serial console. A larger surface was built and run on hardware before this: an Ethernet driver with TCP/IPv4/ARP and a guarded shell, live kernel replacement without a full reboot, 802.11 wireless reaching a secured WPA3-SAE association, USB/xHCI, IOMMU/VT-d, keyboard and framebuffer. That work survives as .vg services and is not linked into the current image; the runtime module system that had loaded such code was removed in the same reduction. The scheduler is being qualified boundary by boundary before the surface is rebuilt outward.
Bare-metal x86-64 kernel with UEFI boot, interrupt tables, context switching, syscall trampolines, and atomics.
Built and run on hardware before the current reduction: an Intel Ethernet path with ARP, IPv4, TCP, a guarded TCP shell, and live kernel replacement over the network, plus a secured WPA3-SAE wireless association. The wireless data path was never reached. None of it is linked into the image under proof today.
PCI configuration, DMA allocation, the APIC timer, ACPI tables and a serial console are in the current image. Framebuffer, keyboard and USB-controller work exists as .vg services but is not linked into it.
Vulkgryph (.vg) compiles process descriptions to native x86-64 ELF — runnable binaries for Linux development, and relocatable objects the kernel links against.
Current direction
The direction is a small, inspectable system with explicit boundaries: boot, interrupts, drivers, network state, service behavior, and remote operation are kept visible rather than hidden behind a general-purpose operating environment.
Concretely, that now means removing Rust from the kernel in favour of .vg, subsystem by subsystem. Scheduling, timer and interrupt sequencing, exception containment, paging, ACPI parsing, and the IOMMU path have moved across, and the superseded Rust is deleted rather than left in place. Each boundary is recorded with the baseline commits it was proven against, the tested kernel hash, and an explicit statement of what it does not claim; most are qualified across five consecutive runs on real hardware rather than in emulation.
Current limits
Bastion is still an active engineering system. It needs production hardening, external documentation, naming cleanup, and validation across more machines before it should be treated as deployable software. There is no release date.
Full self-hosting is not claimed. Kernel builds accept a natively compiled object only when it is byte-identical to the output of the Rust reference compiler, and the reference is still used where that match is unavailable — so Rust continues to participate in producing some kernel objects. Native object staging across the whole kernel, the operator shells, C interoperability needed for ACPI, the wireless data path, and the trust-anchor work all remain open.