Canonical Terminology

This page defines the current AncientOS/Luna vocabulary and architecture boundaries. It is the preferred reference when docs, plans, or implementation notes need to name roles, lanes, kernel services, applications/workflows, transports, providers, and external tools consistently.

The canonical Objective to Loop lifecycle and its authority boundaries live in Governance Kernel. This terminology page defines names; the Governance Kernel defines lifecycle authority.

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

The canonical application-platform epoch is AncientOS v3 Architecture. v3 defines Chen as the application framework and the layered model: Kernel governs -> Chen orchestrates -> Domains implement.

This is a conceptual taxonomy update, not a code-level rename. Existing repo names, service names, Python modules, Docker services, environment variables, API paths, database paths, commands, and imports may still use historical Luna names until a future mechanical rename phase is explicitly approved.

Core Definitions

Term	Canonical meaning
AncientOS	The transport-neutral, provider-neutral governed cognition kernel for personal AI continuity. AncientOS preserves memory, trust, identity, governance, operational alignment, reasoning style, and cognitive relationship across changing models, providers, transports, hardware, and runtime locations. It owns transport-neutral runtime boundaries, governance gates, artifact-backed state, deterministic routing, capability/provider contracts, and fail-closed execution posture.
AncientOS v1	The governed-kernel epoch: semantic routing, kernel records, transport neutrality, and the initial Oracle, Rubick, and Lich foundations.
AncientOS v2	The visibility and explainability epoch: operational awareness, Oracle visibility, Beastmaster host awareness, Rubick capability reasoning, knowledge surfaces, and read-only cognition.
AncientOS v3	The application-platform epoch: Chen application framework, domain manifests, domain registry visibility, Oracle/Rubick app visibility, Media Manager as the first Chen domain, external adapters, and Lich-gated mutation.
Luna	The current interactive cognition/personality and interface layer over the AncientOS kernel. Luna is the operator-facing assistant surface, not the kernel, authority source, OS layer, or whole ecosystem.
Semantic Router	The intent classification and routing layer that maps operator text to the correct advisory, governance, Chen/domain, tool, or fallback surface. It classifies and routes; it does not own governance, approval, domain truth, or execution.
Kernel	The AncientOS governance and platform substrate. It governs, routes, records, enforces policy, maintains audit/replay boundaries, exposes universal platform capabilities, and keeps capability visibility separate from authority.
Chen	The AncientOS app-layer workflow orchestration framework. Chen coordinates capabilities, plans multi-step app/domain flows, delegates to Rubick, Oracle, Lich, Tinker, and domain adapters, and does not own kernel governance.
Domains	Domain-specific implementation packages behind Chen or another governed app surface. Examples include Media, Home, Infrastructure, Finance, Publishing, and Knowledge. Domains implement subject logic; they do not become kernel services.
Media Manager	Chen's first active domain implementation. Media Manager is the plain-English description for the media domain currently retained at app/media_manager for compatibility. It includes read-only resolution, acquisition brokerage, approval-packet planning, and the first tightly bounded approved mutation: paused qBittorrent dispatch. Import, file movement, Plex refresh, playback, and broader migration actions still require future approval-gated slices.
Naga-Siren	A governed workflow application/package running on AncientOS. Naga-Siren owns Naga-specific workflow semantics while using AncientOS kernel primitives and adapter contracts.
X-feed-worker	An application/service workflow or adapter-facing service, not a kernel service unless later adopted under an explicit AncientOS contract.
Discord	A transport layer and rendering adapter. Discord receives events and displays responses, but it does not own cognition, planning, routing, governance, or execution semantics.
discord-luna	The current repository containing Luna interface/runtime compatibility code and historically named AncientOS kernel code. The repository name is not being changed by this taxonomy update.
MCP	Model Context Protocol, an external tool/context interoperability protocol. MCP metadata is not AncientOS authority and cannot bypass Rubick registration, Lich approval classification, Zeus evidence, or replay boundaries.
UCP	Universal Commerce Protocol, an external agentic commerce protocol. Current AncientOS support is model-only and does not add checkout, payment, purchasing, or merchant mutation authority.
MCP Provider	An untrusted external provider until registered through Rubick and classified through governance. MCP providers are disabled by default and cannot route directly to execution.
UCP Commerce Intent	A non-executing commerce representation requiring human approval before any future transaction or mutating commerce action.
Runtime Kernel	The transport-neutral AncientOS kernel service for message-processing order, deterministic routing, governed preemption, clarification, and fallback sequencing. Existing code names may still say Luna Runtime Kernel until a future mechanical rename.
Codex	An executor provider candidate used behind governed contracts. Codex is not Luna's or AncientOS's identity, authority source, or required execution substrate.
Rubick	AncientOS continuity, capability, repository, and relationship reasoning infrastructure. Rubick is the operator-visible cognitive/governance surface and governed continuity control plane for posture, continuity settings, ontology visibility, cognitive modes, prompt/profile portability, runtime abstraction, capability descriptors, repository reasoning, and knowledge graph scaffolding.
Keeper	AncientOS objective and task coordination service. Keeper owns governed objectives, task state, planning records, preflight context, blockers, and next-review needs after Lich gates allow objective coordination. Keeper Console is an application/UI over Keeper; Keeper itself is a kernel service.
Beastmaster	AncientOS host and runtime awareness service. Beastmaster observes supplied or approved runtime, host, Docker, storage, memory, and load evidence. It does not own repository reasoning, execution approval, or Oracle synthesis.
Meepo	AncientOS transition integrity infrastructure. Meepo revalidates approved state transitions so assumptions, approvals, context, output bounds, and execution scope still match before trust is carried forward.
LifeVault	AncientOS logical memory continuity layer. LifeVault owns durable memory authority, promotion state, review provenance, supersession/deprecation status, archive lifecycle, and retrieval eligibility independently of storage backends.
Objective Intake Resolver	A read-only advisory assessment component for objective intake candidates. It may inspect, validate, score readiness, and recommend clarification, but it does not approve, reject, accept, create Keeper objectives, or decide Keeper eligibility.
ready_for_lich_review	The canonical advisory readiness term for a structurally complete intake candidate. It replaces authority-bearing accepted_candidate language and does not imply approval, acceptance, or Keeper eligibility.
Lich Intake Gate	The authoritative governance gate that allows an objective intake candidate to become a governed Keeper objective. The gate outcome must be explicit, scoped, and reviewable; missing or ambiguous authority fails closed.
pgvector / Postgres	Optional local storage and vector-index backend for LifeVault-derived semantic records. It is an index/storage surface, not memory authority.
SQLite / files / artifacts / audits	Storage, artifact, or replay surfaces. They may preserve evidence and lifecycle records, but LifeVault doctrine determines memory truth and retrieval eligibility.
Tinker	A local AncientOS executor provider/lane for bounded proposal and implementation work. Tinker is a kernel lane/provider boundary, not an app and not an approval authority.
Claw Code	Historical or upstream/source-tool name. Preserve it only when identifying the original external tool, legacy command names, or historical artifacts; clarify that the governed local lane name is now Tinker.
Invoker	The safe self-development lane. Invoker work remains bounded, approval-aware, artifact-backed, and unable to bypass governance.
Roshan	The governed execution lane for elevated bounded execution and dangerous-operation validation. Roshan validates sensitive or risky execution under explicit containment contracts.
TrollWarlord	The governed commit and materialization gate. TrollWarlord normalizes commit intent, records strict replayable command shapes, and prevents phrase-specific commit bypasses.
External repos/tools	Patterns, references, integrations, or provider candidates unless AncientOS explicitly adopts them under a governed contract. They are not assumed forks, dependencies, or authority sources.
Zeus	AncientOS evidence and replay governance. Zeus defines evidence expectations, supervision hooks, replay requirements, and constitutional warnings. Zeus does not approve or execute.
Oracle	AncientOS evidence synthesis and operational review. Oracle renders bounded facts, observations, inferences, risks, and recommendations for humans and does not execute or mutate.
Kunkka	A historical deterministic patch/mutation name and future navigation/workflow routing candidate. These meanings must remain explicit until a role split or rename is approved.
Lich	A current runtime approval, confirmation, and governance-gate name. Earlier taxonomy drafts also used Lich as an archival-memory/cold-storage candidate; that archival meaning is future speculative only and must not be presented as current runtime truth.
Nyx	A preflight/interception safety candidate.
Loop Layer	A read-only AncientOS kernel primitive for declaring, inspecting, validating, and replaying bounded observe-review cycles. It is not an executor, scheduler, approval service, memory system, worker, or transport.
loop manifest	A deterministic declarative document describing one repeatable cycle, including owner, scope, capability requirements, governance posture, Zeus evidence expectations, stop reasons, and replay requirements.
loop instance proposal	A bounded proposal to evaluate or later run a loop manifest for a requester and input set. It carries no execution authority by itself.
loop trace	A replayable evidence record for a loop instance's inputs, validation decisions, governance checks, outputs, and stop reason. It is evidence, not approval authority or durable memory authority.
stop reason	An explicit terminal reason for ending a loop iteration, such as manual_stop, governance_blocked, approval_required, evidence_missing, unsafe_manifest, or iteration_limit_reached.
authority boundary	The explicit line between descriptive metadata and existing AncientOS authorities. A metadata object may reference a component, capability, approval, memory, or worker, but does not inherit its authority.

