Architecture and capability posture taxonomy

Status: canonical.

This page defines how AncientOS documentation and reporting describe present implementation. It prevents the word “ready” from collapsing independent facts about code, wiring, operator access, authority, persistence, and validation. Use the values below together. A document may use a shorter summary only when it links here and states the material limitations.

Documentation authority

When claims conflict, use this order:

1. AGENTS.md governs engineering process, safety, and authority invariants.
2. docs/documentation_status.md classifies documentation and identifies the roadmap adoption authority and canonical architecture pages.
3. The governed capability portfolio roadmap governs adoption decisions and delivery; completed records govern their acceptance boundaries.
4. Canonical architecture and terminology pages govern component roles and contracts.
5. Rubick records and Runtime Composition report capability posture and actual process wiring. Neither registration nor injection alone proves usability.
6. Component knowledge files and README.md summarize canonical sources; they do not override them.
7. Historical roadmaps and root ERA*_PLAN.md files preserve design provenance only.
8. Tests and verified source code are implementation evidence. When authored documentation conflicts with them, verified implementation is the temporary source of truth and the documentation must be corrected.

Generated documentation is never an authored authority.

Cognition dependency posture

Capability metadata may declare cognition_requirements: stable references to model-facing knowledge packages. The references are part of Rubick's capability map; package prose and dependency traversal belong to the dedicated cognition layer described in Capability-driven just-in-time cognition. A cognition reference reports a reasoning dependency only. It cannot change any readiness, integration, authority, persistence, or evidence-strength dimension.

Roadmap lifecycle state

Roadmap lifecycle records operator decisions about work. It does not report technical readiness or grant runtime authority.

Value	Definition
candidate	A bounded option identified for analysis; not authorized work.
proposed	A documented adoption packet awaits an explicit operator decision.
adopted	The operator approved the capability for implementation, but work has not started.
in_progress	Implementation has begun under the adopted scope and acceptance contract.
blocked	Adopted work cannot progress until named evidence, dependency, policy, or product decisions are resolved.
complete	The adopted acceptance criteria and required validation are satisfied.
deferred	The operator intentionally made the item inactive until stated conditions change.
rejected	The operator explicitly declined the proposal; reconsideration requires a new proposal.
historical	Retained provenance from completed or retired planning vocabulary; not current work.

Only an explicit operator decision can create adopted work. Oracle and Rubick may report or recommend; neither may change lifecycle state. Roadmap adoption authorizes bounded implementation work, not a live mutation. Lich approval remains a separate exact-action decision.

Independent posture dimensions

Governed development delegation posture

Development planning is read-only/proposal-capable. Original intent and content-addressed LegionCommander plans are durable; review and implementation authorization are distinct Lich decisions. Codex rejects complete final instructions over 20,000 Python Unicode code points. Planning artifacts are not subject to that provider limit. See docs/governed_development_delegation.md.

Meeting Intelligence posture

The meeting capability family is implemented and wired through the shared Runtime Kernel. inspect_meetings, inspect_meeting, and search_meeting_transcript are read-only evidence retrieval. summarize_meeting, decision/commitment/action/question extraction are advisory cognition with segment references. propose_meeting_followups is proposal-capable only and delegates exact task creation to Keeper through Lich; it has no approval or execution authority. Canonical persistence is durable LifeVault artifact storage. Live edge capture is not bundled and producer connectivity remains unobserved.

Experiential knowledge posture

Experiential knowledge is a LifeVault-owned, evidence-certified form of advisory memory. It is distinct from episodic records of particular events, semantic information available for retrieval, deterministic evidence owned by Zeus or another supported receipt authority, and the governance decision that permits durable promotion. Certification establishes that evidence supports a scoped outcome; it does not establish authority or permission.

The implemented posture comprises certified experiential assertions, deterministic exact-scope snapshots, post-boundary injection into immutable LegionCommander plans, and replay provenance. LegionCommander is the only experiential advisory consumer. Experiential lookup occurs after deterministic request interpretation and task-graph construction and cannot affect intent, semantic routing, Rubick posture, Lich decisions, readiness, mutation or pending-action authorization, or executor selection.

Confidence, reinforcement, frequency ranking, and adaptive strategy weighting would be a separate future advisory derivation over certified evidence. They are not memory authority, evidence certification, or deterministic governance; none is currently implemented or registered as a capability. See the canonical portfolio roadmap for the required planning and authority firewall.

Implementation state

Value	Definition
implemented	The bounded contract has working source code. This does not imply wiring or operator access.
partial	A meaningful subset exists, but one or more stated contract boundaries are absent.
planned	Adopted future intent without a complete implementation.
historical	Retained provenance or retired vocabulary; not current intent or readiness.
deprecated	Still identifiable but superseded and not preferred for new use.

