AncientOS Kernel Service And Application Boundary Model

This document defines the conceptual boundary model for AncientOS kernel services, Chen workflow orchestration, domains, applications/workflows, providers/adapters, and interfaces/transports. It is documentation only. It does not add runtime app registration, change behavior, rename runtime resources, or enforce contracts in code.

Boundary Classes

AncientOS is the transport-neutral, provider-neutral governed cognition kernel. It preserves personal AI continuity while providing kernel primitives such as governance, routing/arbitration, capability/provider selection, memory authority, artifacts, ledgers, evidence, policy, replay/provenance, repository reasoning, knowledge graph reasoning, and operational awareness.

Kernel services expose reusable AncientOS capability. Rubick, Oracle, Keeper, Beastmaster, LifeVault, Lich, Zeus, Meepo, Clockwerk, LegionCommander, Roshan, Invoker, TrollWarlord, Tinker, Creep, Kunkka, and Nyx are kernel services, components, lanes, or candidates. They do not own application domain goals. Rubick governs continuity, capability, repository, and relationship reasoning. Keeper owns objectives and tasks. Oracle synthesizes evidence and review. Beastmaster observes host/runtime state. LifeVault owns durable memory authority. Lich owns approval and governance gates. Zeus owns evidence expectations and replay governance. Meepo protects transition integrity when approved state crosses lifecycle boundaries.

Applications and workflows consume kernel capabilities. Luna, Naga-Siren, Prophet, X-feed-worker, Keeper Console, and future domain apps own domain workflows, domain artifacts, app-specific policy, user-facing views, and interface behavior within governed boundaries. Applications do not bypass governance, mutate kernel state directly, or treat a provider as authority.

Chen is the app-layer workflow orchestration framework. It coordinates capabilities, plans multi-step app/domain flows, and delegates to Rubick, Oracle, Lich, Tinker, and domain adapters. Chen does not own kernel governance, approval, policy enforcement, audit, replay, memory authority, or universal platform capabilities.

Domains implement subject-specific logic behind Chen or another governed app surface. Media, Home, Infrastructure, Finance, Publishing, and Knowledge are domain categories, not kernel services by default. Media Manager is Chen's first active domain. The implementation path remains app/media_manager for compatibility until a future app/chen or plugin/domain refactor is explicitly approved.

Prophet is a read-only prediction-market intelligence app. It may inspect market fixtures or explicitly configured read-only snapshots, render advisory recommendations, simulate paper trades, and produce manual-review proposal artifacts. It has no wallet, credential, order-signing, authenticated trading, or live-execution authority, and its execution boundary remains disabled fail-closed.

Providers and adapters expose access to external or local systems. Ollama, xAI/Grok, OpenAI-compatible APIs, Anthropic, Codex, Claude Code, X API, GitHub, MCP providers, UCP commerce providers, and search/browser providers provide capabilities behind AncientOS contracts. They do not decide policy, approve actions, own application state, become kernel authority, or define AI identity.

Interfaces and transports render and relay interaction. Discord, CLI, Web, Android, and future desktop/mobile clients carry requests, confirmations, and responses. They do not own cognition, routing, policy, execution authority, or domain state. Transport replacement must not break continuity.

State Ownership

State class	Owner	Examples	Boundary rule
Application-owned domain state	Application/workflow	Naga-Siren packet state, Prophet paper-simulation artifacts, Luna interface session metadata, Keeper Console view state	Applications may update this state only through their own governed lifecycle and only after required kernel capability results are confirmed.
Chen orchestration state	Chen app layer	workflow readiness summaries, planning previews, domain flow blockers, delegated capability references	Chen may coordinate and summarize workflow state, but it does not mutate kernel state or grant approval.
Domain state	Domain package	Media library posture, Home device posture, Infrastructure maintenance posture, Finance read models, Publishing drafts, Knowledge review surfaces	Domains own subject-specific read models and artifacts under governed app boundaries; domain mutation requires the relevant Lich approval and evidence path.
Kernel state	AncientOS primitives and kernel services	governance decisions, Keeper tasks/objectives, policy outcomes, memory records, ledgers, evidence, routing state, provenance	Applications request changes through kernel capabilities; they do not mutate kernel state directly.
Continuity posture state	Rubick	prompt/profile posture, cognitive modes, runtime abstraction, ontology visibility, capability descriptors, repository reasoning, continuity-safe settings	Applications and lanes may request posture changes, but Rubick remains the governed operator-visible surface.
Objective and task state	Keeper	governed objectives, task rows, blockers, planning metadata, preflight signals, next-review needs	Applications may render or request updates, but Keeper remains the canonical objective/task service.
Host/runtime awareness evidence	Beastmaster	approved host, Docker, storage, memory, load, and runtime observations	Other services consume supplied evidence; Beastmaster remains the observer and does not approve or execute.
Transition integrity state	Meepo	transition packets, approval bindings, context hashes, revalidation results, transition audit events	Apps and lanes provide normalized transition context; Meepo revalidates and fails closed without executing, routing, or mutating their state.
Provider credentials/capabilities	Provider/adapter boundary plus configured secret storage	X API credentials, model provider access, GitHub tokens, local executor access	Apps request capability use by reference; credentials are not app domain state and must not be rendered to transports.
Transport-specific presentation state	Interface/transport adapter	Discord message ids, rendered buttons, CLI output shape, web view state	Presentation state may mirror app or substrate state for review, but it is not the source of truth.

Application Lifecycle

AncientOS v3 keeps the layered model: Kernel governs -> Chen orchestrates -> Domains implement.

The conceptual AncientOS application lifecycle is:

