AncientOS Kernel Services
AncientOS is a governed cognition kernel. Kernel services expose reusable capability under governance; applications and transports consume those services without inheriting authority.
This page is the responsibility map for current kernel services. It does not add runtime wiring, change authority, or create execution paths.
The constitutional reference for these service boundaries is AncientOS Kernel Specification v1.0.
Responsibility Map
| Service or lane | Current responsibility | Explicit non-authority |
|---|---|---|
| Runtime Kernel | Transport-neutral message order, deterministic routing, governed preemption, clarification, and fallback sequencing. | Transport ownership, approval, execution, memory authority, or provider authority. |
| Rubick | Continuity posture, capability registry, provider/consumer descriptors, repository reasoning, relationship reasoning, settings visibility, and knowledge graph scaffolding. | Provider execution, approval, live host probing, LifeVault queries, or hidden capability enablement. |
| Keeper | Governed objectives, task state, planning records, blockers, preflight context, and next-review needs. | Approval, worker dispatch, hidden scheduling, or parallel memory authority. |
| Oracle | Read-only evidence synthesis, operational review, observations, inferences, risk summaries, and recommendations. | Execution, approval, mutation, provider selection, evidence collection by assumption, or source-of-truth authority. |
| Beastmaster | Host and runtime awareness from supplied or approved runtime, Docker, storage, memory, load, and service evidence. | Repository reasoning, approval, mutation, execution, or Oracle synthesis. |
| LifeVault | Durable memory authority, promotion state, review provenance, supersession/deprecation, archive lifecycle, and retrieval eligibility. | Shadow memory, execution, approval, or unreviewed transcript promotion. |
| Lich | Approval, confirmation, intake gates, and governance decision boundaries. | Execution, scheduling, dispatch, evidence substitution, or silent scope expansion. |
| Zeus | Evidence expectations, replay governance, receipts, and constitutional supervision hooks. | Approval, execution, dispatch, mutation, or accepting missing evidence as sufficient. |
| Meepo | Transition integrity and fail-closed revalidation of approved state changes. | Planning, routing, approval orchestration, execution, or policy invention. |
| Clockwerk | Approved scheduling and time-window visibility. | Approval, execution, authority refresh bypass, or autonomous scheduling. |
| LegionCommander | Bounded task graph and dispatch planning after governance. | Governance authority, self-authorization, unbounded planning, or scope expansion. |
| Roshan | Governed elevated execution validation and dangerous-operation containment. | Approval bypass, hidden mutation, or unrestricted execution. |
| Invoker | Safe self-development lane and bounded implementation coordination under approved scope. | Approval authority, unrestricted mutation, or autonomous continuation. |
| Tinker | Local implementation/executor provider lane for bounded coding work. | Governance authority, provider self-selection outside policy, or direct approval bypass. |
| Creep | Bounded worker execution through approved jobs and existing governed lanes. | Self-selected work, scope expansion, indefinite retry, or hidden state retention. |
| TrollWarlord | Governed commit/materialization intent normalization and replayable command shape enforcement. | Generic shell authority, phrase-specific bypass, or approval substitution. |
Application Boundary
Applications and workflows such as Luna, Naga-Siren, Prophet, Keeper Console, and X-feed-worker consume kernel services. They may own interface state, domain artifacts, workflow-specific policy, and rendering choices, but they do not own kernel truth.
Transports such as Discord and terminal TUI carry messages and render results. They do not own routing, governance, memory, provider selection, execution, or objective state.
Providers such as Ollama, xAI/Grok, OpenAI-compatible APIs, Anthropic, Codex, Claude Code, GitHub, X API, MCP providers, and search/browser adapters expose implementation surfaces behind governed contracts. They are replaceable infrastructure, not identity or authority.
Provider Selection Philosophy
AncientOS is capability-first. A request asks for a governed capability, not a specific model, tool, or transport. Rubick records capability/provider truth, runtime arbitration selects eligible providers deterministically, and Oracle may explain decisions from supplied evidence.
The current operating posture is local-first for coding and implementation lanes, with frontier escalation through governance for interactive conversation and eligible inference roles. Frontier output remains advisory unless separately promoted through the appropriate kernel authority.
Safety Invariants
- Read-only inspection is preferred.
- Mutation requires Lich approval and Zeus evidence where applicable.
- Missing or ambiguous authority fails closed.
- Capability visibility is not execution authority.
- Provider availability is not approval.
- Oracle recommendations are not decisions.
- LifeVault memory requires review and promotion.
- Transport convenience must not create hidden kernel authority.