Integration state

Value	Definition
wired	Required service dependencies are composed for the stated path.
partially_wired	Some dependencies or consumers are connected, but the full stated path is not.
not_wired	Code exists without a composed consumer path.
not_applicable	The subject has no runtime integration requirement.

Injection proves only that an object or callback is present. A route is wired only when the intended consumer can reach it through the shared runtime.

Operator reachability

Value	Definition
operator_reachable	A documented operator route reaches the bounded contract.
internal_only	Code is callable by internal consumers but has no operator route.
fixture_only	The demonstrated path depends on a test fixture or fake provider.
unavailable	No usable path is currently evidenced.

A credentialed external provider is not live merely because its fake provider passes integration tests.

Authority class

Value	Definition
advisory	Interprets evidence or recommends; cannot authorize or mutate.
read_only	Observes or retrieves without state mutation.
proposal_capable	May construct or persist a proposed action, but cannot approve it.
approval_authority	May approve or reject an exact governed action.
execution_authority	May perform only its explicitly bounded action after governance checks.
evidence_authority	Owns canonical execution evidence and receipts.
memory_authority	Owns durable memory truth and its lifecycle.
transport	Normalizes and renders interaction; owns no business authority.
application	Delivers an operator outcome through platform authorities; authority depends on its composed services.

Interpretation is not authority. Observation is not mutation. Proposal creation is not approval. Approval is not execution. A changed screen or a provider response is not canonical execution evidence until the evidence authority records the verified outcome.

Persistence class

Value	Definition
durable	Canonical state survives ordinary process restart in the configured persistent store.
process_bounded	State lasts only for the current process.
ephemeral	Request- or operation-scoped state is intentionally transient.
external	State is owned by a provider outside AncientOS.
not_applicable	The subject owns no state requiring persistence.

An in-memory binding is never described as durable. External state and the durable AncientOS receipt describing it are separate persistence facts.

Evidence strength

Value	Definition
source_only	Verified by source inspection only.
unit_tested	Deterministic unit tests exercise the contract.
integration_tested	Tests exercise multiple real repository layers together.
runtime_smoke_tested	A bounded composed-runtime smoke test exercises the path.
live_external_tested	A credentialed external provider was safely exercised and reconciled.

Evidence strength is cumulative only when the stronger validation actually covered the claim. Fixture validation must not be reported as live_external_tested.

Operational health

Operational health is the current observation reported by Runtime Composition or request-time inspection:

Value	Definition
configured	Configuration is present; reachability is unverified.
injected	A dependency object or callback is composed; its target may remain unverified.
observed	A bounded inspection confirmed the stated local condition.
degraded	The path is present but one or more required conditions failed.
disabled	Policy or configuration intentionally prevents use.
unavailable	A required dependency or path is absent.
unknown	Evidence is insufficient to classify safely.

Operational health can change without a roadmap decision or code change.

Prepared actions and execution preflight

AncientOS exposes one transport-neutral, observational preparation view over existing governed mutation capabilities. A prepared action binds a capability and operation, exact target, normalized bounded parameters, provider/executor identity, authority policy, meaningful target precondition, evidence references, freshness window, conversation scope, and a content integrity hash. Meaningful changes produce a different action identity or invalidate its integrity. Prepared actions contain no credentials or provider tokens.

Preparation does not call a provider mutation endpoint, create a Keeper task, contact a meeting attendee, execute a host command, create or resolve a Lich review, or select a model. Orchestration is a separate coordinator that may persist an exact existing PendingAction proposal and request a Lich review; neither operation executes the proposed action. The request-local prepared-action cache is conversation-scoped and process-bounded; it is continuity, not LifeVault memory, Zeus evidence, a durable governed proposal, or execution authority. Creating a Lich review remains a separate governed mutation through an existing family lifecycle.

Execution preflight is also read-only. It recomputes canonical capability truth and combines registration, configuration, provider/dependency state, runtime/executor readiness, operator/transport reachability, proposal integrity, freshness, exact Lich binding, approval expiry, and applicable target preconditions. Its canonical classifications are ready_without_approval, ready_for_approval, approval_pending, approved_ready, blocked, stale, prohibited, and unknown. Approval is one dimension only. Future executors must require a fresh approved_ready result when policy requires Lich; an approved record alone is insufficient.

Keeper task creation and allowlisted Home Assistant light on/off actions are the mutation-capable integrations in this slice. Meeting action claims may provide evidence-linked text for a proposed Keeper task, but meeting evidence grants neither task creation nor external-contact authority. Beastmaster does not currently register a governed service-restart executor, so restart preparation reports unsupported and never falls back to arbitrary shell.

