Identity + Policy + Approval
Unix peer identity, Agent Registry, fail-closed capability policy and target-bound one-time Approval are implemented and covered by current core tests.
KINGAI OS separates source existence, CI verification, VM/hardware validation, published artifacts and production readiness. A later state is never inferred from an earlier one.
Source: 0.1.0-dev · Stage: D5 Alpha Runtime Foundation / Pre-Alpha · Facts updated: 2026-08-14
Unix peer identity, Agent Registry, fail-closed capability policy and target-bound one-time Approval are implemented and covered by current core tests.
Persistent tasks, dependency validation, step lifecycle, approval waits, failure propagation and automatic task completion exist in the D5 source line.
A separate privileged broker exists with capability-specific handlers. The current native privileged capability is deliberately narrow rather than a generic root shell.
Layered memory metadata, local persistence, search, expiry and controlled promotion foundations are implemented in source and unit tests.
Provider-neutral routing, provider registry/health and a replaceable runtime adapter contract are implemented; production provider and external-runtime integrations remain future release work.
The merged D5 main commit has passed Foundation CI and CodeQL. These verify software foundations, not production signing or hardware certification.
A public amd64 Developer Preview exists. Newer D5 source capabilities may be ahead of that published image.
Personal-computer edition with Plasma 6 core, three experiences, live/installer validation tracks and Agent Center foundations.
Generic amd64/arm64 image pipelines exist; board-specific support still requires validated Device Packs on real hardware.
Docker/OCI profile, non-root runtime, persistent state pattern and CI image/runtime smoke path exist. Official production publication is still gated.
Server/Desktop build and VM tracks cover install, live boot and BIOS/UEFI engineering paths.
Dedicated VM paths exercise staging, health confirmation, rollback and recovery workflows.
Client-side trust behavior and VM Secure Boot validation exist, but they are not equivalent to production key custody.
Threshold-key operations, offline key custody and final production Secure Boot signing are intentionally not claimed ready.
Raspberry Pi, Jetson and industrial Device Packs require real board boot validation before being listed as supported.
Release governance, final vulnerability/legal review, artifact delivery, signing and lifecycle commitments must pass before Stable.
The detailed ledger and machine-readable release gates live in the public source repository.