Architecture

Architecture

Purpose

This page describes the full operating-system shape of XAI OS.

Contents

• System Shape
• Kernel Responsibilities
• Runtime Responsibilities
• AI Cell Model
• Control Plane and Hot Path
• What XAI OS Does Not Do

System Shape

XAI OS is a server-only OS for CPU-only AI app agents. It is optimized around fixed resource ownership instead of general-purpose desktop interactivity or broad POSIX compatibility first.

The native execution unit is the AI Cell. An AI Cell owns fixed CPU cores, fixed memory arenas, fixed model-weight mappings, fixed KV/cache arenas, fixed NIC queues, fixed source-code indexes, fixed build/test sandboxes, fixed Git workspaces, and fixed telemetry counters.

Kernel Responsibilities

The kernel owns:

• boot and CPU bring-up;
• physical and virtual memory protection;
• capability enforcement;
• IOMMU/SMMU protection;
• interrupt routing;
• core leases;
• fault handling;
• device setup;
• service supervision;
• signed update and rollback foundations;
• SSH-only administration.

The kernel should enforce ownership and isolation without sitting on the hot path.

Runtime Responsibilities

The user/app runtime owns:

• model loading and tokenizer boundaries;
• CPU-only inference loops;
• app-agent command handling;
• source-code indexing;
• patch generation;
• isolated build and test workflows;
• Git operations;
• service telemetry emission.

AI Cell Model

An AI Cell declares its resource contract before it starts. XAI OS either grants that contract or refuses the service start. This avoids hidden contention after an agent reaches READY.

See AI Cells, Memory System, and Scheduler and Core Isolation.

Control Plane and Hot Path

The control plane handles SSH administration, service startup, logging, updates, and slow management work.

The hot path handles latency-sensitive AI agent traffic:

NIC queue -> app-agent TCP/UDP path -> command parser -> CPU AI runtime -> source/code tools -> response stream

The hot path target is no migration, no involuntary context switching, no post-warmup page faults, and no unrelated interrupts.

Request Flow

human/API request
  -> low-latency TCP/UDP queue
  -> AI Cell network worker
  -> CPU-only AI runtime
  -> source-code index
  -> patch/build/test/Git workflow
  -> response or hot reload/redeploy

Kernel Responsibility Table

Responsibility	Purpose	Hot-path rule
Boot	Enter kernel from UEFI and preserve boot info	Boot-only
CPU bring-up	Discover and start cores	No generic balancing on AI cores
Memory ownership	Assign arenas and protect regions	No post-READY hot-path faults
Virtual memory	Map kernel, user, MMIO, and model arenas	Hugepage/large-page aware
Capabilities	Authorize cores, memory, devices, and Git/build access	Deny undeclared access
IOMMU/SMMU	Protect DMA	Device ownership must be explicit
Interrupt routing	Keep unrelated IRQs off hot cores	Hot-core IRQs are bugs unless declared
Core leases	Pin workers to owned cores	No migration by default
Faults	Diagnose and isolate failures	Faulting cell drains or stops
Device setup	Configure serial, PCI, VirtIO, NVMe, NICs	Queue ownership is explicit
Service supervision	Start, stop, and restart cells	Control-plane cores only
SSH/admin	Manage system and services	Public-key auth only

What XAI OS Does Not Do

XAI OS is not:

• a Linux distribution;
• a BSD fork;
• a desktop OS;
• a GPU AI runtime;
• a CUDA or Metal replacement;
• a Kubernetes clone;
• a POSIX compatibility project first;
• a claim that software can exceed hardware limits.

Related Pages

• Project Purpose
• Performance Targets
• Implementation Plan
• Risk Register