AncientOS Governance Kernel

The Governance Kernel is the canonical architecture reference for governed Objective to Loop lifecycle work in AncientOS. It binds objective context, Keeper coordination, Loop Layer artifacts, lifecycle inspection, Oracle review, Rubick capability reasoning, Zeus evidence, Lich approval, Clockwerk scheduling, LegionCommander and Creep dispatch, loop traces, and LifeVault retention into one inspectable authority model.

This document is doctrine only. It does not grant runtime behavior, routing behavior, execution authority, schema changes, or memory authority.

Canonical Lifecycle

User Intent
  -> Objective Intake
  -> Objective Intake Resolver Assessment
  -> Lich Intake Gate
  -> Objective Context Resolution
  -> Keeper Objective
  -> Strategy Selection
  -> Loop Manifest
  -> Loop Proposal
  -> Lifecycle Inspection
  -> Oracle Review
  -> Zeus Evidence
  -> Lich Approval
  -> Clockwerk Scheduling (optional)
  -> LegionCommander / Creep Dispatch (optional)
  -> Loop Trace
  -> LifeVault Retention (optional)

The lifecycle is objective-first. A loop is not the top-level primitive; it is one governed strategy for pursuing an objective. Read-only inspection may stop before approval. Mutation, external effects, scheduling, dispatch, durable retention, or worker execution require explicit evidence and the appropriate approval path.

Authority Boundaries

Component	Allowed authority	Forbidden authority
Oracle	Inspect, summarize, infer from evidence, warn, and recommend.	Execute, approve, schedule, dispatch, mutate, retain memory, create approval packets, or invent facts.
Rubick	Reason about capability, readiness, posture, provider, and ontology evidence.	Execute providers, invent capabilities, silently enable providers, approve work, or mutate lifecycle state through capability references.
Keeper	Coordinate objectives, goals, jobs, blockers, references, and next review needs.	Implicit execution, approval bypass, worker dispatch without governed authority, or arbitrary mutation authority.
Loop Layer	Declare strategy through manifests, proposals, validation, inspection, and traces.	Autonomous behavior, scheduling, execution, approval, worker dispatch, hidden retries, transport routing, or memory storage.
Zeus	Define evidence expectations, collect or reference evidence packets, and support replay.	Approval, execution, dispatch, hidden mutation, or accepting missing evidence as sufficient.
Lich	Approve, deny, scope, or require changes for governed action.	Execution, scheduling, dispatch, hidden mutation, or silently broadening approval scope.
Clockwerk	Schedule explicitly approved review or dispatch windows and expose timing visibility.	Approval, execution, authority refresh bypass, or converting schedule state into permission to act.
LegionCommander	Build bounded task graphs and dispatch plans only after required approval.	Governance authority, self-authorization, unbounded planning, scope expansion, or approval bypass.
Creep	Execute approved bounded worker jobs through existing governed lanes.	Governance, self-selected work, scope expansion, indefinite retry, or hidden state retention.
LifeVault	Retain approved durable memory artifacts under memory policy.	Hidden operational state, shadow memory, approval authority, execution authority, or duplicate memory authority outside LifeVault.

Lifecycle Components

