Capability Availability and Reachability Truth
AncientOS uses one operation-aware truth contract to distinguish capability registration from current operator availability. Rubick remains the canonical static registry. Oracle projects current truth by combining Rubick facts with fresh, bounded evidence supplied by runtime, provider, executor, authority, and transport surfaces. Neither component receives execution authority.
Operational capability intelligence
Oracle derives provider/service summaries from the same operation-aware capability records used for individual answers. Registration, configuration, dependency reachability, runtime readiness, operator and transport reachability, and per-capability availability remain distinct. A provider is healthy only when every capability in the bounded live projection is available; mixed results are degraded, uniformly unavailable results are unavailable, and registration without fresh evidence is unknown. Aggregation is a canonical view, not a second health store.
The Home Assistant adapter observes only existing REST state discovery. Missing URL/token configuration and failed reachability fail closed, and secret values never enter evidence. The only represented mutation is the implemented allowlisted light set-state lifecycle; readiness never grants execution and an exact-bound Lich approval remains required.
The Meeting Intelligence adapter reads composed LifeVault-backed service status. It distinguishes runtime readiness from stored-data availability: an empty store is a healthy service with no meeting data, not a failed dependency. Inspection, search, summary, and extraction remain read-only/advisory. Import, local transcription, and evidence-linked follow-up proposals retain their existing separate contracts. Meeting speech grants neither execution nor external-communication authority.
approval_projection is a read-only counterfactual:
available_now, blocked_only_by_approval,
approval_and_other_blockers, approval_cannot_help, or unknown. It never
creates a review, approves, executes, or loosens exact binding. Valid approval
remains bound to the operation/action identity, target, proposal and
preconditions, fingerprints, and expiry required by Lich. Pending-review
visibility uses explicit operation mappings only; ambiguous reviews fail
closed. Approval is one dimension of capability truth, not a substitute for
operational readiness.
Future adapters register exact capability IDs, emit bounded fresh dimensions, reuse safe family probes only within a request, omit secrets, and fail the affected family closed without breaking other results. Oracle stays provider-neutral and only groups and renders canonical records.
Canonical chain
operator request -> transport -> shared router -> governed capability surface
-> Rubick registration -> configuration -> dependency/provider -> runtime/executor
-> requested-operation authority/Lich -> effective availability
Each link remains independent in capability-truth-v1: registered,
configured, dependency_ready, runtime_ready, operator_reachable,
transport_exposed, and authorized. The authority state distinguishes
read-only, proposal-only, approval-required, pending, approved, prohibited,
unsupported, and unknown. Effective availability is available,
approval_required, degraded, unavailable, or unknown.
The requested operation is inspect, propose, approve, or execute.
Read-only availability never implies mutation availability. Only existing Lich
lifecycle evidence can alter approval state; inspection cannot create or
resolve an approval.
Evidence and freshness
CapabilityEvidence records a content-addressed evidence ID, source,
dimension, tri-state result, observed_at, bounded maximum age, and bounded
non-secret reason. Dynamic evidence outside its freshness interval is ignored
and the record is marked stale. Missing or stale evidence yields unknown; it
is never inferred as ready.
On-demand projection is preferred. No background polling is introduced. The initial Oracle adapter proves only the Rubick registry surface exercised by the current request. Other registrations remain unknown until their governed surfaces supply configuration, dependency, runtime, route, and transport evidence.
Inference model inventory participates through
capability_truth_evidence_from_model_inventory. It projects configuration,
provider reachability, and bounded model readiness into the same evidence
contract without selecting or switching a model.
Authority boundaries
- Rubick owns static definitions, not live probes. Legacy list/get records now state that operational availability requires a truth projection.
- Oracle reads and renders truth. It does not approve, execute, or mutate.
- Existing Zeus-style evidence remains authoritative; adapters normalize bounded references instead of creating a parallel evidence store.
- Lich remains approval authority. Truth records mirror lifecycle state and grant nothing.
- Transports contribute request-local exposure evidence, not business logic.
Capability author contract
Every new Rubick capability must:
- define stable identity, domain, providers/consumers, observational and mutation posture, and authority metadata;
- treat
implementedandwiredas static facts, never live readiness; - expose non-secret configuration, dependency, runtime, route, and transport observations with timestamps, freshness, deterministic reasons, and inspectable evidence references;
- project operations separately where their readiness or authority differs;
- reuse Lich and Zeus patterns rather than parallel authority/evidence stores;
- test unconfigured, unhealthy, no-route, stale, transport-specific, approval-bound, prohibited, and negative-routing cases; and
- perform deployed acceptance through affected shared surfaces.
Incomplete evidence remains unknown or unavailable. Registration visibility
is never authority.
Live evidence adapters
Oracle resolves current capability truth through the explicit
LiveEvidenceAdapterRegistry. An adapter implements the observational
CapabilityEvidenceAdapter.observe(LiveEvidenceRequest) contract and returns a
LiveEvidenceResult containing canonical CapabilityEvidence, an optional
exact-bound Lich lifecycle state, and a bounded route identifier. Adapters do
not define a parallel status schema.
The request identifies the canonical capability ID, requested operation,
transport, and observation time. Evidence describes configuration, dependency
readiness, runtime readiness, operator reachability, and transport exposure.
Every observation has an explicit maximum age. Missing adapters and stale
observations remain unknown; Rubick registration is never substituted for
live evidence.
Registry bindings are explicit and deterministic. Multiple adapters may be bound to one capability when independent dimensions apply, such as Keeper runtime readiness plus Lich approval state. Family adapters may opt into request-local probe reuse when one observation safely describes all bound capabilities. No persistent polling or uncontrolled readiness cache is used. An adapter exception affects only its bound capability and produces bounded unknown evidence.
Current families are:
- Plex / Media: existing Plex read-only identity and service-status inspection for media status, episode availability, and media request resolution.
- Keeper: a bounded
GET /taskspreflight for task inspection and task-create readiness. It never calls Keeper mutation endpoints. - Beastmaster: the allowlisted
system_overviewread-only probe group without snapshot writes. It does not imply arbitrary shell or service control. - Lich: read-only approval-store projection. Matching is allowed only for an explicit capability-to-operation-type binding; a loose subsystem approval is not treated as authority.
Lich state is projected as approval required, pending, approved, declined,
expired, or invalid. A valid approval with a failed operational dimension is
blocked_after_approval; approval never manufactures registration, readiness,
reachability, or execution. Pending-state inspection does not expire, approve,
decline, create, or otherwise mutate Lich records.
Adapter evidence is request-local and content-addressed by the existing
make_capability_evidence function. It is not automatically persisted as a
Zeus record. This avoids producing durable audit noise for harmless repeated
readiness checks. Actual governed runtime inspections and mutations retain
their existing Zeus and Kernel Record boundaries.
Adding an adapter family
- Reuse a bounded read-only health, readiness, status, or preflight surface.
- Implement
CapabilityEvidenceAdapterand return canonical evidence with a short freshness window and redacted failure reason. - Bind canonical Rubick capability IDs explicitly in Runtime Composition.
- Declare family probe reuse only when the observation is capability-neutral.
- Add tests for healthy, unavailable, exception, freshness, transport, operation, authority, no-mutation, and full Oracle rendering paths.
- Rebuild the deployed runtime and verify the real affected transports.
Oracle may select adapters, combine their observations, classify truth, and render bounded explanations. Oracle may not execute the inspected capability, grant authority, create or resolve approvals, heal dependencies, expose credentials, or turn registration metadata into availability.