Operational Cognition Routing

The AncientOS runtime kernel routes operational introspection through governed Oracle/cognition paths instead of treating status questions as generic execution or governance preview requests. Luna, Discord, and terminal TUI are transport/interface surfaces over this routing behavior.

Doctrine

Operational introspection is not execution intent.

Canonical objective-specific routing and lifecycle authority boundaries are defined in Governance Kernel. This page describes operational cognition routing behavior and should defer lifecycle authority doctrine to that source.

Requests about operational awareness, coordination awareness, replay continuity, topology, capabilities, governance boundaries, workflow state, and constitutional warnings route to advisory Oracle/cognition reports. They do not create execution plans, approval staging, rollback staging, hidden planners, or runtime-owned authority.

Operational cognition routing exists to support personal AI continuity. It helps the operator ask "where are we, what changed, what is safe next, and what still needs trust evidence?" without turning that awareness into action authority. Governance is the trust boundary around continuity, not an enterprise-compliance identity for the project.

Rubick and Meepo are separate continuity surfaces in this routing model: Rubick exposes posture continuity, continuity-safe configuration, ontology visibility, cognitive modes, and prompt/profile posture. Meepo protects transition continuity by revalidating approved state changes. Operational inspection may explain either surface, but it must not convert inspection into posture mutation or transition execution.

Pending-action continuation

The runtime may route an action only after Rubick confirms its canonical capability is implemented and wired, a governed adapter is registered, and the capability declares one canonical authority_mode. Every executable capability is either auto_execute or require_lich. Auto-authorized work executes immediately without redundant confirmation. Lich-gated work creates a real Lich approval and exposes Approve and Decline controls.

Conversational replies such as do it, yes, proceed, and now do it are never execution authority. They cannot resolve a Lich approval or authorize an adapter invocation. Pending action records remain useful for awaiting_lich, approved, executing, completed, declined, expired, unavailable, and failed lifecycle state, but not as informal approval records.

Immediately before execution, the runtime rechecks Rubick capability and provider readiness plus adapter authority. Expired, ambiguous, missing, or revoked actions fail closed. Execution occurs only through the registered adapter and emits deterministic Zeus-compatible evidence for both auto-executed and Lich-approved work; rendering or echoing a CLI string never counts as execution. A model-generated luna-tools command is suppressed unless it is represented by this canonical capability-and-adapter path.

Keeper core/calendar/task/scheduler inspection is not currently a registered capability. keeper_task_management and keeper_repository_preflight are related records but do not authorize that inspection. The existing capability_registry adapter can inspect which Keeper capability records are registered; it must not be described as inspection of Keeper runtime state. Capability, adapter, provider, evidence, parameter, target, and invariant failures are execution-path unavailability, not operator denial. Their response must identify the missing requirement and remediation path. Technically executable work that is not pre-authorized routes to the operator's Lich Approve/Decline boundary rather than ending in a terminal policy denial.

Taxonomy

This repo uses the name advisory_synthesis for the reflective cognition lane. The name is intentionally not an execution-lane name: it means written review, strategic critique, roadmap synthesis, operator reflection, and non-binding recommendations.

app/routing/operational_cognition_router.py classifies operator text into:

• operational_awareness
• coordination_awareness
• topology_inspection
• replay_inspection
• capability_inspection
• governance_inspection
• workflow_state_analysis
• coordination_proposal_review
• constitutional_inspection
• execution_request
• mutation_request
• dangerous_mutation_request
• unknown

app/routing/advisory_synthesis_router.py classifies reflective review text into:

• advisory_synthesis

The advisory classes route to Oracle/cognition. Execution and mutation classes are not handled by this router and must pass through governed execution or governance-preview paths.

advisory_synthesis carries no execution authority, no mutation authority, no approval authority, and advisory-only planning authority. It may use governed read-only context only when the runtime explicitly permits that context.

Routing Examples

