AncientOS Governed Capability Portfolio

Status: canonical operator-facing roadmap view.

The adoption authority and detailed capability standard are the Governed Capability Portfolio roadmap. The canonical lifecycle and posture vocabulary is defined by the Architecture and Capability Posture Taxonomy. This page renders those authorities as one practical view for operators. It is not a second roadmap authority.

Current roadmap position

AncientOS completed its previously adopted numbered-era sequence through Era 8. Era 7 delivered Oracle Operational Ergonomics. Era 8 delivered the first Governed Capability Portfolio. Those names remain historical implementation programs and completion evidence.

There is no active numbered era. Era 9 is not adopted. AncientOS no longer advances by automatically opening another numbered era, stage, or phase. Future work enters the active portfolio only through an explicit adoption decision for a bounded capability.

Current portfolio state:

Portfolio view	Current truth
Adopted work awaiting implementation	Keeper exact-task completion lifecycle consolidation
Work in progress	None; Media objective milestone completed
Blocked adopted work	None
Proposed work awaiting an adoption decision	None
Candidate work	Present; non-authoritative options are listed below
Deferred work	Present; reconsideration conditions are explicit
Active numbered era	None
Adopted Era 9	No

The adopted Keeper exact-task slice remains outstanding. Media's governed objective milestone is complete at commits 62fb131, 019d900, and d914f2a; remaining device and delivery limitations are bounded follow-ups.

The current program sequence and recovered work register separate NOW, NEXT, product, migration, research and completed work. The highest leverage next objective is Keeper exact-task completion lifecycle consolidation, which retains its existing adoption. Broad capability-backed read-only cognition is implemented with bounded source coverage through the shared intent boundary; see its architecture and limitations. Recommendations remain advisory and do not authorize execution.

What AncientOS is

AncientOS is a transport-neutral governed operational cognition platform for controlled, inspectable, single-operator use. Luna is an interactive application and interface over AncientOS; it is not the kernel itself.

AncientOS Platform v1 Alpha supplies reusable runtime and governance primitives:

the shared Runtime Kernel and Runtime Composition;
durable Kernel Records and restart-safe explainability;
deterministic Governed Proposals;
durable, exact-action Lich approval;
separate bounded execution;
Zeus evidence and execution or rollback receipts;
rollback or explicit compensation boundaries;
transport-neutral routing across Discord, Terminal TUI, and Web TUI;
Rubick capability and dependency posture;
Oracle inspection, synthesis, recommendation, queue, validation, and audit;
LifeVault memory authority and provenance;
Meepo transition revalidation;
read-only Spectre terminal observation.

The platform preserves governed execution boundaries. Typed mutation lanes and Clockwerk/Io observation exist; they grant no general shell, Docker, Git-update, package-manager, arbitrary network-write, broad-delete, or autonomous authority.

Portfolio lifecycle

Portfolio lifecycle is a decision record, not a readiness score:

State	Meaning
`candidate`	A bounded option identified for analysis. It is not authorized work.
`proposed`	A documented adoption packet awaits an explicit operator decision.
`adopted`	The operator approved the capability for implementation, but implementation has not started.
`in_progress`	Work 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 removed the item from active consideration until stated conditions change.
`rejected`	The operator explicitly declined the proposal; reconsideration requires a new proposal.
`historical`	Retained provenance from a retired roadmap vocabulary or completed planning program.

Only an explicit operator decision can move a capability into adopted. Oracle may report facts, risks, gaps, and recommendations. Rubick may report capability posture and dependency state. Neither may silently adopt, reorder, or activate portfolio work.

Roadmap adoption and runtime mutation approval are separate decisions. Adopting a capability authorizes bounded implementation work; it does not approve any live mutation. Every meaningful mutation remains separately Lich-gated at the exact-action boundary.

Independent capability posture

Portfolio state never substitutes for technical posture. Every capability is described independently along these dimensions:

implementation: whether bounded code exists;
integration: whether required services and consumers are wired;
operator reachability: whether a documented operator route reaches the contract;
authority: advisory, read-only, proposal, approval, execution, evidence, memory, transport, or application boundaries;
persistence: durable, process-bounded, ephemeral, external, or not applicable;
evidence strength: source-only, unit, integration, runtime smoke, or live external validation;
operational health: current configured, injected, observed, degraded, disabled, unavailable, or unknown state.

Implementation does not prove wiring. Injection does not prove route reachability. Fixture validation does not prove a credentialed integration. A provider call does not prove reconciled success. A roadmap decision grants no runtime authority.

