Skip to content

AncientOS Governed Capability Ontology

Era 6.5 introduces a canonical governed capability layer. A capability is a governed operational primitive, not a tool, route, provider, transport, or hidden executor. Providers expose implementation surfaces behind capability contracts; arbitration reasons over those contracts and never performs work.

Doctrine

  • Deterministic first: registry loading, validation, arbitration, degradation, and evidence rendering are stable for the same inputs.
  • Advisory first: arbitration returns reports only. It does not execute, mutate, route dynamically, delegate, or repair.
  • Governance bounded: approval, escalation, artifact, safety, and constitutional metadata are part of every capability contract.
  • Fail closed: unknown, invalid, degraded, forbidden, or policy-uncertain capabilities are denied by default.
  • Transport neutral: capability reasoning is independent of Discord, Naga, CLI, HTTP, or future transports.
  • Provider neutral: providers are bindings behind contracts, not first-class cognition targets.
  • Execution neutral: executor lanes may satisfy a governed capability after approval, but the capability layer does not invoke them.
  • Replayable: arbitration reports include deterministic evidence sufficient for simulation and comparison.

Contract Fields

Each capability contract defines:

  • capability_id: stable canonical identifier, for example capability.plan.preview.
  • capability_class: semantic primitive class such as observation, retrieval, planning, inference, routing, simulation, mutation, publication, escalation, or evaluation.
  • governance_class: none required, audit only, approval gated, human review, constitutional review, or forbidden.
  • execution_class: none, read only, proposal only, simulation only, approval-bound mutation, external provider call, or transport publication.
  • safety_class: observational, read only, low risk, state mutating, external side effect, constitutional risk, or forbidden.
  • replayability_class: fully replayable, decision replayable, evidence replayable, non-replayable, or simulation only.
  • provider_bindings: required or optional provider surfaces behind the contract.
  • transport_neutral: whether reasoning is independent of transport-specific payloads.
  • artifact_requirements: artifacts required before a downstream caller can perform or audit the capability.
  • approval_requirements: approvals required before downstream mutation or publication.
  • escalation_requirements: deterministic governance escalation conditions.
  • degradation_semantics: how the contract behaves when inputs, providers, or evidence are missing.
  • simulation_eligible: whether decisions can be replayed safely in simulation.
  • constitutional_risks: advisory Zeus supervision metadata.
  • dependencies: other canonical capability IDs required by the contract.
  • alternative_ids: safer, read-only, or simulation paths arbitration may surface.
  • forbidden: explicit fail-closed marker for non-goals and doctrine violations.

Canonical Examples

capability.observe.runtime_state is observational, read-only, fully replayable, transport neutral, and approval-free. It produces source-bound observation reports and fails closed on missing evidence.

capability.plan.preview is proposal only. It can explain a plan and governance implications, but it cannot delegate, execute, or mutate. Mutation steps require a separate approval-bound capability.

capability.infer.provider_role is provider-backed but provider-neutral at the cognition layer. It records role, policy decision, and prompt digest artifacts. Provider outages degrade to no model call.