The first orchestration consumer is Keeper task creation. The canonical machine result explicitly separates unknown/unavailable capability, preparation failure, review required/pending/rejected, invalid approval, stale or blocked preflight, and execution_ready. Exact semantically equivalent requests reuse the durable PendingAction and Lich review. Orchestrated reviews use readiness-only resolution: approval is recorded, preflight is run again, and no executor is called. Existing legacy execute-after-approval pending actions retain their prior behavior.

Preparation is observational. Approval is authorization. Preflight proves current executability. Execution remains a separate governed step.

Compatibility with existing metadata

Rubick's stable readiness_status and integration_status fields predate this taxonomy. They remain backward-compatible summary fields. New or reconciled records place the independent canonical values in metadata using implementation_state, integration_state, operator_reachability, authority_classes, persistence_class, and evidence_strength. Legacy provider_implemented_consumer_not_wired maps to not_wired for the stated consumer; wired must still be evaluated with configuration and reachability rather than treated as a complete readiness claim.

Canonical platform posture

AncientOS is a governed operational cognition platform. AncientOS owns the transport-neutral governed runtime; Luna is an interactive application and operator interface over that runtime. Platform v1 Alpha establishes stable governed primitives. Current development is capability-first: capabilities consume proposal, Lich approval, separate execution, Zeus evidence and receipts, rollback or compensation, Kernel Records, Runtime Composition, explainability, and transport-neutral contracts.

The roadmap adoption authority is the Governed Capability Portfolio roadmap. Era 7 (Oracle Operational Ergonomics) and Era 8 (Governed Capability Portfolio) are complete historical programs. No numbered era is active and Era 9 is not adopted. No capability is currently proposed, adopted, in_progress, or blocked; candidates remain non-authoritative until an explicit adoption decision.

Selected verified posture

Subject	Implementation	Integration	Reachability	Authority	Persistence	Evidence
Oracle operational ergonomics	implemented	wired	operator_reachable	advisory, proposal_capable intake only	durable governed records; otherwise not_applicable	runtime_smoke_tested
Lich governed decisions	implemented	wired	operator_reachable through governed workflows	approval_authority	durable when composed with SQLite	runtime_smoke_tested
Zeus governed evidence and receipts	implemented for governed actions; broader supervision partial	wired for governed actions	internal_only plus Oracle audit rendering	evidence_authority	durable for governed actions	runtime_smoke_tested
Rubick capability posture	implemented	wired	operator_reachable	read_only posture authority	durable registry artifacts where configured	integration_tested
Spectre terminal observation	implemented	wired	operator_reachable after explicit spectre-shell production and binding	read_only	observations bounded; bindings process_bounded	integration_tested
Spectre screen observation	planned	not_wired	unavailable	read_only contract only	not_applicable	unit_tested contract
Governed inference registry and model selection	implemented for canonical local/frontier registry, evidence, inventory, request/session selection, restore/reset, and narrow natural language	wired through shared runtime and exact-target inference	operator_reachable through Web TUI, terminal, and Discord-equivalent transport paths	cognition-only advisory; no execution or approval authority	session selection durable; request overrides ephemeral; readiness TTL-bounded	live_external_tested for llama.cpp and xAI; repository-wide regression tested with known fixed-date fixture failures
Configuration-value edit	implemented	wired when configured and enabled	operator_reachable	proposal_capable; bounded executor has execution_authority after Lich approval	durable	runtime_smoke_tested
Atomic file rename	implemented	wired when configured and enabled	operator_reachable	proposal_capable; bounded executor has execution_authority after Lich approval	durable	runtime_smoke_tested
Home Assistant light state	implemented	partially_wired until provider configuration and request-time reachability succeed	fixture_only in Era 8 acceptance	proposal_capable; provider has bounded execution_authority after Lich approval	durable AncientOS lifecycle; state external	runtime_smoke_tested, not live_external_tested
LifeVault durable memory	implemented in bounded ingestion, review, promotion, and retrieval surfaces	partially_wired; ordinary conversational retrieval is not composed	mixed operator_reachable tools and internal_only runtime surfaces	memory_authority	durable canonical artifacts	integration_tested
Governed experiential knowledge	implemented for receipt-bound certification, exact-scope snapshots, and LegionCommander advice	wired to LegionCommander after deterministic planning boundaries	operator_reachable certification workflow; advisory consumption is internal_only	advisory; LifeVault remains memory_authority, Lich remains approval_authority for promotion	durable assertions, certification chain, snapshots, and plan projection	runtime_smoke_tested

Oracle does not own a second proposal lifecycle: it provides operator vocabulary, inspection, queue, validation, intake, apply delegation, and audit over the existing governed services. Meepo revalidates explicit transition assumptions; it does not approve, execute, select providers, or infer broad lifecycle authority.