Completed foundations

Governed Meeting Intelligence vertical slice

The operator-authorized Meeting Intelligence capability is implemented as a capability-local vertical slice rather than a new platform era. It reuses the shared Runtime Kernel, LifeVault artifact authority, Rubick posture, governed inference, Keeper/Lich proposal path, and transport-neutral rendering. The bounded acceptance surface is transcript import and query; optional Meetily or other workstation capture remains an edge-producer integration, not an AncientOS authority or bundled capture implementation.

These are verified foundations, not active work:

Foundation	Portfolio state	Verified outcome	Important boundary
AncientOS Platform v1 Alpha	`complete`	Transport-neutral governed runtime, durable records, approval, evidence, receipts, explainability, and transport parity	Alpha for controlled use; not production
Oracle Operational Ergonomics	`complete`	Operator inspection, queue, preflight, proposal intake, explicit apply vocabulary, and audit	Oracle delegates to existing services; no approval or execution authority
Governed configuration-value edit	`complete`	Registered non-secret scalar inspection, proposal, execution, evidence, exact rollback, and restart continuity	Default disabled; named target and allowed-value configuration required
Governed atomic file rename	`complete`	Registered no-overwrite regular-file rename with evidence and exact reverse rollback	Default disabled; allowlisted disposable workspace only
Governed Home Assistant light state	`complete`	Registered `light.*` on/off proposal, reconciled receipt, and separately approved compensation	Era 8 used a fake provider; no credentialed live device validation
Governed capability discovery	`complete`	Oracle lists and inspects the implemented portfolio from Rubick evidence	Discovery does not grant capability authority
Governed inference registry and model selection	`complete` for the current production boundary	Canonical local/frontier targets, freshness-bound evidence, truthful inventory, request/session selection, restore/reset, provider disambiguation, and transport-neutral natural language	xAI and llama.cpp live-validated; outbound OpenAI unconfigured; persistent defaults and autonomous routing absent; cognition never changes authority
Media governed objective lifecycle	`complete` for the demonstrated vertical slice	Natural objective through approval, acquisition, completion, Plex verification, durable return, Pixel delivery and named-room playback	Cold/profile-bound device actuation, exact-episode identity and fresh post-repair replay/Push acceptance remain bounded follow-ups
Media episode inventory	`complete` for the current read-only slice	Canonical TVmaze series identity, scoped aired-episode comparison, bounded Plex missing/extra diagnostics, and transport-neutral routing	No acquisition discovery, downloading, filesystem mutation, Plex refresh, scheduling, or approval authority
Media acquisition discovery	`complete` for the current read-only slice	Canonical missing-episode target, hostile candidate normalization, hard eligibility, deterministic deduplication/ranking, and bounded recommendation evidence	Original read-only acceptance boundary; later governed multi-provider acquisition and completion are delivered separately
Spectre terminal observation	`complete` for terminal v1	Explicit `spectre-shell` production, redaction, ingestion, binding, and Oracle explanation	No SSH interception, hidden capture, screen capture, or execution authority
Governed experiential-learning foundation	`complete` for the current advisory contract	Evidence-backed LifeVault assertions, deterministic scoped snapshots, post-boundary LegionCommander advice, and replay provenance	LegionCommander is the only consumer; no confidence, ranking, automatic promotion, cross-domain transfer, routing, readiness, approval, or authority effect

Era 7 and Era 8 are historical program labels attached to the relevant completion evidence. They do not create progression gates for future capabilities.

The authoritative completion boundary and classification of remaining inference ideas are recorded in the Governed Capability Portfolio roadmap. Those future and deferred items are not active work and have no implied order.

Currently adopted portfolio

The Keeper exact-task completion adoption contract is adopted and awaits implementation. It covers one exact task completion through the canonical durable lifecycle. Adoption authorizes implementation, not any task mutation; each runtime action remains separately Lich-gated.

The Chen watch-loop plan is historical lineage for the completed Media milestone. See the canonical roadmap for current follow-ups; its original excluded playback/provider scope was extended by later explicit operator work.

An implementation must not begin merely because a candidate appears in this document or because Oracle or Rubick ranks it favorably.

Candidate capabilities

Candidates are non-authoritative options. Their presence records analysis, not commitment, order, readiness, or permission to implement.

