Luna Master Roadmap

Canonical Present Truth

AncientOS is a transport-neutral, provider-neutral governed cognition kernel for personal AI continuity. Simpler public framing: "AncientOS lets your AI relationship move with you."

The project exists to preserve continuity, trust, memory, identity, governance, operational alignment, reasoning style, and cognitive relationship across changing models, providers, transports, hardware, runtime locations, and future AI infrastructure shifts. Governance, execution lanes, ontology, inference routing, and operational visibility are supporting kernel infrastructure for that continuity layer, not the core thesis by themselves.

Luna is the current interactive cognition/personality and interface layer over AncientOS, not the kernel itself. The project is not a Discord bot, enterprise governance platform, compliance framework, autonomous agent swarm, or AGI project.

The present validated direction is portable, human-centered operational continuity. AncientOS may support reasoning, interpretation, planning, summarization, validation, and proposal workflows through apps such as Luna and Prophet, but execution remains bounded by governance, deterministic artifacts, approval gates, validation contracts, replayable evidence, and constitutional supervision. Prophet is read-only prediction-market intelligence with advisory/manual-review recommendations and disabled fail-closed execution.

Core Thesis And Scope

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

Public-facing framing: AncientOS lets your AI relationship move with you.

Supporting phrases: - The continuity layer around AI. - Portable AI continuity infrastructure. - A persistent intelligence layer independent of any single model or interface. - Your long-term AI relationship, separated from vendors and transports.

Core: - personal AI continuity - durable memory and context - trusted identity and reasoning style across model/provider changes - operator-centered control - transport and provider independence - fail-closed governance where meaningful state can change

Supporting infrastructure: - governance and approval gates - Rubick continuity posture control plane - Meepo transition integrity enforcement - Roshan/Tinker/Invoker execution lanes - Oracle operational legibility - LifeVault memory continuity - model-provider abstraction - transport adapters such as Discord

Aspirational: - richer multi-app workflows - Zeus constitutional supervision - Underlord paid escalation governance - broader bounded operation - future transport clients and runtime locations

Intentionally bounded: - no unrestricted autonomy - no hidden planner loops - no model-owned authority - no transport-owned cognition - no direct memory mutation from retrieval - no execution without approval, validation, rollback, and audit when required

Validated Runtime Surfaces