Taxonomy Model

AncientOS is the portable governed cognition kernel. It contains the governed runtime, policy posture, artifact contracts, routing discipline, capability and provider boundaries, memory continuity, and reusable kernel services needed to keep an operator's AI relationship coherent across changing infrastructure.

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

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

AncientOS contains seven taxonomy classes:

• Kernel services and lanes: symbolic operational services and lanes that provide reusable AncientOS capability.
• Kernel primitives: reusable governance, memory, artifact, evidence, policy, replay, routing, and awareness capabilities.
• Chen workflow orchestration: app-layer orchestration for multi-step workflows and capability coordination. Chen plans and delegates through governed kernel services and domain adapters without owning approval, policy, audit, replay, or universal platform authority.
• Domains: subject-specific implementations such as Media, Home, Infrastructure, Finance, Publishing, and Knowledge. Domains own domain models, domain adapters, and domain-specific planning logic under Chen or another governed app surface.
• Applications/workflows: domain packages that own workflow-specific goals, views, artifacts, and policy while requesting AncientOS kernel capabilities.
• Providers/adapters: external capability integrations. They expose tools, models, APIs, or execution surfaces but do not own app goals or identity.
• Interfaces/transports: human or machine interaction surfaces. They carry requests and render results but are not the substrate or continuity layer.