Component	Purpose	Inputs	Outputs	Authority	Forbidden behavior	Failure behavior
User Intent	Captures the operator's desired outcome, constraints, and risk posture.	Transport-neutral user request, explicit constraints, supplied context.	Raw operator expression for intake.	Intent expression only.	Execute, approve, schedule, mutate, or imply capability availability.	Ambiguous intent asks for clarification or routes to read-only global visibility.
Objective Intake	Converts raw user intent into an inert candidate objective artifact for review.	User intent, requester reference, source transport, constraints, risk hints.	Objective intake candidate, deterministic validation result, candidate hash, advisory readiness score, and clarification needs.	Classification, inspection, validation, readiness scoring, and clarification recommendation only.	Accept candidates authoritatively, create Keeper objectives or jobs, execute, schedule, approve, dispatch, mutate runtime state, or write LifeVault memory.	Missing fields, unknown fields, unclear authority, or ambiguous intent fail closed as not ready, requiring clarification, or requiring Lich review.
Objective Intake Resolver Assessment	Assesses candidate readiness without deciding Keeper eligibility.	Objective intake candidate, validation findings, risk hints, source evidence, clarification needs.	Advisory assessment such as ready_for_lich_review, clarification recommendation, governance blockers, and assessment evidence.	Read-only advisory assessment only.	Approve candidates, reject candidates with governance authority, imply Lich approval, create Keeper objectives, or bypass the Lich intake gate.	Unsupported, ambiguous, stale, or incomplete authority remains inert and fails closed pending clarification or Lich review.
Lich Intake Gate	Decides whether an intake candidate may become a governed Keeper objective.	Candidate artifact, resolver assessment, source evidence, requester context, risk posture, and policy requirements.	Read-only review request artifact and explicit decision artifact: approved for objective creation, no approval required, clarification required, or rejected.	Authoritative governance gate for future Keeper objective eligibility only.	Execute work, schedule, dispatch, mutate state, create hidden approvals, create Keeper objectives or jobs directly, or infer no-approval-required from silence or low risk.	Missing, ambiguous, stale, mismatched, or unsupported authority denies progression, requires changes, requires clarification, or blocks governance.
Objective Context Resolution	Binds a request to exactly one governed objective when explicit evidence exists.	Objective id, exact title, governed metadata, Lich intake gate outcome, Keeper reference, loop artifact reference.	Resolved objective context or fail-closed ambiguity result.	Deterministic binding aid only.	Infer hidden objective context from session proximity, transport state, user identity, or operational intuition.	No objective routes to global Oracle visibility; multiple or stale candidates require clarification.
Keeper Objective	Coordinates Lich-approved objective-linked work and task state.	Resolved objective, approved Lich intake gate outcome or explicit Lich no-approval-required determination, policy posture, blockers, references, status, next review needs.	Keeper goal/job state and coordination references.	Objective coordination after Lich gate eligibility.	Treat coordination as approval, accept ungated intake candidates, dispatch workers directly, or bypass Lich.	Missing or unsafe authority blocks progression and records review needs.
Strategy Selection	Selects the governed strategy for the objective.	Objective context, Keeper state, risk posture, available artifacts, capability needs.	Selected strategy: read-only review, one-shot task, loop, schedule, dispatch, or no action.	Advisory coordination decision.	Create autonomous goals, hidden planners, implicit schedules, or execution paths.	Unknown fit chooses read-only review, no action, or clarification.
Loop Manifest	Declares the repeatable strategy template.	Purpose, owner, read scope, capability requirements, governance posture, stop reasons, replay requirements.	Validated manifest and deterministic manifest hash.	Declarative strategy metadata.	Execute, schedule, approve, dispatch, mutate, hide prompts, store private state, or claim authority.	Invalid, unsafe, missing, or unknown fields fail closed.
Loop Proposal	Binds a manifest to one objective, requester, target, inputs, and requested mode.	Objective reference, Keeper reference, manifest hash, input artifacts, risk posture, requested authority metadata.	Reviewable loop proposal and proposal hash.	Proposal artifact only.	Run the loop, mutate state, approve work, create schedules, dispatch workers, or write memory.	Missing objective, manifest, evidence, bounds, or authority metadata blocks progression.
Lifecycle Inspection	Scores and explains lifecycle completeness.	Objective, Keeper, manifest, proposal, trace, approval, schedule, dispatch, evidence, retention metadata.	Deterministic complete, incomplete, blocked, or unsafe report with blockers.	Read-only inspection.	Repair artifacts, discover hidden files for authority, create approvals, schedule, dispatch, execute, or write memory.	Missing or unsafe lifecycle state is reported as blocked or unsafe.
Oracle Review	Interprets observable lifecycle and operational evidence for humans.	Proposal, lifecycle inspection report, Rubick evidence, Zeus expectations, Lich state, schedule/dispatch/trace/retention observations.	Facts, inferences, warnings, readiness score, and recommendations.	Read-only observability.	Execute, approve, schedule, dispatch, mutate, retain memory, repair artifacts, or present recommendations as decisions.	Missing evidence is reported as unavailable or blocked; Oracle does not fill gaps by assumption.
Zeus Evidence	Defines and receives evidence needed for review and replay.	Objective reference, Keeper reference, manifest hash, proposal hash, capability analysis, Oracle review, approval state, outputs, stop reason.	Evidence expectations, evidence packet, receipt references, replay material.	Evidence and replay authority.	Approve, execute, dispatch, mutate, or treat absent evidence as acceptable.	Missing, stale, mismatched, or untrusted evidence fails closed.
Lich Approval	Decides whether governed action may proceed within scope.	Zeus evidence, policy context, requested authority, risk, rollback/validation posture, bounded scope.	Approval, denial, required changes, or scoped approval artifact.	Approval authority.	Execute the work, silently widen scope, approve without evidence, or approve unrelated future runs.	Missing or insufficient evidence denies or requires changes; ambiguous scope fails closed.
Clockwerk Scheduling	Schedules approved future review or dispatch windows when scheduling is requested.	Explicit scheduling approval, lifecycle reference, cadence/window, freshness and authority checks.	Schedule record and timing visibility.	Scheduling only.	Approve work, execute work, bypass fresh checks, or infer approval from a schedule.	Missing scheduling approval or stale authority prevents scheduling or blocks fire.
LegionCommander / Creep Dispatch	Builds bounded task graphs and performs approved worker execution.	Lich approval, Zeus evidence plan, dispatch bounds, capability constraints, stop conditions.	Task graph, dispatch record, bounded worker result.	Bounded execution only after governance.	Self-authorize, expand scope, run indefinitely, hide retries, or become governance.	Missing approval, evidence, dispatch bounds, or capability support blocks dispatch or stops execution.
Loop Trace	Records what happened across the lifecycle.	Objective, Keeper, manifest/proposal hashes, inspections, Oracle review, evidence, approval, schedule, dispatch, outputs, stop reason.	Replayable trace artifact and stop record.	Evidence artifact only.	Become approval, durable memory, hidden operational state, or authority for later work.	Incomplete, inconsistent, or authority-claiming traces are unsafe evidence and block trust carry-forward.
LifeVault Retention	Promotes approved lifecycle outputs into durable memory when policy allows.	Retention decision, redaction policy, provenance, trace/evidence references, approval metadata.	Promoted memory artifact, rejection, supersession, archive, or retention record.	Durable memory authority.	Shadow memory, hidden operational state, duplicate memory authority, or retention without policy.	Missing approval, provenance, redaction, or scope fails closed and leaves material as evidence only.