Era 8 extends this capability with a role registry and provider arbitration substrate in app/inference/*. Inference roles declare allowed local and frontier providers, structured-output eligibility, cost class, fallback policy, replay metadata requirements, forbidden uses, and degradation behavior. The capability remains advisory-only: model portability does not create execution, approval, mutation, routing, or truth authority.

capability.execute.confirmed_lane represents existing approval-bound executor lanes. It requires governance preview and explicit operator confirmation. If approval or executor readiness is missing, arbitration offers capability.plan.preview or simulation instead.

LifeVault-related capability records should describe memory continuity: durable memory authority, review/promotion provenance, retrieval eligibility, supersession/deprecation state, archive lifecycle, and fragmentation risks. They should distinguish LifeVault from pgvector/Postgres, SQLite, files, artifacts, audits, Discord history, Oracle evidence, Rubick ontology, Meepo transition data, and provider outputs. Storage and evidence surfaces may support memory, but they are not memory authority.

Rubick-related capability records should describe posture continuity: governed settings, ontology visibility, prompt/profile posture, cognitive modes, runtime abstraction, and continuity-safe configuration across changing infrastructure.

Chen-related capability records should describe workflow orchestration: multi-step app/domain planning, capability coordination, and delegation to Rubick, Oracle, Lich, Tinker, and domain adapters. Chen records must not describe Chen as kernel governance, approval authority, policy enforcement, audit/replay authority, or merely the media app. Media Manager is Chen's first active domain and remains read-only until Lich approves mutation.

Meepo-related capability records should describe transition integrity: fail-closed revalidation that checks assumptions, approvals, context, output bounds, and execution scope before trust is carried into the next state. Meepo records must not describe Meepo as orchestration, planning, routing, policy evaluation, approval orchestration, or generic middleware.

capability.autonomy.recursive_execution is registered as forbidden so doctrine violations can be detected, explained, refused, and supervised. It is not approvable.

Arbitration Flow

  1. Load the file-backed registry deterministically from docs/machine/capability-ontology.json.
  2. Validate ontology classes, unique IDs, dependencies, alternatives, provider bindings, and governance requirements.
  3. Resolve the requested capability or select the first deterministic candidate matching requested classes.
  4. Evaluate policy constraints: forbidden status, governance class, mutation permission, provider readiness, degradation state, transport coupling, and simulation constraints.
  5. Surface safer, read-only, and simulation alternatives.
  6. Return a governed arbitration report with selection rationale, rejected alternatives, evidence requirements, approval and escalation requirements, replay implications, provider dependencies, degradation state, and constitutional risks.

The engine does not execute work. It only returns the report.

Governance Interactions

  • Approval-gated capabilities remain allowed only as governed decisions; downstream execution still requires explicit approval artifacts.
  • Unknown capability IDs return fail-closed reports.
  • Missing required providers deny provider-backed capabilities and surface alternatives.
  • Mutation requests without mutation permission deny the mutating capability and prefer read-only or simulation alternatives.
  • Forbidden capabilities always deny and emit Zeus advisory hooks.

Replay Examples

Arbitration reports contain stable request IDs derived from request content, selected capability IDs, deterministic denial reasons, sorted alternatives, required evidence, and policy warnings. Simulation systems can replay the same request against the same registry and compare the report without calling providers or mutating runtime state.

Oracle Visibility

Oracle receives read-only visibility into:

  • registered capability contracts
  • governance and approval requirements
  • provider readiness expectations
  • degradation states
  • capability conflicts
  • arbitration explanations supplied by callers
  • Zeus advisory warnings
  • readiness graph dependencies and downstream risk propagation
  • transport-neutral dashboard cards and panels
  • evidence-index replay hashes
  • operational topology nodes and dependency edges
  • degradation lineage reconstructed from supplied operational snapshots
  • readiness drift and stable-state comparison reports
  • governance risk warnings derived from capability contracts
  • bottleneck analysis and safe inspection recommendations
  • Zeus advisory hook metadata with no authority transfer

Oracle remains read-only and never becomes source of truth or repair authority. Provider-dependent capabilities remain blocked or unknown until explicit provider readiness evidence is supplied; Oracle does not invent healthy provider state.

Future Zeus Integration

The ontology includes advisory hooks for:

  • doctrine drift warnings
  • forbidden capability detection
  • unsafe composition detection
  • provider overreach warnings
  • transport-coupling warnings
  • escalation creep warnings

Zeus hooks are metadata only. They do not auto-repair, auto-block beyond local policy, or create supervision authority inside the capability layer.

Future Underlord Integration

Underlord can consume arbitration reports as bounded governance artifacts for future evaluation, simulation, and quality scoring. It should compare decisions, evidence requirements, degradation behavior, and planner choices without invoking providers or executor lanes directly.

For inference, Underlord approval metadata is required before paid frontier providers can be selected unless a role is explicitly inside a bounded no-approval budget. Silent paid fallback and open-ended token spend are forbidden.

Relationship To Coordination Cognition

The coordination cognition substrate consumes capability contracts through the file-backed ontology and arbitration semantics. Capability composition analysis is fail-closed: unknown IDs, forbidden capabilities, mutation-capable chains, provider-owned orchestration risk, and transport-coupling risk remain warnings or blockers inside reports, never execution authority.

Coordination proposals may reference safer alternatives such as capability.plan.preview or capability.simulate.governance_policy, but the proposal layer cannot invoke those capabilities. Capability visibility remains separate from capability authority.

Relationship To Operator Routing

Capability-inspection requests in Luna route through operational cognition and Oracle visibility. They do not imply capability invocation. Requests that ask to execute or mutate with a capability remain outside capability inspection and must pass through explicit governance and approval paths.

Migration Notes For Historical Runtime Naming

Historical names such as router, executor, lane, provider, adapter, memory, Oracle, and planner remain valid implementation or subsystem terms. New cognition and governance surfaces should reference canonical capability IDs when reasoning about what is being requested. Existing runtime names should map to capability contracts instead of being treated as raw authority.