Declared: the app has a documented identity, purpose, owned domain artifacts, and requested capabilities.
Configured: app-specific settings, destinations, credential references, and policy parameters are provided without embedding raw secrets.
Validated: AncientOS checks that requested capabilities, evidence requirements, adapter references, and policy constraints are coherent.
Approved: a human or governed approval path accepts the app scope, capability requests, risk posture, and review requirements.
Invoked: an interface, scheduler, or governed workflow invokes the app within its approved scope and kernel capability boundaries.
Supervised: AncientOS kernel services observe policy, evidence, execution, routing, and operational-awareness boundaries while the app runs.
Audited: ledgers, evidence, provenance, provider results, and app-owned state transitions remain inspectable and replayable.
Suspended/retired: an app can be disabled, paused, or retired without removing shared kernel primitives or invalidating historical evidence.

This lifecycle is conceptual. No runtime registration system is introduced by this document.

AncientOS v3 Chen domains use a domain workflow lifecycle:

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

Read-only inspection, planning, registry validation, and readiness reporting may stop before Approval. Any mutation, import, download, refresh, migration, external dispatch, file movement, or service mutation must pass through Lich approval before execution.

Capability Contracts

AncientOS is capability-first. A capability contract describes what an application asks the kernel to do, what evidence or permission must exist, which kernel service or provider boundary may satisfy the request, and what state may change after success.

Conceptual capability contract fields:

Field	Meaning
`requesting_app`	The application/workflow making the request.
`capability`	The kernel capability being requested.
`scope`	The bounded target, artifact, destination, or time window.
`required_evidence`	Evidence that must exist before the request can proceed.
`required_approval`	Human or governed approval requirement.
`provider_boundary`	Optional external/local provider or adapter involved.
`allowed_state_updates`	State classes the app may update after confirmed success.
`forbidden_state_updates`	State classes that must not be changed by this request.
`audit_output`	Required ledger, evidence, or provenance record.

Capability contracts are not authority by themselves. They are reviewable descriptions of intended interaction. Runtime enforcement is deferred.

Naga-Siren Example

Naga-Siren is a governed publishing workflow app. A conceptual publishing request may use this sequence:

Request render_content from AncientOS so a candidate can be presented in a review surface.
Request approval for the candidate, destination, policy result, and readiness evidence.
Request publish_to_x through the X API adapter only after approval, readiness checks, duplicate checks, identity validation, and policy checks pass.
Append evidence for the approval, provider call, simulated or live result, destination, payload hash, and policy outcome.
Update Naga-Siren app-owned packet state only after AncientOS confirms the capability result succeeded.

Naga-Siren may own candidate, packet, avatar/persona, destination intent, and publishing-policy state. It must not own X credentials, bypass approval, mutate shared ledgers directly, or treat Discord render state as canonical publishing state.

Keeper And Keeper Console Example

Keeper is the kernel objective and task coordination service. A conceptual objective/task update may use this sequence:

Resolve an objective or task reference through explicit Keeper context.
Request a read-only Keeper view, planning summary, or repository preflight when no mutation is requested.
For task mutation, create a Lich approval surface with target IDs, human-readable summary, and bounded intended change.
After approval, call the canonical Keeper service endpoint for the exact approved mutation.
Append evidence for source task state, approval, mutation receipt, and resulting Keeper state.

Keeper Console is the application/UI over Keeper. It may render task rows, planning views, triage views, and proposal artifacts. It must not create a parallel task backend, bypass Lich approval for governed conversational mutations, write LifeVault memory, or treat browser state as canonical Keeper state.

Component Interaction Rules

Kernel services expose capabilities; they do not own application domain workflows.
Chen orchestrates workflows and coordinates capabilities; it does not own kernel governance, approval, policy, audit, replay, memory authority, or universal platform capability definitions.
Domains implement domain-specific logic; they do not become kernel concepts merely because Chen can orchestrate them.
Media Manager is the first active Chen domain and remains read-only for inspection/planning until Lich approves any import, download, refresh, or migration action.
Rubick owns posture, capability, repository, and relationship reasoning surfaces; applications do not create private posture or capability controls that bypass Rubick.
Keeper owns objective and task state; applications do not create shadow Keeper backends.
Beastmaster owns host/runtime awareness; applications and Oracle do not run host probes by assumption.
Oracle owns evidence synthesis and review; it does not approve, execute, or mutate.
LifeVault owns durable memory authority; applications do not create shadow memory stores.
Lich owns approval and governance gates; Zeus owns evidence expectations and replay governance.
Meepo owns transition integrity checks; apps and lanes do not turn it into orchestration, planning, routing, policy evaluation, or approval management.
Applications consume capabilities; they do not bypass governance or mutate kernel state directly.
Kernel primitives remain reusable across applications and must not become application-specific hidden authority.
Providers/adapters expose access to local or external systems; they do not decide policy, approval, app goals, or final truth.
Bitmagnet, Plex, qBittorrent, Deluge, and similar services are external service adapters for domains, not kernel services or authority sources.
Interfaces/transports render and relay interaction; they do not own cognition, routing, app domain state, or execution authority.
Provider credentials are referenced through configured boundaries and must not be copied into app state or transport state.
App-owned state changes should follow confirmed substrate capability results, not optimistic assumptions.
Evidence and ledgers must remain append-oriented, inspectable, and replayable.
Ambiguous scope, missing evidence, missing approval, or unclear provider authority must fail closed.
Symbolic names remain cognitive anchors, but canonical classifications define the boundary.

Deferred Runtime Work

This document does not implement:

runtime app registration
executable manifest loading
permission enforcement code
capability dispatch APIs
provider credential plumbing
transport permission models
mechanical renames of Luna-era paths, modules, services, commands, or files

Future runtime work should wait until the taxonomy and contract vocabulary are stable, then introduce enforcement incrementally with compatibility and audit plans.