Skip to content

AncientOS Kernel Specification v1.0

Status: canonical.

This specification defines the AncientOS kernel architecture as it exists today. It is not a roadmap, proposal, or feature plan. Future implementation, documentation, and AI-agent work MUST conform to this specification unless a later version explicitly replaces it.

1. Purpose And Scope

AncientOS is a governed cognition kernel. It provides reusable kernel services for governance, capability reasoning, objective coordination, evidence, operational review, memory authority, runtime awareness, routing, and bounded execution.

Applications consume AncientOS kernel services. Applications MAY own domain-specific workflow state, views, rendering, artifacts, and package-level policy. Applications MUST NOT own kernel responsibilities, bypass kernel governance, or treat transport/provider convenience as authority.

This specification authorizes terminology and architectural boundaries only. It does not authorize new runtime behavior, Discord routes, provider calls, execution lanes, memory writes, background loops, network access, mutation, or approval bypasses.

2. Kernel Invariants

AncientOS MUST preserve these invariants:

  • Governance-first: authority must be explicit, inspectable, and bounded.
  • Read-only by default: inspection and synthesis are preferred over mutation.
  • Mutation requires Lich approval unless an existing explicit Lich gate says no approval is required for the scoped operation.
  • Evidence-backed operation: Zeus defines evidence and audit expectations; Oracle synthesizes supplied evidence for human review.
  • Transport-neutral: Discord, terminal TUI, web UI, CLI, and future interfaces carry requests and render results; they do not own cognition.
  • Provider-neutral: model and tool providers are replaceable implementation surfaces, not identity or authority.
  • Capability-first: callers should request governed capabilities, not hidden tool/model shortcuts.
  • Local-first with governed frontier escalation: local providers are preferred for coding and implementation where eligible; frontier escalation requires governed routing, policy, cost, and evidence boundaries.
  • Deterministic and replayable where possible: outputs, rankings, routing decisions, approvals, and evidence should be stable from the same inputs.
  • No application may own kernel responsibilities.
  • Missing, stale, ambiguous, or conflicting authority MUST fail closed.

3. Kernel Services

Keeper owns objective and task coordination. Keeper is responsible for objectives, task state, planning records, decomposition, execution lane selection, canonical plans, blockers, preflight context, and next-review needs. Keeper does not approve, execute, dispatch workers by itself, or own memory authority.

Rubick owns capability and relationship reasoning. Rubick is responsible for the capability registry, provider/consumer descriptors, repository reasoning, repository intelligence, knowledge graph reasoning, component relationships, and capability truth from evidence. Rubick does not execute providers, approve work, query LifeVault directly, mutate state, or invent capabilities.

Oracle owns read-only evidence synthesis and operational review. Oracle is responsible for operational awareness, observed facts, bounded inferences, risk summaries, review packets, and recommendations. Oracle does not execute, approve, mutate, retain memory, collect host evidence by assumption, or invent facts.

Beastmaster owns runtime and host observation. Beastmaster is responsible for bounded host/runtime awareness from supplied, approved, or replayed evidence. Beastmaster does not approve, mutate, execute, reason about repository impact, or synthesize Oracle conclusions.

LifeVault owns persistent memory authority. LifeVault is responsible for durable memory, promotion status, provenance, supersession/deprecation, archive lifecycle, and retrieval eligibility. LifeVault is distinct from storage backends, operational evidence, repository knowledge, Oracle reports, Rubick descriptors, and chat/session continuity.

Lich owns approval and mutation governance. Lich is responsible for approval classification, confirmation, intake gates, governance decisions, and fail-closed approval boundaries. Lich does not execute work or substitute for Zeus evidence.

Zeus owns evidence and audit authority. Zeus is responsible for evidence expectations, receipts, replay requirements, audit posture, and constitutional supervision hooks. Zeus does not approve, execute, dispatch, or mutate.

4. Applications Vs Kernel Services

Prophet, Naga-Siren, Clockwerk, Keeper Console, Luna interface surfaces, X-feed-worker, dashboards, and future domain packages are applications, workflows, or operator surfaces unless explicitly adopted as kernel services.

Applications MUST consume kernel services through governed contracts. They MUST NOT bypass Lich approval, Zeus evidence, Rubick capability truth, LifeVault memory authority, Keeper objective coordination, or transport-neutral runtime boundaries.

Luna is the current interactive conversation/personality interface over AncientOS. Luna is not the kernel. Keeper Console is an application/UI over Keeper. Prophet and Naga-Siren are governed domain applications. Clockwerk is currently documented as a kernel service for approved scheduling and project evolution visibility where that kernel role is used; any dashboard or UI surface around it remains an application surface.

5. Objective Lifecycle

A governed objective SHOULD follow this lifecycle:

  1. A user or system request enters through a transport.
  2. The transport normalizes the request into a kernel-facing request without taking ownership of cognition, approval, memory, or execution.
  3. Keeper receives or normalizes the objective after the applicable intake gate allows objective coordination.
  4. Rubick discovers relevant capabilities, provider descriptors, repository context, component relationships, and knowledge graph context.
  5. Oracle and Beastmaster provide reviewable evidence when supplied through their boundaries: Oracle synthesizes; Beastmaster observes host/runtime state.
  6. Keeper selects or recommends a bounded execution lane and canonical plan.
  7. Lich gates mutation, dangerous operations, or authority-bearing state changes.
  8. Roshan, Invoker, Tinker, and/or Creeps execute bounded work packages only when scoped authority exists.
  9. Zeus records or validates evidence, receipts, audit posture, and replay expectations.
  10. Results return through the requesting transport with authority, evidence, and limitations preserved.

