Arcology OS

One component of The Arcology

Arcology OS is the operating system, not the name of the entire Arcology ecosystem. It owns the freestanding systems layer, hardware bring-up, operating environment, object services, system management, and the eventual desktop.

The Arcology is the larger whole. Its language, compiler, executable forms, philosophy, applications, and other projects can participate in Arcology OS without being reduced to parts of the OS itself.

Designed from the experience outward

Arcology OS begins with the application and object environment, then derives the system foundation needed to support it. Existing kernel conventions do not get to dictate the experience merely because they are familiar.

The desktop direction is responsive, tactile, inspectable, and cybernetic without sacrificing usability. Graphical and terminal interfaces are intended to become two understandable views into the same object environment.

Four architectural pillars

Replaceable Object Architecture: composable behavior behind explicit interfaces
ArcoBASIC as Universal Control Language: scripting, inspection, automation, extension, and systems implementation
Capability-Oriented Object Substrate: a small privileged mechanism layer beneath replaceable policy
Central System Manager: visible testing, replacement, rollback, profiles, capabilities, and substrate generations

Current implementation boundary

Freestanding ArcoBASIC-to-UEFI x86-64 compilation and boot fixtures
APS-owned page tables and demonstrated CR3 authority cutover, confirmed on real physical hardware, not only QEMU
Real PS/2 and USB HID keyboard drivers running entirely on their own, with no firmware left underneath them
A live boot screen showing real subsystems assembling themselves, and a real interactive `READY.` prompt behind it
Physical Region Database policy written in ArcoBASIC
A routed hardware timer and a substrate dispatch loop hooks register against
A typed block-storage contract and ArcologyFS, a crash-safe copy-on-write native filesystem, itself confirmed on real physical storage
A real Arcology System Namespace, with a filesystem able to attach into it
Hosted opaque-handle Resource Registry reference implementation
Foundational graphics and Surface work, now extending toward a real, vendor-neutral native display driver
Architecture, RFCs, hardware harnesses, tests, and tooling maintained together

What Arcology OS is becoming

The intended environment is hackable without being hostile, replaceable without being fragile, and powerful without requiring people to memorize implementation plumbing.

A complete desktop, persistent system Contracts, live capability enforcement, a production-scale filesystem, scheduling, networking, and production-grade lifecycle transfer remain active design and implementation work. Storage moved from nothing to a proven filesystem core with real crash safety; growable on-disk structures and real space reclamation are the next named increment, not a vague someday.

Designing outward instead of inheriting a shape

The specific pillars above, Replaceable Object Architecture, a capability substrate, a central system manager, are Arcology-specific answers. The question that produced them is not: what should the experience feel like first, and only then, what foundation does that experience require. That ordering is the part worth taking elsewhere.

Start from the outcome a user or caller actually needs, then derive the layers beneath it, instead of adopting a foundation because it is the conventional one and forcing the experience to fit what it allows.
Keep the boundary between mechanism and policy visible and named, the way the current implementation boundary list separates what is proven from what is still design work; a boundary nobody can point to is a boundary nobody is actually enforcing.
Let a status list say "active work" instead of implying completion. A roadmap that distinguishes proven ground from open ground is more useful to a reader, and to the builder, than one that reads as finished a year early.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Freestanding program: A program that cannot assume an operating system, filesystem, heap, or standard runtime already exists. It must explicitly choose the small set of facilities available at its target.
UEFIUnified Extensible Firmware Interface: The standardized firmware environment that starts a modern computer before an operating system takes control. Arcology OS currently enters through UEFI during hardware bring-up.
APSArcology Polymorphic Substrate: The small privileged foundation beneath Arcology OS. It provides essential mechanisms while replaceable components provide most higher-level policy.
Physical address: A location in the machine’s actual addressable memory or device space. Firmware and hardware report physical locations; applications normally should not use them directly.
Virtual address: A location in the address space currently presented to software. Page tables decide which physical memory or device, if any, appears at that virtual location.
Page table: A data structure used by the CPU to translate the virtual addresses a program uses into physical memory locations. It also carries access rules such as writable or executable.
CR3Control Register 3: An x86-64 CPU register that points to the active top-level page table. Writing CR3 changes which virtual-memory map the processor uses.
PRDPhysical Region Database: Arcology OS records every known piece of physical memory here, including who owns it, what it is for, and whether it is free or reserved. This replaces scattered allocator knowledge with one inspectable source of truth.
Opaque handle: A safe identifier for a resource whose internal memory address and representation stay hidden. Applications pass the handle back to the API that owns it.