Candidate	Operator outcome	Existing evidence	Adoption gaps
qBittorrent pause/resume	Pause or resume one exact observed torrent	Read-only adapter and Chen provider experience	Exact hash policy, durable portfolio proposal/evidence/receipt lifecycle, reconciliation, provider configuration
Read-only service diagnostics	Explain service degradation from bounded evidence	Beastmaster and Oracle inspection surfaces exist	Exact operator outcome, evidence freshness, provider boundaries, no-remediation guarantee
Optional inference follow-ons	Benchmarking, provider/role reconciliation, additional providers, multimodal/long-context policy, session cleanup/history, Ollama repair, egress/accounting, or per-model metrics	The governed registry/selection initiative is complete; its authoritative follow-on table records each item separately	A future session must adopt one bounded outcome; the grouped row is not a program or priority queue

No candidate has an implied priority. Adoption analysis must evaluate operator value, scope, dependency evidence, reversibility or compensation, blast radius, testability, provider configuration, and authority boundaries at the time of decision.

Deferred capabilities

Deferred capability	Why it is deferred	Reconsider only when
General allowlisted container restart	Large Docker-socket authority and weak reversal semantics; the adopted typed `recover_gluetun_vpn` exception grants no generic target selection	A separate typed target contract, health convergence, uncertainty receipts, and safe fixture acceptance exist for each additional invariant
Compose deploy or recreate	Combines build, images, networking, volumes, and service health	A separately governed deployment program is explicitly adopted
Fast-forward-only Git update	Remote trust, signatures, dirty-tree, divergence, and rollback policy are unresolved	Repository trust and recovery contracts are adopted and tested
Package or system update	Root authority, network trust, reboot impact, and downgrade uncertainty	Isolated host validation and reliable rollback evidence exist
Broad delete or data removal	Irreversibility and retention risk	A quarantine-first capability proves bounded identity, retention, capacity, and restoration
General scheduler	Creates durable unattended execution and cancellation concerns	One adopted capability demonstrates a narrow, cancelable scheduling need
Autonomous remediation	Conflicts with current explicit human governance	A separate operator decision changes doctrine; no such decision exists
General shell or command executor	Authority is too broad for typed governed outcomes	Not anticipated; prefer bounded typed capabilities
Governed experiential confidence/reinforcement	Evidence-backed ranking semantics, reinforcement identity, governance, and replay are unresolved	Real certified experience has accumulated; missing exact evidence adapters are justified; and a dedicated architecture review defines independent evidence, scope, correlation, contradiction, freshness, deterministic ranking, mutation governance, explainability, and the authority firewall
Deferred inference automation and mutation	Persistent defaults, automatic routing/fallback, LegionCommander choice, background monitoring, model lifecycle, and updates require governance not present in the completed registry contract	The exact prerequisite for each item in the authoritative inference completion table is met and the operator adopts that bounded capability

Deferred items are not a queue. Their order carries no meaning.

The experiential foundation is complete, but confidence and reinforcement are not implemented or adopted. The canonical roadmap authority defines the required planning gate and a non-authoritative reconsideration sequence. No Rubick capability or additional advisory consumer is implied.

Known portfolio gaps

The following gaps are observations, not adopted work:

capability posture metadata is richer for the Era 8 portfolio than for some legacy Rubick records;
external-provider freshness and reachability are evaluated at request time rather than universally persisted;
Home Assistant lacks credentialed live-provider acceptance evidence;
canonical principals and enrolled device sessions are implemented; a general multi-user or cross-instance cryptographic identity model is not established;
LifeVault ordinary conversational retrieval is not composed into the default runtime pipeline;
Spectre conversation bindings are process-bounded and live screen capture is unavailable;
Zeus durable evidence is complete for Governed Actions but not universal across every subsystem;
legacy application-specific mutation lanes do not all use the canonical portfolio lifecycle.

Closing a gap requires explicit scope and adoption. A gap report is not an implementation instruction.

Capability adoption process

Identify one bounded operator outcome as a candidate.
Document its identity, scope, dependencies, provider configuration, authority requirements, persistence, evidence requirements, rollback or compensation classification, risks, and acceptance criteria.
Ask Oracle and Rubick for advisory evidence, dependency, conflict, and posture analysis when useful.
Produce a proposed adoption packet that names the exact capability and preserves unresolved gaps.
The operator explicitly adopts, defers, or rejects the proposal.
Adoption places only that capability into the active portfolio. It does not alter Lich, Zeus, Oracle, Rubick, Meepo, Spectre, LifeVault, transport, or provider authority.
Move adopted work to in_progress only when implementation begins. Record named blockers rather than inventing substitute work.
Record source, unit, integration, runtime smoke, and live external evidence honestly. Fixture, local, credentialed, and live-provider validation remain distinguishable.
Declare complete only when the adopted acceptance criteria and required repository-wide validation pass.
Preserve the proposal, adoption decision, evidence, completion record, and any superseded historical material.