No stage MAY infer missing approval, missing evidence, missing capability truth, or missing memory authority from convenience, recent context, transport state, model output, or application state.

6. Execution Model

LegionCommander is advisory unless existing governed code explicitly delegates bounded planning behavior. It may form deterministic task graphs and dispatch plans, but it does not approve, self-authorize, or expand scope.

Roshan, Invoker, and Tinker are execution lanes or lane/provider boundaries. Roshan handles elevated or dangerous-operation validation under containment. Invoker handles bounded self-development coordination. Tinker handles local implementation/executor-provider work under governed scope.

Creeps are bounded workers. They execute approved, scoped work packages. They MUST NOT select their own objectives, expand scope, retain hidden state, or retry indefinitely outside their bounded contract.

Underlord is emerging cost/provider escalation governance. Underlord metadata MAY be used for paid, frontier, or externally metered escalation decisions, but it does not grant execution authority by itself.

No execution may occur without bounded authority, capability evidence, governance classification, and required audit/evidence boundaries.

7. Capability And Provider Model

Keeper SHOULD eventually select capabilities and eligible providers rather than explicit model names. Until that is fully realized, code and configuration may still contain model/provider names, but those names are implementation details, not architecture.

Rubick is the authority for capability and repository reasoning. Rubick records which capabilities exist, how they are described, what evidence supports them, and how repository or component relationships affect their use.

Provider and model names, including Ollama, xAI/Grok, OpenAI-compatible APIs, Anthropic-compatible APIs, Codex, Claude Code, GitHub, X API, MCP providers, and search/browser providers, are replaceable implementation surfaces.

Current posture is local-first for coding and implementation lanes. Frontier providers may be used for interactive conversation and eligible inference roles only through governed policy, cost, evidence, and fallback boundaries.

8. Memory Model

LifeVault owns persistent memory. Persistent memory MUST preserve provenance, promotion status, supersession/deprecation state, and retrieval eligibility.

No service, application, transport, provider, or model output may silently mutate canonical memory. Memory promotion and mutation must follow LifeVault and governance rules.

Operational memory, evidence artifacts, repository knowledge, capability descriptors, knowledge capsules, session continuity, and Oracle reports are distinct from persistent memory authority unless LifeVault explicitly promotes them according to policy.

9. Transport Model

Discord, terminal TUI, web UI, CLI, future mobile clients, and future machine interfaces are transports only. They carry requests and render results.

No transport owns cognition, planning, memory, approval, provider selection, capability truth, repository reasoning, or execution.

Transport-specific behavior MUST normalize into kernel requests before it affects planning, governance, routing, memory, or execution. Transport convenience MUST NOT create hidden authority.

10. Governance And Audit Model

Lich defines approval boundaries. Mutation, dangerous operation, authority transfer, or state-changing work MUST pass through the applicable Lich gate.

Zeus defines evidence and audit boundaries. Evidence requirements, receipts, replay material, and constitutional warnings are Zeus-owned surfaces.

Oracle recommendations are advisory. Oracle output may inform human review, Keeper planning, or Zeus evidence context, but Oracle output is not approval, execution authority, dispatch authority, or memory truth.

Approvals, mutations, execution, evidence, and materialized results MUST be traceable. Missing or mismatched approval/evidence MUST block trust carry-forward.

11. Repository And Knowledge Model

Rubick repository intelligence provides read-only repository inventory, import and dependency extraction, reverse dependency lookup, changed-file summaries, impact ranking, repository reasoning reports, and handoff context.

Rubick knowledge graph scaffolding provides deterministic in-memory relationship models for supplied capability descriptors, repository graphs, runtime snapshots, Oracle observations, Keeper preflights, and LifeVault memory references. It does not query live LifeVault, Docker, host state, or external services by itself.

Knowledge capsules and component identities are documentation and discovery surfaces. They MUST align with this specification and MUST NOT claim execution, mutation, approval, provider, transport, or memory authority that is not implemented.

Machine-readable architecture manifests, capability descriptors, registry metadata, operational exports, and Oracle/Rubick-readable knowledge surfaces MUST align with this specification.

12. Non-Goals And Prohibited Drift

AncientOS MUST NOT drift toward:

  • an app-centric ownership model;
  • a model-centric architecture;
  • transport-specific cognition;
  • provider-specific authority;
  • silent memory mutation;
  • silent repository or runtime inspection;
  • autonomous background execution;
  • execution paths bypassing Keeper, Lich, or Zeus boundaries;
  • Oracle as executor or approval authority;
  • Rubick as executor or hidden capability enabler;
  • Keeper as an application-owned task backend;
  • LifeVault alternatives or shadow memory stores.

Historical names may remain in repository paths, service names, environment variables, modules, and tests until an explicit rename is approved. Historical names MUST NOT be treated as current architectural truth when they conflict with this specification.

13. Compatibility And Evolution

Future features MUST conform to this specification. If a future feature needs different architecture, it MUST propose an explicit versioned update to this specification before implementation relies on the new boundary.

Changes to this specification SHOULD be explicit, reviewed, and versioned. Downstream docs, knowledge surfaces, machine-readable manifests, tests, and registry metadata SHOULD be updated in the same change whenever practical.

Historical proposal documents MAY remain historical. Adopted proposals SHOULD include a clear historical or adoption note pointing back to this specification and the current canonical architecture documents.

Implementation/documentation mismatches SHOULD be documented separately rather than resolved by inventing behavior in documentation.