ITISYOU_OS
PRE-ALPHA

SYSTEM / PUBLIC ENGINEERING RECORD

ITISYOU OS

Building an operating system from the kernel upward.

A long-term research and engineering project exploring what a personal operating system could look like if designed today around explicit privilege boundaries, strong kernel/user isolation, recoverable and auditable system changes, reproducible builds, and local-first intelligence — where AI can reason about the system but never holds unrestricted kernel authority.

Explore the architecture View current build
Current milestone — V0.2 — Userspace Foundation PRE-ALPHA
System layer model
  1. L5 AI layer intelligence, never authority CONCEPT
  2. L4 Privileged services / capability engine deterministic policy layer CONCEPT
  3. L3 Userspace ring 3, syscall ABI — single process (V0.2) VERIFIED
  4. L2 Kernel Rust no_std, x86_64, ring 0 VERIFIED
  5. L1 Bootloader rust-osdev crate, BIOS & UEFI stages VERIFIED
  6. L0 Firmware SeaBIOS / OVMF-UEFI, inside QEMU ENVIRONMENT

Layers above the kernel are documented direction, not implemented functionality. See /architecture.

Physical-Hardware Warning

ITISYOU OS is an experimental, pre-alpha research kernel. It is developed and verified exclusively inside QEMU with project-generated disposable disk images. Do not install it on physical hardware, point it at a real disk, or expect it to preserve data. There are no production builds.

What we’re building now

Milestone “V0.2 — Userspace Foundation”

Current Build

LOCALLY-VERIFIED
VERSION
v0.2.0-dev
MATURITY
pre-alpha
MILESTONE
V0.2 — Userspace Foundation
ARCH
x86_64
ENVIRONMENT
QEMU (BIOS + UEFI/OVMF)
COMMIT
cc29cda
LAST VERIFIED
2026-09-02T07:35:00Z
TRUTH SOURCE
status/current.json

Fields marked “—” have no verification evidence yet and are reported as absent rather than estimated.

  • Boot path (BIOS + UEFI via bootloader crate)

    VERIFIED

    MODULE / boot

  • Serial console & structured boot stages

    VERIFIED

    MODULE / serial

  • CPU identification

    VERIFIED

    MODULE / cpu

  • Physical memory manager

    VERIFIED

    MODULE / memory-physical

  • Virtual memory / paging (kernel + user W^X)

    VERIFIED

    MODULE / memory-virtual

  • Kernel heap allocator

    VERIFIED

    MODULE / heap

  • GDT/IDT, exceptions, PIC/PIT timer

    VERIFIED

    MODULE / interrupts

  • Kernel tasks & cooperative scheduler

    VERIFIED

    MODULE / scheduler

  • VFS & embedded initramfs

    VERIFIED

    MODULE / vfs

  • Interactive serial shell (14 commands)

    VERIFIED

    MODULE / shell

  • ELF64 loader (strict validation, W^X)

    VERIFIED

    MODULE / elf-loader

  • Ring 3 execution & privilege isolation

    VERIFIED

    MODULE / ring3

  • Syscall ABI (write/exit/yield/getpid)

    VERIFIED

    MODULE / syscalls

  • Process lifecycle & crash containment

    VERIFIED

    MODULE / process

  • Per-process page tables (concurrent processes)

    PLANNED

    MODULE / process-isolation

  • PS/2 keyboard input

    PLANNED

    MODULE / input-keyboard

  • QEMU boot/regression harness

    VERIFIED

    MODULE / test-harness

Statuses are read from status/current.json at build time. “Implemented” and “Verified” are not interchangeable; anything not marked Verified should be assumed incomplete.

Boot sequence

Boot-Stage Contract B000 → B150 kernel-core::stage · serial markers

Each stage emits one machine-parseable serial marker — [ITISYOU:B0xx] description — asserted in order by the QEMU harness. Stage statuses below are the live module statuses, not a boot capture.

  1. B000 firmware/loader handoff observed VERIFIED
  2. B010 kernel entry reached in 64-bit mode VERIFIED
  3. B020 early serial console ready VERIFIED
  4. B030 CPU baseline established VERIFIED
  5. B040 boot memory map validated VERIFIED
  6. B050 physical memory manager ready VERIFIED
  7. B060 virtual memory abstraction ready VERIFIED
  8. B070 kernel heap ready VERIFIED
  9. B080 descriptor/exception layer ready VERIFIED
  10. B090 interrupt controller/timer ready VERIFIED
  11. B100 scheduler initialized VERIFIED
  12. B110 VFS/initramfs initialized VERIFIED
  13. B120 input path initialized VERIFIED
  14. B130 shell/init task running VERIFIED
  15. B140 userspace transition ready VERIFIED
  16. B150 V0.1 boot acceptance reached VERIFIED