Applications run on AncientOS. Luna is the current interactive assistant interface/personality. Chen is the app-layer workflow orchestration framework. Media Manager is Chen's first active domain, using the compatibility module path app/media_manager until a future app/chen or plugin/domain structure is explicitly approved. Naga-Siren is a governed publishing workflow package. Prophet is a read-only prediction-market intelligence application. X-feed-worker is a feed ingestion or service workflow unless a later design promotes part of it into a kernel primitive. Keeper Console is an application surface over Keeper; Keeper itself is the kernel objective/task service.

AncientOS v3 domains should follow the Chen lifecycle:

Intent -> Planning -> Capability Discovery -> Evidence -> Approval -> Execution -> Verification -> Kernel Record

The Media domain refined this lifecycle into a practical workflow shape:

Resolver -> Broker -> Agents -> Approval -> Execution

Chen orchestrates this shape without knowing provider internals. Brokers ask agents who can satisfy an operator request. Agents return candidates and evidence. Approval packets separate reasoning from mutation.

Read-only inspection, planning, registry validation, and readiness reporting may stop before Approval. Mutation, import, download, refresh, migration, external dispatch, file movement, or service mutation requires Lich approval before execution. The first approved Media mutation is paused qBittorrent dispatch only; it is not download completion, file import, Plex refresh, or playback authority.

v2 applications should gradually become Chen domains when they represent subject-specific workflows rather than universal kernel services. Existing module paths remain compatibility surfaces until a separate mechanical migration is explicitly approved.

Kernel services are not applications. Rubick, Oracle, Keeper, Beastmaster, LifeVault, Lich, Zeus, Meepo, Clockwerk, LegionCommander, Roshan, Invoker, TrollWarlord, Tinker, Creep, Kunkka, and Nyx are AncientOS kernel services, components, lanes, or candidates. They provide continuity posture, capability reasoning, evidence synthesis, objective coordination, host awareness, memory authority, approval, evidence governance, transition integrity, scheduling, bounded execution, self-development, promotion, worker, navigation/routing candidate, and preflight/interception safety capabilities for the kernel. Archival-memory wording for Lich is future speculative only and must be labeled as such.

Providers and adapters are not applications and are not the kernel. Ollama, xAI/Grok, OpenAI-compatible APIs, Anthropic, Codex, Claude Code, MCP providers, UCP commerce providers, the X API, GitHub, Bitmagnet, Plex, qBittorrent, Deluge, and search/browser providers expose external capabilities behind governed contracts instead of becoming implicit authority. Tinker is special because it is both a kernel lane and the local executor provider boundary.