An adoption decision should state:

capability ID and operator outcome;
decision actor and date;
exact scope and non-goals;
dependencies and provider requirements;
authority and approval boundaries;
persistence and restart behavior;
evidence and acceptance requirements;
rollback, compensation, or non-reversibility;
security and privacy risks;
compatibility impact;
conditions for completion, deferral, rejection, or reconsideration.

Authority boundaries

Oracle

Oracle reports facts, observations, inferences, risks, gaps, and recommendations. It may render the portfolio and an adoption packet. It may not adopt work, mutate roadmap state, approve a capability, execute a capability, or create a separate governed lifecycle.

Rubick

Rubick is the capability and dependency posture authority. It reports evidenced implementation, wiring, reachability metadata, authority, persistence, evidence, configuration, and limitations. Registration is not readiness and Rubick does not grant execution or approval authority.

Lich

Lich approves or rejects exact governed mutations. Portfolio adoption does not pre-approve implementation outputs or live actions.

Zeus

Zeus owns governed execution evidence and receipts and provides bounded supervision evidence. Zeus does not adopt roadmap work, approve actions, or execute providers.

Meepo

Meepo revalidates transition assumptions across approval-scoped state changes. It does not choose work, approve, execute, or create authority.

LifeVault

LifeVault is durable memory authority. Portfolio documents and Oracle reports do not become long-term memory merely by existing; memory promotion retains its governed provenance and review requirements.

Spectre

Spectre observes and normalizes attributable terminal evidence. It cannot control a terminal, intercept SSH, capture hidden screens, approve, execute, or certify success.

Validation language

Use these distinctions:

fixture validation: deterministic fake or fixture provider;
local validation: real local process or disposable workspace without a credentialed external service;
credentialed integration validation: authenticated external API exercised in a bounded environment;
live-provider validation: the intended external provider and target were exercised and the result reconciled safely.

The strongest evidence recorded for a claim must match what was actually tested. Era 8 Home Assistant acceptance is fixture validation and a shared-runtime smoke test, not credentialed or live-provider validation.

Historical numbered-era record

AncientOS previously organized work using numbered eras and sub-era phase labels. That sequence is closed.

Historical program	Historical outcome
Eras 0–4	Early runtime, subsystem, artifact, orchestration, and integration foundations
Era 5	Governed live-execution concepts; implementation landed through several later bounded lifecycles rather than one completed scalar program
Era 6 and sub-era labels	Memory, interoperability, cognition, and validation foundations; individual surfaces have independent current posture
Era 7	Oracle Operational Ergonomics, complete
Era 8	Governed Capability Portfolio, complete
Era 9 and later numbered headings	Never adopted candidates or historical planning vocabulary

Root ERA*_PLAN.md files and superseded proposal documents remain provenance. Their numbering, stages, phases, priorities, and “next” language do not govern current work.

Canonical sources

Documentation Reality and Status classifies authorities, supporting pages, historical records, and generated output.
Architecture and Capability Posture Taxonomy defines portfolio lifecycle and independent posture dimensions.
Governed Capability Portfolio roadmap governs adoption and the capability standard.
Durable Governed Actions defines the implemented mutation lifecycle.
Runtime Composition reports current process wiring without unsafe probes.
Rubick reports capability posture; verified source and tests remain implementation evidence when authored documentation drifts.

No generated page, component knowledge file, historical era plan, model recommendation, or runtime summary is an independent roadmap authority.

Rote design knowledge

The preserved Rote corpus is now part of the repository's authoritative design documentation. P1 in the canonical portfolio records reconciliation, decisions and dependencies. Universal semantics are Core conceptual concerns; Apps may specialize domain Rotes without owning universal authority. The adopted reconstructed addendum's provenance remains explicit. The first bounded informational exchange is implemented in 79dc3628b5e1627c7e9aec29bc6f903c9c1b6ca7. Relationship-scoped exchange with no public advertisement is the near-term posture; wider discovery and effectful Rotes remain deferred. Project-corpus reads and narrow source establishment have deployed evidence; broad planning remains separately incomplete. The next recommended product slice is governed read-only inspection of one received informational Rote, including its provenance and restrictions. Keeper exact-task completion remains the adopted development slice.