Evidence And Approval Rules

Evidence and approval are separate gates.

• Zeus evidence proves what was reviewed, observed, produced, validated, or replayed.
• Lich approval decides whether scoped governed action may proceed.
• Lich also owns the intake gate that allows an intake candidate to become a governed Keeper objective.
• Lich intake gate artifacts are read-only records. They do not invoke Lich runtime services, create approvals, create objectives, create jobs, schedule, dispatch, execute, mutate state, or write memory.
• Resolver assessments, including ready_for_lich_review, are advisory evidence only and do not create Keeper eligibility.
• Keeper may receive objectives only after Lich approval or an explicit, scoped, reviewable Lich no-approval-required determination.
• A complete Oracle recommendation is not Zeus evidence by itself.
• Complete Zeus evidence is not Lich approval.
• Lich approval does not execute work.
• Schedules, dispatches, traces, and retained memory must remain tied to the evidence and approval scope that produced them.

Any missing, ambiguous, stale, mismatched, or unsupported authority state fails closed.

Routing Doctrine

Ambiguous read-only prompts must not silently bind to recent conversation, transport state, or session continuity. If explicit objective context resolves to exactly one objective, route to Oracle Objective Lifecycle Review. If no objective context exists, route to global Oracle Visibility Review. If multiple objective candidates exist, ask for clarification.

This routing doctrine grants no execution, approval, scheduling, dispatch, mutation, or memory authority.

Memory Doctrine

Loop traces, Oracle reports, Zeus evidence, Keeper state, Rubick records, Lich approvals, Clockwerk schedules, dispatch records, and provider outputs are not durable memory by default. They are evidence or operational artifacts unless LifeVault explicitly promotes them under retention policy.

LifeVault remains the memory authority. Storage backends, indexes, raw logs, Discord history, session continuity, and local files do not become memory truth by existing.

Consistency Audit

This Phase 1 audit found the following documentation areas that should remain linked to this Governance Kernel rather than duplicating full lifecycle doctrine.

Potential Doctrinal Inconsistencies

• docs/luna_master_roadmap.md describes Zeus with broader future orchestration and constrained self-stabilization language. That roadmap text is future-facing and should keep clarifying that Zeus evidence and supervision do not replace Lich approval or execution lanes.
• docs/architecture.md is broad and historically accumulative. It contains multiple era sections that restate authority boundaries. Future edits should collapse repeated Objective/Loop lifecycle language into references to this document.
• docs/proposals/objective_loop_lifecycle_canonicalization.md is now a source proposal, not the canonical doctrine. It should remain as historical rationale and point to this document for current terminology.
• docs/proposals/oracle_ambiguous_prompt_routing_recommendation.md remains a proposal for routing doctrine. Its routing recommendation is consistent with this document, but future implementation docs should cite the Governance Kernel as authority.
• Generated Sphinx and API HTML under docs/api/ and docs/_build/ contain historical text snapshots. They should not be treated as doctrine sources.

Deprecated Terminology

• Objective -> Skill -> Capability -> Provider -> Execution remains valid for objective governance metadata, but it is not the full canonical operational lifecycle. Use the Objective to Loop lifecycle when describing governed operational progression.
• Loop instance proposal and Loop proposal refer to the same canonical artifact class. Prefer Loop Proposal in architecture summaries and keep schema names unchanged.
• Zeus evidence expectations and Zeus Evidence should be distinguished: expectations define required proof; evidence packets or receipts carry supplied proof.
• Dispatch state should be expanded to LegionCommander / Creep Dispatch when describing authority ownership.
• Any Lich archival-memory wording is historical or speculative only. Current Lich authority is approval and governance gating.

Recommended Future Cleanup

• Add a short "Canonical Source" note to any future Objective, Loop, Oracle, Zeus, Lich, Clockwerk, LegionCommander, Creep, or LifeVault architecture page that restates this lifecycle.
• Convert proposal documents that have been adopted into historical rationale pages with explicit links to canonical architecture references.
• Consider a machine-readable governance-kernel manifest only after a separate schema phase is approved; this phase intentionally avoids schema changes.
• Rebuild generated API/Sphinx output only through the normal documentation generation workflow, not as part of manual doctrine adoption.