Operator request	Route	Result
What is the current operational posture?	operational_awareness	Oracle operational console summary
What coordination risks exist?	coordination_proposal_review	Coordination/risk visibility
What workflows are blocked?	workflow_state_analysis	Workflow-state report
Show replay continuity	replay_inspection	Replay-aware operational report
Show operational topology	topology_inspection	Topology/readiness report
What capabilities are available?	capability_inspection	Capability governance report
What governance boundaries exist?	governance_inspection	Governance boundary report
What constitutional risks exist?	constitutional_inspection	Constitutional warning report
Review the platform and suggest a self-development plan.	advisory_synthesis	Conversational strategic critique
Analyze AncientOS and tell me where we are weak.	advisory_synthesis	Strength/weakness synthesis
Am I in a rabbit hole?	advisory_synthesis	Reality-check without action authority
Reality-check this project.	advisory_synthesis	Non-binding project critique
Execute the coordination proposal	execution_request	Not handled as introspection
Delete the workflow state file	mutation_request	Not handled as introspection

Operational Console UX

app/oracle/operational_console.py builds transport-neutral console surfaces with:

• route explanations
• authority cards
• readiness/topology/workflow/replay/capability/governance cards
• Oracle narration
• explicit no-execution and no-mutation fields

Discord, CLI, web, and mobile renderers may display these fields, but they must not reinterpret routing or own operational semantics.

Governance Preview Separation

Operational inspection routes before plan/delegate/governance-preview staging. For example, What governance boundaries exist? renders a governance inspection report. It does not trigger blast-radius planning, execution-plan generation, rollback notes, approval staging, or Commander callbacks.

Requests that ask to run, execute, mutate, delete, commit, repair, or deploy are not promoted into operational inspection. They remain outside the advisory router and must be handled by existing governed preview/approval paths.

Reflective review routes before patch-application and governance-preview classification when the prompt is clearly asking for written analysis, synthesis, or recommendations. Explicit mutation language such as edit, patch, apply, change files, or run commands stays in the existing execution governance path.

Continuity

The runtime may store bounded operational focus fields:

• active operational focus
• current route class
• last route decision
• next safe inspection suggestion
• workflow summary for the current focus

It may not store unrestricted transcript memory, infer preferences, persist authority, or start autonomous continuity loops.

Continuity here means bounded, inspectable context that survives ordinary interaction gaps and transport changes. It does not mean hidden personalization, sentience, unreviewed memory writes, or autonomous background operation.

Explanation Layer

Every console response includes deterministic route explanation fields:

• route intent
• routing reason
• matched terms
• execution authority
• mutation authority

These explanations are evidence-linked to router and Oracle modules. They do not disclose hidden reasoning or chain-of-thought.

Human Review Questions

• Which operational console cards should become stable UI contracts?
• Should replay inspection receive a dedicated Oracle report kind beyond current operational-state visibility?
• Which execution/mutation trigger terms should be promoted into a machine-readable policy manifest?
• Should bounded operational focus be shared across transports or remain scoped to channel/user/session?

Pending Lich approvals

What are my pending approvals? selects the authoritative Lich queue, not Keeper workflow state or generic governance awareness. The injected durable Lich service returns a transport-neutral projection that distinguishes storage unavailable from an authoritative empty queue and sorts cards by creation time and approval ID.

Cards distinguish plan_review from implementation_authorization. Approve and Decline use different opaque bindings over the exact approval, decision, requester, channel, operation, objective, authoritative hash, binding ID, and expiry. Each card displays the exact Approve Lich review lich_<id> and Decline Lich review lich_<id> commands. These verb-first commands take precedence over generic governance language that follows. ID-first and other unsupported Lich-shaped decision text is intercepted before inference and returns the exact canonical syntax without making a decision. Unknown, malformed, expired, stale, decided, unauthorized, actor/channel, objective, plan-hash, lifecycle, and binding mismatches fail closed. By default a decision records only that gate and does not execute. The bounded Chen acquisition exception explicitly declares that Approve releases one immutable candidate episode through the existing executor. Meepo revalidates every material transition against the approved envelope; expected download, promotion, Plex verification, and stop-seed transitions continue, while material drift halts the cascade and creates a fresh Lich review. This authority cannot be consumed by another proposal, revision, candidate, or action class.

Compositional observational inquiries

The shared runtime also supports principal-authorized compositional read cognition. Existing exact scoped read owners retain their semantics; generalized Oracle inspection uses current Rubick operation registrations before task/planning and generic inference fallback. Registered observations can be composed without adding a route for each future question. Discovery never grants mutation or approval authority.