Why build another OS?

Linux is a mature, broad, production-proven kernel ecosystem — ITISYOU OS does not claim to be better than it, and is not a Linux distribution. It contains no Linux kernel code at runtime.

Instead, this project documents specific research hypotheses to test for a constrained personal-computing target: what changes when explicit authority boundaries, verification evidence, and recoverability are design inputs from the first boot stage rather than retrofits.

  • Explicit authority

    Privilege and authority boundaries are declared, inspectable, and narrow — never ambient.

  • Evidence over claims

    A subsystem is “done” only when an automated QEMU run proves it. The website reads that evidence, not marketing intent.

  • Recoverable by design

    System changes should be auditable, verifiable, and reversible — recovery is architecture, not an afterthought.

  • Local-first intelligence

    Future AI assistance runs against local state under a policy engine. It advises; it does not rule.

SECURITY PRINCIPLE 01

AI has intelligence,
not authority.

Any future AI/agent layer reasons about the system and proposes actions; it never executes privileged kernel operations directly. The principle exists now — before any AI component — because it constrains how every kernel interface is designed.

No AI component exists in the current runtime. See the security model.

The verification loop

  1. STEP_01 Specification requirement + gate defined first
  2. STEP_02 Implementation Rust no_std, unsafe documented
  3. STEP_03 Compile pinned nightly, reproducible
  4. STEP_04 QEMU Boot BIOS + UEFI matrix
  5. STEP_05 Verification markers, selftests, JSON evidence

A hang, panic, or missing marker can never pass. Absence of output is never success.

Roadmap

Sequenced by dependency, not calendar — no dates.

  1. V0.1 Kernel Foundation IN DEVELOPMENT
  2. V0.2 Userspace Foundation PLANNED
  3. V0.3 Storage PLANNED
  4. V0.4 Networking PLANNED
  5. V0.5 Graphics & Desktop Foundations PLANNED
  6. V0.6 Hardware Expansion PLANNED
  7. V0.7 System Platform PLANNED
  8. V0.8 AI-Native System Layer CONCEPT
  9. V0.9 Daily-Driver Research CONCEPT
  10. V1.0 Experimental Personal OS CONCEPT
Full roadmap

Development story

Decisions, failures, root causes, fixes — logged as they happen.

2026-09-02 02:30 Session 1 — Foundation IN DEVELOPMENT

Kernel skeleton and test harness authored

Workspace laid down: kernel/ (lib + interactive and selftest binaries), crates/kernel-core (host-testable stage/marker contract), tools/image-builder (pure-Rust BIOS/UEFI images + SHA-256 manifest), tools/qemu-runner (deterministic boot assertion harness with JSON evidence).

error: unknown Cargo.toml feature `bindeps` — resolved in .cargo/config.toml

2026-09-02 02:20 Session 1 — Foundation IN DEVELOPMENT

Governance intake and discovery

Read AGENT_OPERATING_RULES.md and the end-to-end implementation plan; both adopted as binding. Requirement traceability matrix created (docs/REQUIREMENTS.md). Stitch design export preserved unchanged in design/ and extracted as the visual source of truth.

docs/REQUIREMENTS.md · docs/adr/0001..0003 · design/stitch/ (13 screens + DESIGN.md)

Full ledger

Long-term research direction

The trajectory runs from kernel foundation through userspace, storage, networking, graphics and hardware expansion toward an experimental personal OS with an AI-native system layer — local inference outside the kernel, policy-controlled actions with preview and approval, provenance and audit for everything.

Every milestone must pass its verification gates before it is claimed. Modern hardware assumptions are preferred over universal legacy compatibility from day one.

Philosophy & vision Engineering process

Source & documentation

The repository is private during early development and will open once the V0.1 foundation and its verification evidence stabilize. The engineering documentation is public now.

Read the docs Source access