Surface	Present validated role	Boundary
app/runtime/kernel.py	Transport-neutral runtime kernel, historically named Luna Runtime Kernel	Owns message-processing order; does not own Discord rendering or direct execution.
app/runtime/state_store.py and sibling runtime-state modules	Governed Runtime Cognitive State for bounded operational continuity	Stores scoped operational facts; not execution authority.
app/architecture/*	Governed architectural awareness, roadmap cognition, dependency readiness, drift warnings, advisory next-step synthesis	Read-only reports; no roadmap mutation.
app/oracle/*	Standalone Oracle read-only visibility and governed situational-awareness service over architectural and operational evidence	Visibility, synthesis, topology, propagation, risk, drift, bottleneck, and narrative continuity only; no execution, mutation, approval, or repair authority.
app/coordination/*	Governed coordination cognition substrate for workflow state, dependency reasoning, proposal sequencing, capability composition, bounded simulation, recovery proposals, and coordination-risk warnings	Advisory-only proposal and analysis layer; no execution, approval, scheduling, remediation, recursive planning, hidden workflows, or runtime-owned authority.
app/routing/operational_cognition_router.py and app/oracle/operational_console.py	Luna operator-console routing and transport-neutral operational console rendering	Routes introspection to Oracle/cognition instead of execution staging; no mutation, approval, scheduling, or transport-owned semantics.
app/inference/*	Governed named inference roles over luna-inference for eligible model calls	Model outputs are advisory; no model-owned routing, approval, or execution authority.
app/capabilities/*	Governed capability ontology, registry, policy, evidence, degradation, and arbitration reports	Capability reasoning only; no work execution.
app/interoperability/mcp_authorization/*, app/interoperability/mcp_approval/*, and app/interoperability/mcp_execution_planning/*	Governed MCP authorization, immutable approval packet generation, and execution planning substrate	Answers required approval, evidence, governance path, and future plan questions only; no MCP execution.
app/interoperability/skill_registry/*	Governed skill metadata, skill contracts, skill-capability mappings, skill graph validation, reports, and advisory recommendations	Skill intent and governance metadata only; no execution, provider invocation, Rubick mutation, Discord dependency, automatic optimization, or autonomous lifecycle transition.
app/interoperability/skill_intelligence/*	Advisory skill health, fitness, overlap, gap, strategic importance, recommendation, and report layer	Skill ecosystem reasoning only; no execution, provider invocation, Rubick mutation, lifecycle mutation, automatic optimization, automatic promotion, automatic deprecation, Discord dependency, or transport dependency.
app/interoperability/objective_governance/*	Objective metadata above skills, objective-skill-capability mapping, lifecycle simulation, portfolio aggregation, intelligence assessment, validation, reports, and advisory recommendations	Objective purpose metadata only; no execution, provider invocation, MCP enablement apply, lifecycle mutation, autonomous goals, automatic planning, automatic promotion, automatic retirement, Discord dependency, or transport dependency.
app/interoperability/gap_intelligence/*	Era 7C advisory gap intelligence and roadmap intelligence for Objective -> Skill -> Capability -> Provider support	Reports missing, weak, dormant, unresolved, and underrepresented support; recommendations and priority assessments only; no execution, provider invocation, lifecycle mutation, capability creation, skill creation, objective creation, autonomous planning, roadmap mutation, Discord dependency, or transport dependency.
app/interoperability/conversational_intake/*	Rule-based natural-language intake that maps operator text to governed objective, skill, capability, proposal, and next-step structures	Intake only; no Discord behavior, LLM call, provider invocation, MCP enablement apply, lifecycle mutation, objective mutation, automatic approval, execution, or hidden autonomy.
app/runtime/discord_adapter.py and app/bot.py	Discord ingress, envelope conversion, lifecycle, and rendering shell	Discord does not own cognition, planning, routing, governance, or execution semantics.

AncientOS/Luna state remains file-backed, inspectable, bounded, replayable, and fail-closed because those properties make continuity trustworthy across changing infrastructure.

Continuity Stack

AncientOS is the continuity layer. The current stack should be read from stable identity inward to replaceable infrastructure outward:

Layer	Continuity role
AncientOS	Transport-neutral, model-agnostic continuity substrate for the operator's long-term AI relationship.
Luna	Interactive cognition/persona surface that expresses the relationship through the current app/interface.
LifeVault	Long-term memory continuity and preservation substrate.
Rubick	Continuity posture layer and governed control plane for settings, ontology visibility, prompt/profile posture, cognitive modes, and runtime abstraction.
Meepo	Transition integrity infrastructure that revalidates approved state changes so continuity trust survives transitions.
Oracle	Read-only state and evidence explanation layer for operator legibility.
Roshan / Tinker / Invoker	Bounded execution and implementation paths that may act only under approved scope, validation, and replayable evidence.
Transports	Discord, CLI, web, mobile, and future interfaces that carry interaction without owning continuity.
Providers/models	Replaceable inference and execution infrastructure behind governed contracts. Frontier models are infrastructure, not identity.

Continuity Primitives

The roadmap uses six continuity primitives:

Primitive	Meaning	Primary owners
Memory continuity	Durable, reviewable memory and context that can survive model, provider, transport, and runtime changes.	LifeVault, Keeper, context retrieval
Posture continuity	Operator-visible behavior, prompt/profile stance, cognitive mode, and continuity-safe configuration across changing infrastructure.	Rubick
Transition continuity	Trust-preserving revalidation when approved state moves from proposal to execution, result, commit, or promotion.	Meepo
Governance continuity	Approval, policy, audit, rollback, and fail-closed expectations remain stable across lanes and providers.	Rubick, Lich language, Meepo, Zeus
Interaction continuity	The AI relationship can move across Discord, CLI, web, mobile, and future transports without losing identity or context.	Luna, transport adapters, AncientOS runtime
Execution continuity	Bounded execution paths remain replayable, validated, and provider-independent as executors change.	Roshan, Tinker, Invoker

Continuity risks are tracked explicitly:

• vendor lock-in
• memory fragmentation
• posture drift
• transition drift
• provider coupling
• transport coupling
• governance inconsistency

The long-term architecture should support provider switching without relationship loss, transport switching without relationship loss, prompt/profile portability, continuity-safe upgrades, long-term AI relationship persistence, and continuity-preserving migrations.

Present Taxonomy

Class	Present members	Current interpretation
Kernel services and lanes	Rubick, Oracle, Keeper, Beastmaster, LifeVault, Lich, Zeus, Meepo, Clockwerk, LegionCommander, Roshan, Invoker, TrollWarlord, Tinker, Creep, Kunkka, Nyx	Symbolic kernel services, components, lanes, or candidates. Their present role is constrained by validated runtime evidence and explicit migration notes below.
Kernel primitives	governance, routing/arbitration, memory authority, artifacts, ledgers, evidence, capability registry, provider selection, policy engine, replay/provenance, repository reasoning, knowledge graph reasoning, operational awareness	Reusable AncientOS primitives, not application-owned hidden authority.
Applications/workflows	Luna, Naga-Siren, Prophet, Keeper Console, X-feed-worker	Domain workflows and interfaces using kernel capabilities under governance.
Providers/adapters	Ollama, xAI/Grok, OpenAI-compatible APIs, Anthropic, Codex, Claude Code, X API, GitHub, MCP providers, search/browser providers	External or local capability surfaces behind governed contracts; not app owners or authority sources.
Interfaces/transports	Discord, terminal TUI, CLI, Web, Android, future desktop/mobile clients	Swappable interaction surfaces; not the kernel.

Canonical terminology for these roles and provider boundaries is maintained in Canonical Terminology. The roadmap treats external repos and tools as patterns, references, integrations, or provider candidates until AncientOS explicitly adopts them under governed contracts.

Transitional Naming / Migration Context

This roadmap is a semantic taxonomy update, not a mechanical rename plan. Existing repo names, service names, modules, API paths, Docker services, environment variables, commands, database paths, imports, and persisted artifact paths may still use historical Luna naming until a separately approved mechanical rename phase.

Historical name or surface	Current validated meaning	Migration note
Luna Runtime Kernel	AncientOS transport-neutral runtime kernel	Keep existing code names until a compatibility-preserving rename is approved.
discord-luna	Repository and compatibility shell containing Luna interface code and historically named AncientOS kernel code	Repository name is historical; do not infer Discord ownership of cognition.
Lich	Current runtime governance/approval/confirmation language	Do not describe Lich as a present archival memory subsystem. Any archival-memory role is future speculative and requires a role split or rename plan.
Kunkka	Historical deterministic patch mutation language and future navigation/workflow routing candidate language	Preserve current runtime references; future role split must clarify patch mutation versus navigation/routing.
Keeper	Current objective/task coordination kernel service	Preserve runtime context; Keeper Console is the application/UI over Keeper. Memory preservation belongs under LifeVault doctrine unless a future governed application boundary is explicitly introduced.
Underlord	Planned investment-aware paid escalation approval gate	Not a general approval replacement and not active broad runtime authority.

Constitutional Doctrine

The following invariants supersede implementation convenience, model preference, naming convenience, and short-term capability gains.

Current hard limits: - No broad autonomous execution. - No unrestricted shell authority. - No hidden planner loops. - No recursive self-execution. - No unbounded filesystem mutation. - No direct memory mutation from retrieval. - No vague chat memory or unbounded conversation-log retention. - No runtime state as execution authority or approval bypass. - No live runtime coupling without governance gates. - No paid external intelligence escalation without explicit approval. - No open-ended external token expenditure.

AncientOS/Luna must remain: - deterministic-first - artifact-driven - governance-gated - replayable - inspectable - versioned - offline-safe - transport-neutral - provider-neutral - fail-closed - model-portable - human-governed - operationally legible - constitutionally supervised - investment-aware for paid escalation - coordination proposals are not execution authority - operational introspection is not execution intent

Core rule: capability visibility is not authority. Observation, planning, simulation, inference, recommendation, or arbitration does not imply permission to execute.

Interoperability rule: MCP discovery, authorization, approval packets, and execution plans are not execution authority. Era 6D.1 adds exactly one default-disabled real read-only MCP capability, inspect_disk_space, behind the complete governed lane: Discovery -> Identity -> Intent -> Trust -> Authority -> Reasoned Authorization -> Approval Packet -> Execution Plan -> Invocation Candidate -> Lich Gate -> Zeus Evidence Gate -> Read-Only Execution Facade -> Receipt.

Objective rule: Objective metadata explains why skills and capabilities exist. It is not a goal engine, planner, lifecycle authority, provider invocation path, execution lane, MCP enablement apply path, Discord behavior, or automatic promotion/retirement system. Era 6D.2 adds a local operator validation harness for inspecting that packet chain with fake-provider scenarios by default and explicit real-provider opt-in. The harness is validation-only and adds no second MCP capability, public transport, Discord routing, mutating execution, commerce execution, arbitrary shell execution, or default filesystem writes. Era 6E.1 adds a transport-neutral governed MCP capability enablement path. It accepts text or object requests from any transport, parses the target capability_id, verifies Rubick capability and provider registration, classifies read-only versus mutating, commerce, and network authority, includes validation simulation when supplied, generates a Rubick/Lich/Zeus approval packet, and produces an enablement plan and receipt. Proposal is not enablement: unknown capabilities produce proposal-only refusals, and default requests remain dry_run=true, apply=false, approval_state=pending, and enablement_performed=false. Apply is allowed only for already registered, provider-backed, read-only capabilities with an approved packet, explicit apply=true, and explicit dry_run=false. The only mutation is a narrow governed MCP allowlist or registry-surface update. No Discord command, transport, model, or provider may bypass Rubick, Lich, and Zeus. Era 6E.2 adds transport-neutral MCP capability lifecycle governance in app/interoperability/mcp_lifecycle/. Lifecycle state changes are explicit, receipt-producing, evidence-backed, attributed to a requester, and bound to trust metadata and an approval packet. Unknown requesters, unknown lifecycle actions, missing approval, and invalid transitions fail closed. Dormancy governance is recommendation-only: AncientOS tracks last-use and count metadata, recommends human review after 90 days without successful execution, and never auto-disables a dormant capability. Operators may choose to keep enabled, suspend, deprecate, disable, or retire, but each actual state change requires human approval. Retired capabilities are archived rather than deleted so evidence, receipts, and governance history remain replayable. Era 6E.3 adds transport-neutral MCP capability portfolio governance in app/interoperability/mcp_portfolio/. It builds advisory portfolio health, risk, dormancy, review backlog, redundancy, recommendation, summary, and JSON snapshot reports from Rubick capability/export catalog data, lifecycle records, lifecycle observations, dormancy recommendations, and approval or evidence metadata where available. It requires no live telemetry. Portfolio governance answers aggregate questions about how many MCP capabilities exist, how many are enabled, disabled, retired, dormant, high risk, unreviewed, missing evidence, stale approval, promotion candidates, suspension candidates, deprecation candidates, disablement candidates, retirement candidates, or redundant. It is advisory only: it never invokes a provider, never adds an execution path, never depends on Discord or MCP transport, never mutates lifecycle state, and never auto-suspends, auto-disables, auto-deprecates, or auto-retires capabilities. All lifecycle state changes still require human approval through lifecycle governance. Mutating execution, commerce execution, arbitrary shell execution, network mutation, Docker/Git mutation, Keeper mutation, LifeVault mutation, Naga mutation, and Discord routing changes remain unavailable. Era 6F.1 adds app/interoperability/skill_registry/ as a first-class metadata layer above capabilities. The hierarchy becomes Skill -> Capability -> Provider -> Execution. Skills represent durable governed purposes such as host awareness, MCP governance, capability lifecycle governance, capability portfolio governance, and capability enablement governance. Capabilities remain Rubick-owned implementation units. Providers remain implementation metadata. Skill records map skills to capabilities, providers, dependencies, typed contracts, evidence requirements, validation requirements, unresolved bindings, reports, and advisory recommendations. This phase adds no MCP capabilities, no provider invocation, no execution path, no Rubick registry mutation, no Discord dependency, no automatic optimization, and no autonomous lifecycle transition. SkillOpt is relevant only as inspiration for reusable skill artifacts with evidence and validation gates. SkillOps-like practice is relevant only as inspiration for typed contracts and skill ecosystem graphs. Era 6F.2 adds app/interoperability/skill_intelligence/ as an advisory reasoning layer over skills. It produces health classifications, 0-100 fitness scores, overlap findings, gap analysis, strategic importance labels, recommendations, deterministic JSON snapshots, and human-readable reports. Health states include healthy, needs-review, weak, dormant, missing-capabilities, overlapping, high-risk, and unknown. Fitness bands are strong, adequate, weak, and poor. Strategic labels include foundational, operational, governance, integration, experimental, and deprecated. Recommendations may identify improvement, capability, binding, validation, overlap, promotion-candidate, deprecation-candidate, keep, review, and monitor signals, but they remain advisory only. SkillOpt informs fitness and recommendation concepts only; AncientOS still adds no autonomous optimization, promotion, deprecation, retirement, execution, provider invocation, Rubick mutation, lifecycle mutation, Discord dependency, or MCP transport dependency. Era 7A adds app/interoperability/conversational_intake/ as a deterministic conversational governance intake layer. It turns operator text or object input into structured governed proposals by classifying intent, mapping objectives, skills, and capabilities, selecting a governance path, identifying required authority, and recommending the next safe step. It is not a chatbot personality layer, not Discord wiring, and not autonomous execution. It makes no LLM calls and performs no provider invocation, MCP enablement apply, lifecycle mutation, objective mutation, automatic approval, hidden autonomy, or execution. Unknown and ambiguous requests fail closed with unknown_intent and a recommended clarifying question.

Future Strategic Direction

AncientOS should continue toward a multi-app continuity ecosystem. Apps request substrate capabilities through explicit contracts, own domain artifacts and workflows, inherit governance and auditability from AncientOS, and remain portable across providers and interfaces.

Future direction is advisory unless backed by validated runtime code, tests, and governed artifacts. Providers and executors should stay swappable. Interfaces and transports should remain replaceable. Assistant identities and personas must not be treated as the substrate itself.

The conceptual app lifecycle and capability-contract model is documented in AncientOS App And Component Boundary Model. That page is non-enforcing roadmap vocabulary unless or until runtime app registration, permission enforcement, and capability dispatch are implemented under separate governed work.

Roadmap Language Standard

To reduce ambiguity, AncientOS/Luna roadmap language is standardized as follows:

Term	Meaning
Era	A major strategic maturity band across the whole AncientOS/Luna system.
Layer	A durable architectural capability area.
Milestone	A validated completion point within a layer.
Work Package	A bounded implementation effort suitable for governed executor providers such as Codex, Tinker, or Roshan.
Phase	Deprecated for master-roadmap structure; use only inside local implementation plans when necessary.
Stage	Deprecated unless referring to external systems or historical documents.

The master roadmap should use Eras, Layers, Milestones, and Work Packages.

Strategic Commitments

AncientOS is being shaped around seven strategic commitments:

1. Personal AI continuity instead of vendor-, model-, or transport-bound identity.
2. Governed operational intelligence in service of trust, not generic autonomy.
3. Model-portable cognition instead of model-specific behavior.
4. Operational ergonomics through Oracle instead of infrastructure-only interaction.
5. Deterministic execution and artifact provenance instead of opaque agent action.
6. Permanent constitutional supervision through Zeus.
7. Investment-aware escalation governance through Underlord.

AncientOS's substrate identity must live in governance, operational doctrine, canonical artifacts, replayable state, deterministic boundaries, validation contracts, operational continuity, memory provenance, human-guided intent, and architectural constraints. Luna's identity is the Discord assistant app/interface over that substrate.

The LLM is a replaceable cognition engine behind governed inference roles. Frontier models are infrastructure, not identity. Transports are replaceable. Providers are replaceable. Continuity is the valuable layer.

Roadmap Status by Era

Era	Name	Status
Era 0	Runtime Foundation	Complete
Era 1	Standalone Subsystem Ecosystem	Complete
Era 2	Governed Artifact Control Plane	Complete
Era 3	Local Orchestration Substrate	Complete
Era 4	Live Integration Boundary Preparation	Complete
Era 5	Governed Live Execution Bridge	Active
Era 6	Memory, Retrieval, and Retention	Active
Era 6A	Interoperability Protocol Layer	Scaffolded, disabled by default
Era 7A	Conversational Governance Intake	Active foundation
Era 7	Oracle Operational Ergonomics And Situational Awareness	Active late-stage foundation
Era 8	Governed Coordination Cognition And Model-Portable Inference	Active foundation
Era 9	Proactive and Scheduled Governance	Future
Era 10	Personal Knowledge Ingestion	Future
Era 11	Governed Runtime Perception	Future
Era 12	Bounded Governed Operation	Long-term
Era 13	Zeus Constitutional Supervision	Planned
Era 14	Underlord Paid Escalation Governance	Planned

Core Architectural Layers

Deployment and Operations Layer

Purpose: Own AncientOS installation, onboarding, administration, device trust, identity binding, role authorization, policy locks, backup/restore, update lifecycle, configuration migration, multi-installation topology, and application lifecycle enforcement as platform continuity concerns.

This layer is bounded substrate infrastructure. It is not an app concern, not a transport concern, not a provider concern, and not model-owned administration. It exists because continuity trust must survive installation changes, device changes, administrative changes, update/restore events, configuration migrations, and future multi-installation operation.

Status: Planned doctrine only. Deployment and operations capabilities are not implemented unless backed by runtime code, tests, machine-readable manifests, governed artifacts, and evidence receipts.

Ownership boundaries:

• Rubick owns posture and configuration visibility for installation, deployment, operations, capability readiness, policy posture, application lifecycle state, and multi-installation topology. Rubick does not silently weaken policy, grant authority, or mutate administration state without the required governed path.
• Meepo validates continuity-sensitive transitions such as onboarding, configuration import, migration, restore, update apply, device trust change, role authorization change, policy-lock change, application lifecycle change, and multi-installation authority transfer before trust carries forward.
• Lich gates administrative approvals, break-glass operations, policy-lock changes, role changes, restore apply, update apply, and other meaningful administrative mutations.
• Oracle renders deployment posture, onboarding readiness, backup health, restore readiness, update readiness, policy-lock status, device trust status, role authorization posture, application lifecycle state, capability gaps, and multi-installation topology for human review. Oracle does not mutate, approve, repair, schedule, or administer.
• The capability ontology represents administrative capabilities, governance class, safety class, execution class, approval requirements, artifact requirements, degradation behavior, and provider bindings. It does not grant authority by making a capability visible.
• The runtime dispatches only approved administrative flows through explicit contracts. Runtime does not become a hidden administrator, policy authority, identity authority, update authority, or transport-owned administration surface.

Required future capability families include installation identity, onboarding, organization/workspace administration, device trust, role authorization, policy locks, configuration export/import, configuration migration, backup/restore, update lifecycle, installation topology, and application lifecycle management.

Continuity Posture Layer — Rubick

Present classification: Rubick is AncientOS continuity posture infrastructure: the operator-visible cognitive/governance surface and stable abstraction between the operator and changing AI infrastructure.

Rubick is not merely settings management, ontology middleware, or governance tooling. It governs continuity-safe posture across providers, models, transports, prompt profiles, execution modes, and future runtime architectures.

Rubick owns:

• posture and continuity settings
• ontology visibility
• cognitive modes
• prompt/profile portability
• runtime abstraction
• continuity-safe configuration
• operator introspection surfaces

Rubick should preserve controllable behavior when the surrounding infrastructure changes. A provider upgrade, model swap, transport migration, or prompt profile change should remain visible and governable through Rubick instead of silently changing the relationship.

Transition Integrity Layer — Meepo

Present classification: Meepo is AncientOS transition integrity infrastructure. It exists to preserve continuity trust across state changes by revalidating approved transitions and failing closed when assumptions drift.

Meepo is not generic middleware, orchestration, routing, planning, policy evaluation, or broad approval orchestration. It verifies that assumptions did not drift, approvals remain valid, context still matches, outputs remain bounded, execution remains inside approved scope, and continuity trust survives the transition.

Implemented lane:

• Rubick apply: settings changes create transition packets, bind approval ids, and revalidate before snapshot mutation.

Experimental or planned lanes:

• Roshan, Naga-Siren, and memory promotion adapters are scaffolded and experimental.
• Tinker integration is planned and should reuse the adapter pattern without expanding Meepo into orchestration.

Constitutional Supervision Layer — Zeus

Present classification: Zeus is an AncientOS core component for orchestration, routing, coordination intelligence, constitutional supervision, and bounded self-stabilization planning.

Zeus oversees constitutional coherence, governance integrity, roadmap alignment, planner quality, execution quality, subsystem degradation, doctrine drift, architectural compliance, and operational continuity.

Unlike Oracle, Zeus is not purely observational.

Validated present behavior remains advisory unless backed by specific runtime code, tests, and approvals. Future Zeus work may recommend improvements, create repair proposals, supervise quality, evaluate LegionCommander outputs, initiate governed improvement workflows, and make constrained changes through approved execution paths.

Zeus responsibilities: - constitutional supervision - governance coherence monitoring - doctrine drift detection - roadmap drift detection - planner quality oversight - system-quality enforcement - constrained repair proposals - bounded self-stabilization - emergency stabilization workflows - validation discipline enforcement - ongoing improvement recommendations

Zeus non-responsibilities: - unrestricted autonomy - hidden mutation - self-expansion of authority - bypassing Lich - bypassing Underlord - bypassing Oracle visibility - replacing human constitutional authority - direct unrestricted shell execution - unbounded recursive repair loops

Target operating pattern:

Zeus observes -> Zeus evaluates -> Zeus proposes -> human reviews -> governed approval / Underlord gates -> Kunkka/Roshan/Tinker executor lanes act only if approved -> Oracle surfaces outcome.

Codex is a temporary external executor provider behind governed contracts. Zeus is a permanent AncientOS core component.

Investment Governance Layer — Underlord

Present classification: Underlord is AncientOS's investment-aware escalation and paid-intelligence approval gate.

Underlord governs whether paid or externally metered intelligence intervention is justified, bounded, valuable, and safe.

Underlord applies when Zeus/Grok escalation, paid external models, external metered tooling, or cost-bearing intelligence intervention is proposed.

Underlord responsibilities: - require local AncientOS/Luna-first attempts where practical - require escalation justification - estimate token usage - estimate cost range - define maximum approved spend - define bounded scope - define allowed and forbidden actions - require rollback plans - require validation plans - record approval evidence - fail closed when scope or cost is unclear

Underlord non-responsibilities: - ordinary no-cost AncientOS/Luna approvals - replacing Lich governance - executing work directly - hiding cost from the operator - permitting open-ended spend

Underlord doctrine: Paid intelligence is an escalation resource, not the default runtime.

Governance Layer — Lich

Present classification: Lich names current runtime governance, approval, and confirmation language. This is the current validated documentation meaning.

Future speculative context: Some earlier taxonomy drafts used Lich as an archival memory / cold-storage candidate. That meaning is not present runtime truth. It may be revisited only as a future role split or mechanical rename proposal with explicit migration notes, compatibility handling, and validation.

Ensure meaningful action remains approval-mediated, policy-aware, auditable, and fail-closed.

Deterministic Execution Layer — Kunkka / Roshan

Present classification: Ensure mutations remain bounded, replayable, inspectable, and validation-aware.

Migration context: Kunkka currently appears in deterministic patch/mutation language and in future navigation/workflow routing candidate language. These meanings must not be collapsed. Future docs should either preserve the historical mutation context or explicitly mark navigation/routing language as speculative role evolution.

Orchestration Layer — Keeper / LegionCommander

Present classification: Coordinate plans, workflows, tasks, and bounded execution proposals without hidden autonomy.

Taxonomy note: Keeper is now classified as the AncientOS objective/task coordination kernel service. Keeper Console is the application/UI over Keeper. Historical memory-management or preservation wording should be treated as legacy context unless it is explicitly routed through LifeVault doctrine.

Operational Ergonomics Layer — Oracle

Present classification: Make AncientOS/Luna understandable and operable by humans.

Oracle interprets AncientOS operational state for humans. Oracle does not execute AncientOS or apps.

Late-stage role: Oracle maintains bounded, evidence-backed situational awareness across topology, dependencies, governance boundaries, readiness drift, replay continuity, degradation lineage, operational narrative continuity, bottlenecks, and stable state comparison. Operational awareness is not authority.

Governed Architectural Awareness Layer

Purpose: Give AncientOS bounded architectural self-awareness without autonomy.

The layer answers questions about verified capabilities, completed roadmap eras, recent milestones, dependency readiness, subsystem boundaries, governance layers, Discord coupling, recent architectural changes, and unresolved debt.

Semantics: - capability claims require evidence from runtime code or tests - docs are derived evidence, not authority by themselves - roadmap cognition cannot complete or mutate roadmap state - dependency reasoning is deterministic and read-only - drift detection emits warnings only - next-step synthesis is advisory-only and has no execution authority

This layer supports Oracle-style legibility while preserving human-governed operation. It is not a hidden planner, scheduler, executor, or approval path.

Memory and Retrieval Layer

Purpose: Provide durable contextual continuity without direct memory-to-behavior mutation.

Current governed runtime continuity: - Runtime Cognitive State stores bounded operational facts such as active objective, unresolved clarification, pending intent, last route decision, current bounded scope, route confidence, clarification confidence, and last safe suggested next step. - It is channel/user/session scoped, transport-neutral, inspectable, and explicitly expiring. - It supports plain-English inspection such as "What are we doing?", "What's pending?", and "What did I ask you to do?" - It supports clarification continuity without retaining conversation logs. - It allows "proceed" only when exactly one safe pending continuation exists; otherwise Luna clarifies. - It does not store secrets, Discord objects, unbounded transcripts, or inferred private preferences. - It does not bypass Lich, TrollWarlord, Oracle, Keeper, Roshan, Kunkka, governance preview, or confirmation gates.

Model-Portable Inference Layer

Purpose: Prevent AncientOS/Luna from becoming dependent on one model's quirks.

Doctrine: LLMs are replaceable cognition engines behind governed inference roles.

Direction: - centralize inference through luna-inference - define named inference roles - prefer one resident primary model for RAM efficiency - keep fallback models policy-controlled - log model usage and fallback events - evaluate models against AncientOS/Luna contracts - avoid subsystem-owned model selection

Current governed role surface: - app/inference/contracts.py defines transport-neutral inference requests and responses - app/inference/client.py calls luna-inference with fail-closed text behavior and explicitly degraded embedding behavior - app/inference/policy.py constrains roles, tiers, structured outputs, embedding roles, and forbidden uses - app/inference/roles.py defines governed role metadata for conversational reply, Oracle synthesis, operational narration, architecture summary, coordination analysis, route explanation, draft generation, bounded reasoning, memory fact extraction, retrieval query embedding, architecture evidence embedding, and compatibility roles - app/inference/providers.py defines local Ollama/luna-inference, OpenAI-compatible, Anthropic-compatible, and disabled provider contracts without requiring live credentials - app/inference/arbitration.py performs deterministic local-first provider selection from role policy, readiness, structured-output needs, cost policy, fallback eligibility, degradation state, and Underlord approval metadata - app/inference/lineage.py records replay-safe provider-selection lineage without prompts, outputs, or secrets - app/inference/observability.py exposes Oracle-readable provider readiness, role readiness, degraded roles, fallback events, blocked paid escalation, provider-overreach warnings, and model usage lineage - docs/inference_doctrine.md and docs/machine/inference-roles.json document the human and machine-readable inference substrate contract

Model and embedding output remain advisory. They cannot approve, execute, mutate, bypass governance, expand runtime authority, or replace deterministic routing. Retrieval prepared by embeddings is evidence, not authority. Paid frontier models require explicit Underlord approval metadata or a bounded no-approval budget; silent paid fallback and open-ended spend are forbidden.

Current State by Subsystem

luna-interop

Status: Mature governed control plane.

Kunkka

Status: Implemented and validated.

Roshan

Status: Implemented bounded dangerous-execution lane.

discord-luna

Status: Runtime-kernel-backed adapter shell with bounded session context.

Current structure: - app/runtime/kernel.py owns message-processing order. - app/runtime/pipeline.py defines governed preemption, explicit command compatibility, plain-English operational routing, governance interception, Keeper, confirmation, and fallback stages. - app/runtime/discord_adapter.py converts Discord messages into runtime envelopes and renders returned payloads. - app/architecture/* handles architectural inspection requests as informational reports. - app/bot.py remains lifecycle and event ingress only.

Doctrine: Ambiguous operational requests clarify before action. Discord-owned cognition is an anti-pattern; all transport-neutral routing belongs in the AncientOS runtime kernel. The discord-luna name is historical and is not changed by this taxonomy update.

luna-skills

Status: Governance-aware operational skill library implemented.

luna-inference

Status: Implemented local inference gateway.

Direction: Eligible chat, task-intent classification, structured fact-extraction, and memory fact embedding calls now route through governed inference roles. Missing embedding service state is explicit degradation; callers must not silently fall back to direct backend embedding calls.

Remaining retrieval and memory debt: - migrate additional retrieval query paths to retrieval_query_embedding - ensure architecture evidence indexing uses architecture_evidence_embedding - keep retrieval results as evidence inputs, never execution or mutation authority

Oracle / luna-oracle

Status: Standalone read-only service surface implemented.

Current shape: - app/oracle/service.py answers bounded operator visibility questions. - app/oracle/evidence_loader.py consumes Governed Architectural Awareness evidence. - app/oracle/synthesis.py separates verified facts, inferred readiness, warnings, and advisory recommendations. - app/oracle/policy.py forbids execution, mutation, approval, background loops, and automatic drift reconciliation.

Remaining direction: Add canonical state readers, dashboard summaries, and external service packaging without expanding authority.

Zeus / zeus-supervisor

Status: Planned permanent constitutional supervision subsystem.

Direction: Remain continuously active as AncientOS's constitutional supervisor.

Underlord / escalation-governor

Status: Planned investment-aware escalation gate.

Direction: Govern all paid or externally metered intelligence intervention.

Era 5 — Governed Live Execution Bridge

Goal: Expand governed patch execution toward reviewed multi-operation workflows while preserving deterministic safety and governance visibility.

Era 6 — Memory, Retrieval, and Retention

Goal: Build durable contextual continuity without direct runtime mutation from retrieval.

Invariant: Canonical artifacts remain authoritative.

Era 6.5 — Governed Capability Cognition

Goal: Introduce a governed semantic capability ontology that allows planners, governance, memory, evaluators, simulation systems, and executor lanes to reason about shared operational primitives. Invariant: All capability resolution remains policy-constrained, inspectable, replay-safe, artifact-backed, and fail-closed. Direction: Establish canonical capability registries, manifests, dependency graphs, governance classifications, and evidence contracts without introducing autonomous capability synthesis or unrestricted execution routing.

Era 6A: Interoperability Protocol Layer

Purpose: make AncientOS ready for emerging AI-agent interoperability protocols without letting external standards bypass AncientOS governance. MCP is treated as a tool/context interoperability layer. UCP is treated as a future commerce-intent layer. Rubick remains the capability authority, Lich remains the approval authority, and Zeus remains the evidence/supervision authority.

6A.1 MCP capability export

Expose selected Rubick capabilities as MCP-compatible descriptors. This is descriptor/export only. It does not add execution authority, network calls, or transport coupling.

Initial descriptor candidates:

• inspect_disk_space
• inspect_runtime_hardware_summary
• keeper_list_tasks
• lifevault_search

Current real governed MCP capability:

• inspect_disk_space

6A.2 MCP inbound provider registry

Allow future external MCP servers to be represented as Rubick provider stubs. All inbound providers are disabled by default, untrusted by default, and require explicit governance review before use.

6A.3 MCP governance bridge

Map MCP requests into AncientOS capability requests with risk classification, approval requirements, replay boundaries, and evidence artifacts. MCP must never route directly to execution.

6A.4 UCP commerce substrate placeholder

Add model-only structures for future commerce workflows such as merchants, offers, carts, checkout sessions, payment intents, orders, and returns. UCP support is non-executing until a later approved phase. No checkout, payment, or purchase authority is added in Era 6A.

6A.5 Rubick MCP Export Bridge

Status: complete.

Produce descriptor-only MCP tool catalogs from Rubick capability and provider records. Export policy fails closed by default, generated descriptors carry AncientOS governance annotations, and execution/network flags remain false. The catalog/report layer is read-only operator visibility for future server work, not a routing or invocation surface.

6A.6 Read-only MCP Server

Status: not started.

A future phase may expose the descriptor catalog through a live read-only MCP server after separate review of transport, registration, supervision, and governance-bridge requirements. Era 6A.5 does not start a server, open sockets, register external providers, or execute MCP tools.

Era 6A invariants

• Rubick remains the source of truth for capability registration.
• Lich approval is required for any future mutating or commerce action.
• Zeus evidence artifacts are required before any future governed execution.
• MCP/UCP inputs are untrusted by default.
• External providers are disabled by default.
• Advisory metadata from MCP or UCP cannot influence routing, memory, approval, or execution authority.
• No network calls, purchases, payments, or live protocol servers are introduced in this era.
• Transport neutrality is preserved.
• Fail-closed behavior is preserved.

Era 6B: Governed MCP Read-Only Execution Lane

Purpose: extend the MCP path from discovery, authorization, approval packet, and execution plan into a narrow governed read-only execution lane that produces an evidence receipt.

Status: implemented as an opt-in, default-disabled facade.

Execution setting:

• mcp_read_only_execution_enabled
• Default: false
• When false: tools/call keeps the discovery-only refusal behavior.
• When true: only the allowlisted governed read-only lane can execute.

Current executable MCP capability:

• inspect_disk_space

Lifecycle:

Discovery -> Authorization -> Approval Packet -> Execution Plan
-> Invocation Candidate -> Lich Gate -> Zeus Evidence Gate
-> Read-Only Executor Facade -> MCP Execution Receipt

Implemented layers:

• Invocation candidate resolution in app/interoperability/mcp_invocation/.
• Lich approval gate adapter in app/interoperability/mcp_lich_gate/.
• Zeus evidence gate and receipt models in app/interoperability/mcp_zeus_gate/.
• Read-only executor facade and provider allowlist in app/interoperability/mcp_execution/.
• tools/call wiring through the governed lane when explicitly enabled.
• Operator visibility for discoverable, executable, and blocked MCP tools.

Era 6B invariants:

• Candidate resolution never executes providers.
• Unknown, mutating, commerce, unregistered, unsupported, or incomplete requests fail closed.
• Approval metadata alone is not execution permission.
• Zeus evidence is required before provider invocation.
• Receipts explicitly report mutation_performed = false and network_performed = false.
• No direct MCP server calls into Rubick execution, Beastmaster, shell, Docker, Git, Keeper, LifeVault, Naga, Discord routing, network providers, or UCP/commerce providers.
• Mutating execution remains unavailable.
• UCP and commerce execution remain unavailable.

Era 6D.2: MCP Operator Validation Harness

Purpose: Give operators and developers a local way to inspect the complete governed MCP packet chain without adding authority.

Status: implemented.

Package:

• app/interoperability/mcp_validation_harness/

CLI:

python -m app.interoperability.mcp_validation_harness.cli --list-scenarios
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_default_disabled_refusal
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_success_path_with_fake_provider --json
python -m app.interoperability.mcp_validation_harness.cli --scenario inspect_disk_space_success_path_with_real_provider --allow-real-provider

The harness reports discovery output, requester identity, session context, intent, trust, authority scopes, authorization decision, approval packet, execution plan, invocation candidate, Lich gate result, Zeus evidence result, execution result or structured refusal, receipt summary, provider invocation status, mutation/network flags, and sanitized result data.

Default execution is fake-provider only. The real Beastmaster disk_overview provider scenario requires explicit opt-in. The harness does not add capability #2, does not mutate by default, does not call Discord, does not start HTTP transport, does not perform commerce or mutating execution, and does not bypass the governed MCP lane.

Era 7 — Oracle Operational Ergonomics And Situational Awareness

Goal: Translate AncientOS distributed state into human-legible operational awareness and maintain coherent, bounded, governance-aware situational understanding.

Late-stage implementation: - Canonical operational topology graph for subsystems, providers, transports, capability domains, governance domains, execution lanes, and dependency classes. - Deterministic temporal reconstruction from supplied operational snapshots, including degradation lineage, capability/provider state transitions, governance-event lineage, validation history, and replay continuity. - Dependency-aware readiness propagation with explainable provider, replay, governance-boundary, validation, and execution-lane paths. - Formal constitutional risk surface for transport-cognition leakage, provider-authority drift, autonomy creep, governance bypass risk, replayability violations, capability-contract violations, hidden-state accumulation, unsafe dependency coupling, authority-boundary erosion, and deterministic-boundary violations. - Bounded bottleneck synthesis and safe next inspection recommendations only. - Stable-state comparison and readiness drift surfaces over replay-safe baselines. - Zeus advisory hooks with no execution coupling and no authority transfer.

Era 8 — Model-Portable Inference

Goal: Realign all LLM usage into one governed inference substrate.

Decision: Use one preferred resident model operationally while remaining architecturally model-portable.

Era 9 — Proactive and Scheduled Governance

Goal: Add time-aware governance without hidden autonomy.

Era 10 — Personal Knowledge Ingestion

Goal: Import personal and operational data into governed local artifacts.

Era 11 — Governed Runtime Perception

Goal: Provide bounded live observability without autonomous remediation.

Constraint: Runtime perception must not become runtime authority.

Era 12 — Bounded Governed Operation

Goal: Allow bounded work under governance where policies, rollback paths, validation contracts, and constitutional supervision are mature.

This is not unrestricted autonomy.

Deployment, Administration, and Operational Continuity

Purpose: Add a bounded platform-level deployment and operations roadmap area before broader bounded operation depends on administrative assumptions. This section preserves the existing era sequence; it does not renumber current roadmap eras.

Status: Planned doctrine for human review. These capabilities are not implemented unless backed by runtime code, tests, machine-readable manifests, governed artifacts, and evidence receipts. Documentation alone is not authority.

Milestones:

• Installation identity and first-run onboarding doctrine, including installation id, creation provenance, operator binding, trust-root metadata, bootstrap checks, secret initialization boundaries, environment validation, and recovery paths.
• Organization and workspace administration model for future multi-operator or delegated-operation contexts without converting AncientOS into an enterprise administration product.
• Platform administrator and role authorization model that maps requesters, roles, installations, devices, workspaces, policy scopes, and capability requests before capability-specific safety evaluation occurs.
• Device trust registry and revocation doctrine covering enrollment, trust level, last validation, rotation, revocation, retirement, and degraded-device capability restrictions.
• Policy lock artifacts and drift detection describing who set each lock, what it protects, what evidence can unlock it, what provenance is required, and what must fail closed when lock integrity is uncertain.
• Update lifecycle doctrine covering preview, release channel, compatibility validation, apply receipt, rollback path, and explicit prohibition on silent changes to local policy, posture, identity, memory authority, or capability enablement.
• Configuration export/import, schema migration, cross-version compatibility, migration receipts, and Meepo validation before continuity trust carries forward.
• Backup manifest, backup creation, restore preview, restore apply, restore receipt, restore validation, secret-handling boundaries, and replay continuity checks.
• Multi-installation operation covering topology visibility, primary and secondary installations, replication boundaries, conflict handling, stale node behavior, human-approved authority selection, and Meepo-validated authority transfer.
• Application lifecycle management covering declared, configured, validated, approved, invoked, supervised, audited, suspended, deprecated, retired, and archived application states once runtime registration, manifest loading, permission enforcement, and capability dispatch exist.
• Oracle deployment and operations posture reports for readiness, gaps, backup/restore health, update readiness, device trust, policy locks, application lifecycle state, and multi-installation topology.
• Oracle capability-gap follow-up as future advisory document generation: Oracle may later draft proposal documents from evidence-backed summaries under explicit non-mutation guarantees and human review, but Oracle must not amend the roadmap or administer the system directly.

Administrative capability visibility is not authority. Any mutation-capable deployment or operations workflow must be approval-gated, evidence-backed, replayable where possible, policy-locked where required, Meepo-validated where continuity trust changes, and fail-closed when scope or authority is ambiguous.

Era 13 — Zeus Constitutional Supervision

Goal: Establish Zeus as AncientOS's permanent constitutional supervisor and coordination intelligence core component.

Zeus ongoing improvement mandate:

Zeus may continuously inspect roadmap alignment, governance posture, subsystem quality, planner quality, memory posture, inference posture, operational ergonomics, and execution reliability.

Zeus may produce improvement recommendations, roadmap drift reports, constitutional drift warnings, repair proposals, governance hardening recommendations, and proposed work packages.

Zeus may not directly deploy changes outside governed execution paths.

Era 14 — Underlord Paid Escalation Governance

Goal: Create an investment-aware approval gate for paid or externally metered intelligence escalation.

Default path:

local AncientOS/Luna reasoning -> local AncientOS/Luna proposal -> governed AncientOS execution

Escalation path:

local AncientOS/Luna insufficiency -> Zeus review -> Underlord proposal -> human approval -> bounded paid intervention -> validation -> Oracle visibility

Underlord must fail closed when cost cannot be estimated, scope is unclear, rollback is missing, validation is missing, authority is ambiguous, or spend is open-ended.

Core Architectural Principles

These principles restate the constitutional doctrine in implementation-facing language. They are not separate authority grants.

Principle	Deterministic interpretation
deterministic-first	Prefer explicit contracts, registries, stable ordering, and replayable reports over heuristic action.
artifact-driven	Durable claims require inspectable artifacts, evidence, or test/runtime references.
governance-gated	Meaningful action requires the appropriate approval, policy, and validation path.
replayable	Decisions should be reconstructable without executing mutations.
inspectable	Operators and Oracle-visible surfaces should expose evidence, boundaries, and uncertainty.
versioned	Schemas, manifests, migrations, and durable artifacts should carry version context.
offline-safe	Local operation should fail closed when external providers are absent.
transport-neutral	Discord, CLI, Web, Android, and future clients must not own cognition or authority.
provider-neutral	Models, APIs, and executor providers are swappable surfaces behind governed contracts.
fail-closed	Unknown scope, missing evidence, degraded providers, and ambiguous authority deny or clarify.
model-portable	LLMs are replaceable cognition engines behind governed inference roles.
human-governed	Humans remain constitutional authority for meaningful action and authority expansion.
operationally legible	Oracle and related reports make state understandable without granting execution power.
constitutionally supervised	Zeus supervision remains bounded by doctrine and approval paths.
investment-aware	Paid escalation requires Underlord scope, cost, validation, and approval evidence.

Anti-Goals

Do not introduce: - uncontrolled recursion - opaque agent loops - hidden prompt magic - unbounded mutation authority - hidden admin authority - model-owned administration - transport-owned administration - direct memory mutation from retrieval - Discord-owned execution logic - hidden Zeus mutation - Zeus authority self-expansion - automatic policy weakening - silent update behavior that changes local policy - paid escalation without Underlord approval - open-ended external token spend - governance bypass ergonomics - unrestricted shell execution

Immediate Priority Order

1. Add Oracle canonical state readers and dashboard summaries.
2. Migrate remaining retrieval callers onto governed embedding roles.
3. Route LegionCommander through governed inference roles.
4. Define Zeus constitutional supervision boundaries.
5. Define Zeus ongoing improvement cadence.
6. Define Underlord escalation approval schema.
7. Expand governed multi-file patch workflows.
8. Continue memory and retention evolution.
9. Add runtime perception only after Oracle visibility stabilizes.

Pending Work Packages

Work Package 1 — Build Oracle

Create standalone luna-oracle operational ergonomics service.

Primary outcome: Human-legible operational visibility.

Status: Service surface implemented in-process as app/oracle/*; external dashboard and service packaging remain future work.

Work Package 2 — Model Role Realignment

Move scattered model usage behind luna-inference role routing.

Primary outcome: Model-portable AncientOS/Luna cognition.

Status: Governed role contracts and the primary chat, task-intent, and fact-extraction client paths are implemented. Remaining direct model-call debt is memory embedding traffic.

Work Package 3 — Governed Multi-File Patch Workflows

Expand governed patch execution toward larger bounded workflows.

Primary outcome: Larger governed operational changes with deterministic safety.

Work Package 4 — Zeus Constitutional Supervision

Implement Zeus as AncientOS's permanent constitutional supervisor and coordination intelligence core component.

Primary outcome: Permanent governed quality supervision and bounded self-stabilization.

Work Package 5 — Underlord Paid Escalation Governance

Implement Underlord as AncientOS's investment-aware escalation gate.

Primary outcome: Paid intelligence becomes bounded, cost-visible, and approval-mediated.

AncientOS / Luna Constitutional Doctrine

These principles supersede implementation convenience, model preference, or short-term capability gains.

AncientOS Is

AncientOS is a transport-neutral, provider-neutral governed cognition kernel for personal AI continuity. It preserves the operator's long-term AI relationship, memory, trust, identity, reasoning style, operational alignment, and governance posture across changing models, providers, transports, hardware, and runtime locations.

AncientOS also includes governed operational cognition services, a deterministic execution environment, a replayable operational memory system, a governance-mediated coordination framework, a bounded operational reasoning environment, and constitutional coordination surfaces. Those are supporting architectural concepts, not replacements for the continuity thesis.

AncientOS is not defined by any single model, interface, transport, executor, orchestration strategy, memory backend, or dashboard.

Luna Is

Luna is the interactive assistant/personality and interface layer over AncientOS. Luna may present assistant behavior, operator interaction, transport rendering, and persona/interface continuity, but it is not the kernel, authority source, OS layer, or whole ecosystem.

Human Authority

Humans remain AncientOS's constitutional authority.

AncientOS apps such as Luna may interpret, summarize, plan, simulate, propose, validate, organize, and surface operational insight.

AncientOS and apps running on it must not silently escalate authority, self-authorize execution, conceal operational state, rewrite constitutional boundaries, or recursively self-expand authority.

Governance is a core architectural feature.

Operational Truth

Operational truth must remain inspectable, replayable, attributable, provenance-aware, bounded, and evidence-linked.

Canonical artifacts remain authoritative.

Model Doctrine

LLMs are replaceable cognition engines.

AncientOS must remain model-portable, inference-abstracted, governance-first, and architecture-centered.

No subsystem should become dependent on one model’s quirks.

Model and provider abstraction exists so continuity survives infrastructure change. A frontier model may improve a task, but it is not Luna's identity and not AncientOS's source of truth.

Portability Doctrine

AncientOS must preserve continuity when any outer layer changes:

• model: local, frontier, or future provider
• provider: OpenAI, Anthropic, Ollama, local gateways, or later backends
• transport: Discord, CLI, web, mobile, desktop, or future interfaces
• host: SER6BUZZ, another machine, container layout, or later runtime location
• memory backend: file artifacts, pgvector, or future storage surfaces
• execution provider: Codex, Tinker, Roshan, or future bounded lanes

The portable layer is not just data export. It includes memory provenance, operator trust boundaries, reasoning style, identity continuity, governance state, audit history, and bounded operational context.

Oracle Doctrine

Oracle exists as an AncientOS core component for operational awareness and state interpretation. It makes AncientOS/Luna operationally legible.

Oracle may interpret, synthesize, narrate, explain, warn, surface drift, analyze readiness, analyze dependencies, reconstruct operational history, and propose safe next inspections.

Oracle must never become a hidden executive authority, an ungoverned planner, a governance bypass layer, a runtime-owned authority source, an automatic repair loop, an unrestricted orchestrator, or a background cognition loop.

Zeus Doctrine

Zeus exists as an AncientOS core component for orchestration, routing, coordination intelligence, and constitutional integrity.

Zeus may inspect system state, evaluate governance coherence, evaluate planner quality, recommend improvements, initiate governed improvement workflows, produce repair proposals, and eventually make constrained changes through approved execution paths.

Zeus must not self-expand authority, mutate silently, bypass Lich, bypass Underlord, bypass Oracle visibility, conceal costs, or replace human constitutional authority.

Zeus may remain permanently active. Paid Grok intervention may not remain permanently spending.

Underlord Doctrine

Underlord is AncientOS's investment-aware escalation gate.

Underlord evaluates safety, governance, scope, expected value, estimated cost, spend ceilings, rollback readiness, validation readiness, and whether local alternatives were attempted first.

Approval must record approved spend ceiling, approved scope, approved executor, expiration window, validation requirements, and rollback requirements.

Underlord must fail closed when cost cannot be estimated, scope is vague, rollback is missing, validation is missing, or executor authority is ambiguous.

Execution Doctrine

Execution must remain bounded, reviewable, replayable, artifact-backed, policy-gated, rollback-capable, and fail-closed under uncertainty.

Safe execution is achieved through governance, deterministic boundaries, explicit authority, operational visibility, and validation contracts, not through hidden prompt behavior.

Runtime Decomposition Doctrine

Discord is a transport edge, not the owner of AncientOS operational cognition. app/bot.py should remain an ingress and rendering shell while transport-neutral modules own contracts, observability, governed preemption, governance preview interception, operational routing, confirmation lifecycle, Keeper surfaces, and conversational fallback.

Plain English is the operator interface. Operators should be able to ask Luna to plan, delegate read-only inspection, list confirmations, approve a deterministic pending confirmation, show task state, or ask what to do next without memorizing exact command syntax. Exact commands remain supported as compatibility paths.

Clarification-before-action is a permanent safety rule. If target, scope, action, validation evidence, or approval context is ambiguous, Luna must ask a clarifying question or fail closed according to the governed subsystem rules. Ambiguous requests must not be converted into default execution.

Authority ownership table:

Authority	Owner
Commit normalization and replay-safe commit execution	TrollWarlord plus governed preemption
Approval and confirmation gates	Current Lich governance language plus confirmation lifecycle
Dangerous-operation validation	Roshan
Patch artifact mutation	Current Kunkka mutation language
Planning and proposal generation	LegionCommander
Task continuity	Current Keeper task/workflow surfaces
Memory management and preservation workflow	Keeper app/workflow
Visibility and synthesis	Oracle
Constitutional supervision	Zeus
Paid or externally metered escalation approval	Underlord

Roadmap anti-patterns to continue removing:

• Discord code making cross-domain execution decisions.
• Natural-language parser broadening that makes random feed text executable.
• Governance-preview bypass before planner/delegate collapse.
• Confirmation approval without a deterministic pending target.
• Runtime identity or audit traces polluted by stale backup files.

Long-Term Direction

The long-term direction of AncientOS/Luna is not unrestricted autonomy.

The long-term direction is portable personal AI continuity: durable memory, operator trust, stable reasoning style, model-portable cognition, transport independence, operational self-legibility, trustworthy bounded execution, governance-native orchestration, constitutional supervision, investment-aware escalation, and human-centered coordination intelligence.

AncientOS should become increasingly understandable, inspectable, resilient, composable, operationally coherent, safe to extend, safe to recover, and safe to govern without becoming opaque, self-authorizing, or operationally unbounded. Luna should remain a governed Discord assistant interface over that substrate.

Era 6F.3 / 6G.1 Validation Milestone

Era 6F.3 adds a local Skill Intelligence Validation Harness. It validates skill ecosystem reasoning with deterministic scenarios for listing skills, host awareness health and fitness, MCP governance health, overlap reports, gap reports, recommendations, missing capability bindings, dormant capability coverage, and skills with no implemented capabilities. The harness is advisory-only and performs no execution, provider invocation, lifecycle mutation, capability mutation, automatic optimization, promotion, deprecation, or retirement.

Era 6G.1 adds a local MCP Client Compatibility Harness. It validates MCP-client-shaped transcripts for generic MCP, Claude Desktop-shaped, Cursor-shaped, VS Code-shaped, and OpenAI MCP-shaped profiles without live external client installation, launches, credentials, external auth, public HTTP transport, or network calls. Compatibility covers initialize, tools/list, resources/list, prompts/list, deterministic refusals, and the existing governed inspect_disk_space success transcript. Live external client validation remains a future separate track.

Strategic Summary

The next major challenge is operational coherence.

Oracle addresses operational legibility. Zeus addresses permanent constitutional supervision. Underlord addresses investment-aware escalation governance. Model-portable inference addresses model dependence. Governed execution addresses safe action.

Together, these directions move AncientOS/Luna toward a durable governed continuity layer rather than a brittle agent stack or enterprise governance clone.