Interfaces and transports are not apps unless explicitly packaged as an app. Discord, terminal TUI, CLI, Web, Android, and future desktop/mobile clients carry requests and render results. They do not own routing, governance, provider selection, memory, or execution semantics.

Kernel primitives are reusable AncientOS capabilities such as approval lifecycle gates, evidence bundle contracts, append-only ledgers, readiness checks, duplicate blocking, adapter contracts, runtime state policy, and transport-neutral routing. The Loop Layer is a kernel primitive for declarative loop manifests and loop traces only; it does not execute, schedule, approve, or mutate. An app may request these primitives, but it does not own the kernel.

LifeVault terminology must distinguish logical memory continuity from storage. Discord history, Oracle reports, Rubick records, Meepo packets, raw imports, database rows, vector indexes, and model/provider outputs are evidence or storage surfaces until governed review and promotion make them LifeVault memory.

Objective Intake terminology must distinguish advisory assessment from authority. The Objective Intake Resolver may inspect, validate, score, and recommend clarification only. Lich owns the intake gate that permits a candidate to become a governed Keeper objective. Keeper receives objectives only after Lich approval or an explicit, scoped, reviewable Lich no-approval-required determination. Resolver readiness, including ready_for_lich_review, is not approval and is not Keeper eligibility.

Symbolic Names And Canonical Classifications

The symbolic Dota-style names are intentional human-facing cognitive anchors. They help the operator reason about complex operational roles without flattening the system into generic labels. Documentation should preserve the symbolic name and pair it with a canonical machine-readable classification.

component_id	symbolic_name	classification	canonical_role
rubick	Rubick	ancientos_kernel_service	continuity_capability_repository_relationship_reasoning
keeper	Keeper	ancientos_kernel_service	objective_task_coordination_service
beastmaster	Beastmaster	ancientos_kernel_service	host_runtime_awareness_service
lifevault	LifeVault	ancientos_kernel_service	durable_memory_authority
meepo	Meepo	ancientos_core_component	transition_integrity_infrastructure
roshan	Roshan	ancientos_core_component	governed_execution_lane
invoker	Invoker	ancientos_core_component	safe_self_development_lane
trollwarlord	TrollWarlord	ancientos_core_component	promotion_commit_engine
tinker	Tinker	ancientos_core_component	local_executor_provider_lane
creep	Creep	ancientos_core_component	executor_component_worker
zeus	Zeus	ancientos_kernel_service	evidence_replay_governance
oracle	Oracle	ancientos_kernel_service	evidence_synthesis_operational_review
kunkka	Kunkka	ancientos_core_component_candidate	navigation_workflow_routing_candidate
lich	Lich	ancientos_core_component	approval_confirmation_governance_language
nyx	Nyx	ancientos_core_component_candidate	preflight_interception_safety_candidate
luna	Luna	ancientos_app	discord_assistant_interface
naga_siren	Naga-Siren	ancientos_app	governed_publishing_workflow
keeper_console	Keeper Console	ancientos_app	manual_keeper_task_interface
x_feed_worker	X-feed-worker	ancientos_app	feed_ingestion_service_workflow
prophet	Prophet	ancientos_app	read_only_prediction_market_intelligence_manual_review

Migration Note

Historical Luna naming remains valid where it is part of current repository or runtime shape. Do not infer that a code symbol, command, path, service, API route, or environment variable should be renamed just because the conceptual substrate is now called AncientOS. Runtime names should change only in a future mechanical rename phase with explicit migration planning, compatibility handling, and validation.

Provider Strategy

AncientOS prefers to wrap or adapt external tools behind governed contracts before adopting them as core dependencies. Provider integrations should preserve:

• transport-neutral architecture
• deterministic-first execution
• artifact-backed state and replay evidence
• governance-gated operations
• auditability
• fail-closed boundaries
• provider interchangeability

Forks are intentional maintenance decisions, not default integration tactics. AncientOS should fork only when it explicitly decides to maintain a divergent codebase with clear ownership, validation, upgrade, rollback, and audit responsibilities.

Naming Rules

