AncientOS Documentation

This is the canonical documentation entry point for the AncientOS governed runtime and its configurable assistant presentation. Luna is the default name; Discord, Terminal and Web are transports. See Identity Model.

See Meeting Intelligence for the governed edge producer, LifeVault evidence, query, privacy, and Meetily integration boundary.

See Governed continuations for exact deferred-work persistence, canonical-principal ownership, and resume boundaries.

AncientOS is a transport-neutral, provider-neutral governed cognition kernel for personal AI continuity.

“Operating system” describes its responsibility boundary, not a claim that it replaces the host OS: AncientOS mediates governed access to cognition, memory, capabilities, providers, evidence, and bounded execution for applications above it. The conversational assistant is an interface, not the system boundary.

The current coherent milestone is AncientOS Platform v1 Alpha. It is intended for controlled single-operator use and continued capability development; it is not production-ready. Start with the documentation reality and status index to distinguish canonical present truth, active roadmap work, historical proposals, legacy documents, knowledge surfaces, and generated output.

Public shorthand: "AncientOS lets your AI relationship move with you."

The Rote design corpus and its architecture reconciliation preserve supplied product intent and open decisions. Document ingestion does not establish Rote implementation or full Luna retrieval availability.

What lives here

High-level architecture
Operational concepts
Canonical terminology and architecture boundaries
Visual diagrams
Links into generated Sphinx API docs

Canonical vocabulary

Start with Canonical Terminology when naming the AncientOS kernel, Luna interface, kernel services, applications/workflows, transports, providers, and external-tool boundaries.

Use the Architecture and Capability Posture Taxonomy to distinguish implementation, wiring, operator reachability, authority, persistence, and validation evidence. A single “ready” or “active” label is not a complete capability claim.

Use AncientOS Kernel Specification v1.0 as the constitutional architecture reference for kernel invariants, service ownership, application boundaries, provider/capability posture, memory, transport, governance, repository knowledge, and prohibited drift.

Use Durable Governed Actions as the canonical implemented mutation boundary. Older v3 and Chen domain documents remain design and historical context; Runtime Composition and the Durable Governed Action documentation determine live readiness.

Use Governance Kernel as the canonical architecture reference for the Objective to Loop lifecycle, authority boundaries, Oracle review model, evidence, approval, execution, and LifeVault retention.

AncientOS is the persistent governed cognition kernel around AI relationships. The assistant has a user-configurable name, defaulting to Luna, over AncientOS. Existing repo, service, path, API, command, environment variable, and module names may still use historical Luna naming until a future mechanical rename phase.

Runtime context

Roadmap alignment

The governed operator-loop foundation is complete. The single roadmap adoption authority is the Governed Capability Portfolio roadmap. The master portfolio view renders current operator status but cannot independently adopt work. Root Era plans are historical records, not readiness or execution queues. Era 7 and Era 8 are complete historical programs. No numbered era is active, Era 9 is not adopted, and no capability is currently adopted or in progress.