Skip to content

Rubick Capability Registry

Rubick is the AncientOS kernel service for continuity posture, capability reasoning, repository reasoning, relationship reasoning, settings, and configuration visibility. The capability registry extends that service with a deterministic machine-readable map of kernel services, applications, Chen workflow orchestration, domains, capabilities, dependencies, providers, consumers, readiness states, integration states, configuration references, and evidence references.

Rubick stores the system map. Oracle may synthesize supplied Rubick evidence. Lich governs authority-bearing changes to the system map. Zeus defines evidence expectations for governed changes. Roshan and Tinker may execute approved changes only through their governed lanes. Beastmaster supplies host/runtime facts, not repository reasoning.

Chen is represented as the app-layer workflow orchestration framework, not as kernel governance. Media Manager is represented as Chen's first active domain. External services such as Bitmagnet, Plex, qBittorrent, and Deluge are adapter surfaces behind domain workflows, not kernel concepts.

Boundary

Rubick answers:

  • what exists
  • what is enabled
  • what depends on what
  • what provides what
  • what consumes what
  • what is configured
  • what is implemented, partial, planned, disabled, deprecated, or aspirational
  • what repository files, imports, dependencies, and graph relationships may be impacted when supplied read-only evidence is available

Rubick must not answer:

  • what should be built next
  • whether a roadmap idea is good
  • which option is strategically best
  • how the system should redesign itself
  • how to bypass Lich, Roshan, Tinker, or any governed change path

The registry does not call LLMs, run agent loops, execute changes, start background jobs, mutate runtime state, wire Oracle, query Beastmaster, query LifeVault, or inspect live Docker/git state.

Stored Data

The file-backed artifact is rubick_capability_registry.json under Rubick's configured artifact root. It contains:

  • components: stable AncientOS component records.
  • capabilities: stable capability records with readiness and integration status.
  • providers: component-to-capability provider relationships.
  • consumers: component-to-capability consumer relationships.
  • dependencies: component-to-component dependency edges.
  • configuration_refs: references to Rubick settings or feature flags.
  • evidence: documentation or test references supporting a claim.

Status values are constrained. Readiness is one of implemented, partial, planned, disabled, deprecated, or aspirational.

Oracle Consumption

Oracle can later consume Rubick exports as read-only input:

  • export_capability_map_json() for the full system map.
  • export_dependency_graph_json() for graph-shaped component dependency data.
  • lookup APIs such as get_component(), get_capability_providers(), and find_integration_gaps().

Those APIs return facts and explicit gaps. They do not recommend priorities or choose strategy.

Beastmaster Relationship

Beastmaster remains the host-awareness producer. Rubick records that Beastmaster provides host_awareness and structured_host_awareness.

The current seed registry explicitly records the known gap: Beastmaster provides structured_host_awareness, Oracle may consume it later, and the integration status is provider_implemented_consumer_not_wired. This makes the gap inspectable without wiring Oracle or turning Rubick into a planner.