• Use AncientOS for the transport-neutral, provider-neutral governed cognition kernel.
• Use Luna for the interactive assistant/personality and interface layer over AncientOS.
• Use Semantic Router for intent classification and routing, not governance, approval, execution, or domain truth.
• Use Kernel for governance, routing, records, policy enforcement, audit/replay, and universal platform capabilities.
• Use Chen for app-layer workflow orchestration, capability coordination, multi-step domain planning, and delegation through governed services.
• Use Domains for subject-specific logic. Media, Home, Infrastructure, Finance, Publishing, and Knowledge are domain categories, not kernel services by default.
• Use Media Manager for Chen's media domain and plain-English media workflow description. Keep app/media_manager as a compatibility path until a separate mechanical refactor is approved.
• Use Naga-Siren for the governed Naga workflow app/package running on AncientOS.
• Use Tinker for the bounded local implementation/provider lane.
• Classify Rubick, Oracle, Keeper, Beastmaster, LifeVault, Lich, Zeus, Meepo, Clockwerk, LegionCommander, Roshan, Invoker, TrollWarlord, Tinker, Creep, Kunkka, and Nyx as AncientOS kernel services, components, lanes, or candidates, not applications.
• Describe Rubick as continuity, capability, repository, and relationship reasoning infrastructure and the governed continuity control plane, not merely settings management, ontology middleware, or generic governance tooling.
• Describe Keeper as objective/task coordination infrastructure, not as a memory-management application. Use Keeper Console for the UI/application over Keeper.
• Describe Beastmaster as host/runtime awareness, not repository reasoning or execution approval.
• Describe Zeus as evidence and replay governance, not approval or execution.
• Describe Oracle as evidence synthesis and operational review, not an executor or source of truth.
• Describe Chen as workflow orchestration/application framework, not a kernel component, not an approval authority, and not merely a media app.
• Describe Media Manager as Chen's first domain, read-only for inspection, resolution, brokered planning, and approval-packet generation, with one bounded approved mutation: paused qBittorrent dispatch. Import, file movement, Plex refresh, playback, migration, and broader mutation actions require future Lich-approved slices.
• Describe Meepo as transition integrity infrastructure, not generic middleware, planning, routing, orchestration, policy evaluation, or approval orchestration.
• Describe Lich as current approval, confirmation, and governance-gate language, including the Objective Intake gate for Keeper objective eligibility. Describe archival memory or cold-storage Lich only as future speculative role-split context.
• Describe Objective Intake Resolver outputs as advisory assessments, not decisions, approvals, rejections, or accepted candidates.
• Use ready_for_lich_review instead of accepted_candidate for structurally complete intake candidates awaiting Lich review.
• Describe Keeper objective intake as allowed only after Lich approval or an explicit Lich no-approval-required determination.
• Describe Kunkka patch/mutation language and navigation/routing candidate language separately until a role split or rename is approved.
• Classify Luna, Naga-Siren, Prophet, Keeper Console, and X-feed-worker as applications/workflows or interfaces.
• Use Claw Code only for historical, upstream, binary, or legacy-command references, and pair it with the Tinker lane name when ambiguity is likely.
• Describe Codex and Tinker as executor providers or provider lanes, not as ungoverned tools with direct authority.
• Describe Discord as a transport, adapter, or rendering shell, not as AncientOS's core logic owner.
• Describe Luna as the interactive assistant/personality and interface layer, not as the governed kernel.
• Describe LifeVault as the logical memory continuity layer, not as pgvector, Postgres, SQLite, a file tree, Discord history, Oracle evidence, Rubick ontology, or Meepo transition data.
• Describe Naga-Siren and X-feed-worker as applications, workflow packages, or services unless a specific kernel primitive is being named.
• Describe providers/adapters as external capability integrations, not app owners, substrate authority, or identity.
• Describe interfaces/transports as interaction surfaces, not the substrate itself.
• Use wrap, adapt, provider, or contract language for external tools unless a maintained fork has been explicitly approved.

What Not To Rename Yet

Do not rename these as part of this taxonomy update:

• repository names such as discord-luna
• docs paths such as docs/luna/* or machine manifest filenames
• Python packages, modules, imports, classes, or functions
• Docker services, compose keys, image names, or container names
• environment variables and secret names
• API routes, command names, CLI entrypoints, or database paths
• persisted artifact paths, state roots, or compatibility identifiers

Boundary Invariants

All AncientOS/Luna terminology should reinforce these invariants:

• personal AI continuity
• model/provider replaceability
• transport-neutral architecture
• posture continuity
• transition continuity
• deterministic-first execution
• artifact-backed state
• governance-gated operations
• replay safety
• auditability
• fail-closed boundaries
• no hidden autonomy
• no unrestricted execution routing