Governed Capability Portfolio Roadmap

Status: canonical roadmap adoption authority and capability delivery standard.

This document governs how AncientOS capability work enters and leaves the active portfolio. The master portfolio view is the operator-facing summary. The Architecture and Capability Posture Taxonomy defines lifecycle and posture vocabulary.

AncientOS completed its numbered-era sequence through Era 8. No numbered era is active and Era 9 is not adopted. A capability appears here as a candidate only for analysis; it becomes authoritative work only after an explicit operator adoption decision is recorded.

Portfolio lifecycle

The canonical lifecycle states are:

• candidate: identified option, not authorized work;
• proposed: complete adoption packet awaiting operator decision;
• adopted: explicitly selected for implementation, not yet started;
• in_progress: adopted implementation has begun;
• blocked: adopted work cannot progress for named reasons;
• complete: acceptance criteria and required validation are satisfied;
• deferred: intentionally inactive until stated conditions change;
• rejected: explicitly declined; reconsideration needs a new proposal;
• historical: retained provenance outside the current portfolio.

Portfolio state is not implementation readiness, runtime health, or execution authority. Those remain independent dimensions in the canonical taxonomy.

Current portfolio

Candidate order is not priority. No candidate is an implied next capability.

Program sequence — 2026-09-07

Reconciled against clean main at d914f2a, the September 7 Media milestone, recent implementation reports, runtime composition, current source and deployed surfaces. This is the current program view inside the existing adoption authority, not a second backlog or a new governance system. Recommendations do not silently adopt work. The exact-task Keeper adoption remains valid.

Recommended next objective: Keeper exact-task completion lifecycle consolidation.

NOW — foundational convergence

1. Broad compositional read-only cognition (C1, complete): the shared runtime discovers principal-authorized Rubick operation contracts, executes a finite observational batch, and preserves Oracle source provenance and uncertainty in Kernel Records. Plex inventory no longer requires generic inference. Registered sources span media, notifications, governance, work, runtime and project state. Optional model interpretation remains dependent on inference availability; individual peer diagnostics and live device control readiness are not implied. See the implemented architecture for effect policy, authorization, bounds and deployed-surface limitations. Completion does not grant authority to execute recommendations.
2. Program truth (C2): this reconciliation repairs the stale Media lifecycle, missing Keeper adoption in runtime metadata and obsolete next-step state. Observational roadmap ownership no longer requires a progression word: current state questions resolved to AncientOS also reach Oracle evidence. Maintain canonical-document/runtime agreement; evidence reconciliation is a release obligation, not an autonomous backlog writer. Runtime synthesis now consumes the canonical recommended objective without granting adoption.
3. Security and validation hygiene (S1, V1): close authenticated chat's missing session-bound CSRF check and repair report-archive test discovery. Preserve existing Lich/identity authority. Finish deterministic test-fixture hygiene where baseline failures demonstrate it is necessary.

NEXT — bounded convergence after NOW

• C3: Keeper exact-task completion, already adopted: reuse durable exact-action proposal/approval/evidence/receipt primitives and test restart/uncertainty. Existing conversational task completion is not proof of the adopted canonical lifecycle. No new task backend, bulk completion or task mutation is implied.
• C4: Lich presentation parity: connect existing controls and simple scoped confirmation to normal proposal rendering, hide opaque identifiers by default, preserve exact binding and high-risk recent-authentication requirements.
• C5: observer/delivery host independence: move only the existing typed pulse hosting contract out of Discord when separately scoped; use shared Io and outcome-return primitives. Do not create a workflow engine or a second outbox.
• A1: cold-device playback truth: distinguish command dispatch, app/profile barrier and observed playback. Never report “playing” solely from dispatch. This can be a narrow App fix alongside Core convergence, not a reopened Media program or authorization to actuate a room during maintenance.

PRODUCT TRACKS

• Rotes (P1): design corpus ingested; documentation reconciliation complete. The source authority inventory preserves the Conceptual Specification Draft 1, Ontology and Effect Semantics Draft 1, and the authoritative reconstructed collectibility/curation/provenance addendum, plus supplied architecture context. The addendum records its replacement adoption and is not a verbatim recovery of the unavailable original. The reconciliation and decision ledger separates settled intent, recommendations, unresolved choices and direct implementation evidence. Universal semantics fit Core conceptual architecture; Apps may specialize domain cognition without redefining them. Chen remains Core. The first bounded informational exchange is implemented in 79dc3628b5e1627c7e9aec29bc6f903c9c1b6ca7; the historical map's implementation and retrieval absences no longer describe current state. Project-corpus reads and narrow establishment have deployed evidence, without claiming complete broad planning. Next recommended Rote slice: governed read-only inspection of one received informational Rote with provenance and restrictions. Global discovery and effectful forms remain deferred. This recommendation does not grant implementation authority or displace the separately adopted Keeper slice.
• Apps (P2): Media Manager, Home Automation, Naga Siren, X Feed, Meeting Intelligence and the read-only Prophet boundary retain independent domain ownership. Prioritize an explicit operator outcome per App; do not make all Apps prerequisites for Core or Rotes. No speculative Android product is implied.

ARCHITECTURE / MIGRATION

• M1: identity and repository migration: AncientOS is the system; Luna is the configurable interface. Preserve discord-luna, module names, Compose service identities, environment aliases, URLs, bind paths and data locations where they have consumers. First inventory consumer contracts and backups/restore; then separately approve remote rename, checkout relocation, compatibility changes and deployment validation. No blind global rename or storage move.
• M2: Core/App extraction: retain Chen, runtime, routing, governance, Keeper, Rubick, Oracle, LifeVault and shared observation/return contracts in Core. Extract App-owned policy/adapters only after consumer and state boundaries are proven. Reconcile Naga's two histories and deployed availability before moving it. Existing X Feed/ops histories should be preserved. A container, integration or hero name alone does not justify a repository.
• M3: legacy reliability seams: database migration exception visibility, old Keeper stores/audit references, provider launch parity and duplicate host mount authority need isolated contracts and validation before deletion.

BOUNDED FOLLOW-UPS — reconciled recovered register

“Open” means current evidence supports the issue, not permission to execute. “Verify” means historical evidence is insufficient to claim current closure. Owner is Core, App, ops or integration; priority follows the sequence above.

RESEARCH / EXPERIMENTS

R1 is ready for a bounded read-only comparative study after Core inquiry convergence. Establish the problem not served by SearXNG, overlap and unique capabilities, privacy/retention and trust implications, maintenance cost and whether a second search surface is justified. Default classification: search integration, not a new Core component or App. Expose both only if evidence supports independent operator value. No upstream functionality is asserted here; the study has not been performed and nothing was installed.

Inference benchmarks, extra providers, experiential reinforcement, networked identity and speculative automation are not maintenance prerequisites. Preserve the existing explicit inference/experience deferral gates below.

DONE / SUPERSEDED and subtractive decisions

Retire “finish Chen watch loop” as a broad active objective; preserve its bounded exceptions. Do not rebuild notification/outcome stores, Lich approvals, Io, canonical-principal identity, qBittorrent linking, model self-inspection or Media provider routing already delivered. Earlier blocked authorization reports are historical when later exact work completed; they do not create fresh backlog. Remove NeoHabit presentation. Exclude disposable report copies from test discovery without deleting reports. Keep unknown capability posture explicit instead of creating adapters merely to fill a dashboard. Retain compatibility paths until consumer evidence supports migration; a name mismatch alone is not a defect.

First-principles review: pipeline ordering and stale hand-maintained adoption metadata reflect historical growth. A second router, registry, scheduler or approval store would increase the ownership problem. Simplify by using the existing intent boundary, bounded provider contracts and single authorities. Do not automate roadmap mutation to compensate for unreconciled release records. Do not optimize model selection to answer questions already owned by evidence. DELETE > SIMPLIFY > OPTIMIZE > AUTOMATE remains the sequencing rule.

Dependency graph and release gates

Arrows are sequencing recommendations unless an adopted contract says otherwise. Rote conceptual requirements are now attributed to the preserved sources and separated from implemented dependencies in the reconciliation. The first exchange has bounded verified-instance mechanisms; broader network and identity mechanisms remain deferred. No graph edge authorizes implementation or mutation. For each implementation slice: focused/full tests, architecture/static/hooks/docs, diff review, Compose rebuild/health and actual affected-surface acceptance. Never substitute mocked providers for live device/notification acceptance.

Completed portfolio

Platform foundation

AncientOS Platform v1 Alpha provides the shared transport-neutral runtime, Runtime Composition, durable Kernel Records, restart-safe explanation, Governed Proposals, durable Lich approvals, bounded execution, Zeus evidence and receipts, rollback or compensation records, and transport parity.

This foundation is complete for the current alpha contract. It is not a claim of production readiness or universal capability coverage.

Oracle Operational Ergonomics

Historical program: Era 7. Portfolio state: complete.

Oracle supplies operator-facing inspection, action queue, governed proposal preflight, simplified proposal intake, explicit apply vocabulary, and proposal audit over existing governed services. Oracle remains advisory and does not own approval, execution, evidence, receipts, memory, or a second proposal lifecycle.

Completion commits:

• 0dba71e Add Oracle governed proposal preflight
• e7c6ae6 Fix governed action precondition race
• 6c31539 Add unified Oracle action queue
• 8be8ee0 Add Oracle governed proposal audit
• 9263433 Add simplified Oracle proposal intake
• 08edff2 Add explicit Oracle governed apply vocabulary

Spectre terminal observation

Portfolio state: complete for terminal observation v1.

Spectre ingests explicit spectre-shell terminal records, applies deterministic redaction, supports explicit process-bounded conversation binding, and supplies read-only evidence for Oracle interpretation. It does not intercept SSH, capture hidden screens, execute commands, approve work, or certify success.

Completion commits:

• 0384b82 Add Spectre terminal observation capability
• b6477df Fix Spectre pre-commit hygiene

First governed capability portfolio

Historical program: Era 8. Portfolio state: complete.

Completion commits:

• cdc31ef Adopt governed capability portfolio as Era 8
• 8b06de0 Add governed configuration value edits
• 319d0e3 Add governed atomic file rename
• 97cf673 Add governed Home Assistant light state
• 124e896 Add Oracle capability portfolio discovery
• 288a861 Add Era 8 portfolio runtime acceptance
• ee65fb7 Complete Era 8 governed capability portfolio

Governed experiential-learning foundation

Portfolio state: complete for the current advisory foundation.

AncientOS can persist independently certified experiential assertions through the governed LifeVault promotion lifecycle, derive deterministic scoped snapshots, attach an exact snapshot to LegionCommander plans after the deterministic task graph is complete, and retain the snapshot identity and evidence provenance for replay. Supported certification evidence is currently limited to exact governed-action receipts and deterministic pytest receipts with exact file-content subject binding and the shared 90-day evidence freshness policy.

LegionCommander is the only experiential consumer. Experience is advisory and cannot influence intent or semantic routing, Rubick readiness or authority_mode, Lich approval, mutation or pending-action authorization, or executor selection. Durable promotion authorizes only persistence of the advisory assertion; it does not approve the action described by that assertion.

Completion commit:

• 775d0fe Add governed experiential learning foundation

The following remain intentionally absent from the completed contract:

• confidence or reinforcement scoring, frequency-based ranking, and adaptive strategy weighting;
• automatic promotion or automatic contradiction adjudication;
• advisory consumers other than LegionCommander;
• learned routing, capability readiness, authority, or approval;
• automatic cross-domain experiential transfer;
• aggregate validation-suite receipts and generalized artifact/tree subject binding;
• arbitrary model-authored durable experiential knowledge; and
• generalized self-optimization.

These limits are architectural boundaries, not incomplete acceptance criteria for the completed foundation.

Governed Inference Registry and Model Selection

Portfolio state: complete for the current production boundary.

The operator explicitly authorized Slices 1–5B and the completion pass. The implemented boundary comprises canonical provider-independent model identity, configuration composition, deterministic aliases, discovery/reachability/ readiness evidence with freshness, bounded Ollama and authenticated OpenAI-compatible observation, canonical inventory and Oracle projection, read-only model questions, request and session selection, bounded restoration, reset to configured routing, targeted readiness verification, provider-name disambiguation, exact-target local/xAI invocation, and shared natural-language semantics across transports.

Live acceptance on 2026-08-21 established the local llama.cpp Qwen 3.8 target and the configured xAI grok-4.3 target through luna-inference. The same Qwen GGUF remains discovered but not ready through Ollama. OpenAI has a provider and adapter contract but no deployed outbound key/model target; LUNA_OPENAI_API_KEY remains only the inbound AncientOS API guard. Completion evidence is recorded in the initiative implementation, tests, deployed acceptance record, and repository history.

The completed capability changes cognition only. It does not change Rubick, Lich, Zeus, executor, mutation, external-contact, tool, or pending-action authority. Explicit selection has no fallback. Existing fast/mid/heavy, LUNA_MODEL_MODE, and luna-local:preferred values remain compatibility configuration when no explicit selection exists.

Remaining inference work is intentionally inactive:

These classifications close the initiative without adopting optional routing, monitoring, lifecycle, or policy work. A future session must explicitly adopt one bounded item before implementation.

Media Manager read-only episode inventory and acquisition discovery

Portfolio state: complete for the current read-only slices.

Episode inventory resolves an explicit TV series through TVmaze and Plex, compares canonical aired-order episodes within an explicit latest-episode, latest-season, or whole-series scope, and returns bounded missing, duplicate, unmatched, wrong-library, ambiguity, and Plex-ahead observations. Acquisition discovery consumes one uniquely resolved aired episode, checks Plex first, and normalizes, filters, deduplicates, and ranks bounded provider observations into an advisory recommendation under media_preference_v1.

Neither slice creates an executable proposal, invokes Lich, starts acquisition, contacts a candidate locator, controls a downloader, mutates the filesystem, refreshes Plex, schedules monitoring, or gains approval or execution authority. The deployed Bitmagnet candidate adapter remains unavailable until a bounded normalized observation contract exists; the synthetic provider is explicit acceptance-only.

Future provider adapters, quality/version policy changes, duplicate handling workflows, automated missing-episode workflows, scheduled monitoring, approval-gated acquisition, download-client integration, filesystem placement, and Plex refresh are not active capabilities. Each requires separate adoption and its applicable evidence, governance, execution, receipt, rollback or non-reversibility, and deployed acceptance boundary.

Completed Media vertical slice

Portfolio state: complete for the demonstrated governed objective lifecycle. The 2026-08-25 watch-loop plan is historical lineage; subsequent operator work extended its provider and playback scope. Commits 62fb131, 019d900, and d914f2a establish the current boundary: natural objective, canonical principal, entity resolution and bounded clarification, exact Lich approval, separate execution, completion observation, Plex verification and qBittorrent cleanup, durable outcome return, current-device Push, named-room playback and observation. A real Pixel notification and awake Living Room playback were observed during that milestone. Playback replay was repaired to make it a one-shot objective. These are historical acceptance facts, not fresh live acceptance in this audit.

Do not reopen the milestone as an unfinished general acquisition program. Cold-device/profile barriers, exact-episode playback identity, observer hosting, clarification crash recovery, retained copies and fresh post-repair replay/Push acceptance are bounded follow-ups in the recovered register below. Completion is not universal device readiness, peer viability, or universal transport parity.

Candidate analysis

Candidates are retained because repository evidence shows plausible bounded operator outcomes. They are not adopted and have no mandatory order.

qBittorrent pause/resume

• Outcome: pause or resume one exact observed torrent.
• Reuse: read-only qBittorrent adapter, Chen provider experience, governed proposal and receipt lifecycle.
• Missing adoption evidence: exact hash identity, fixed operations, provider configuration, durable lifecycle integration, reconciliation, compensation, and transport acceptance.
• Authority boundary: any mutation remains separately Lich-gated.

Read-only service diagnostics

• Outcome: explain one service degradation from bounded evidence without remediation.
• Reuse: Beastmaster inspection, Oracle synthesis, Runtime Composition.
• Missing adoption evidence: exact target class, freshness, redaction, provider identity, route, and deterministic unavailable behavior.
• Boundary: read-only diagnosis must not grow an execution or repair path.

Deferred analysis

Deferred items are intentionally outside the active portfolio:

• container restart and Compose deploy/recreate because Docker authority, convergence, and reversal are unresolved;
• Git update because remote trust, signatures, dirty state, divergence, and recovery are unresolved;
• package/system update because root authority, reboot impact, network trust, and downgrade evidence are unresolved;
• broad delete because retention and irreversibility are unresolved;
• general scheduling because unattended durable execution and cancellation semantics are absent;
• autonomous remediation because explicit human governance remains doctrine;
• general shell execution because typed bounded capabilities are safer and more inspectable.

Reconsideration requires a new evidence-backed adoption proposal. Deferred items do not become candidates automatically when another capability completes.

Governed experiential confidence and reinforcement

Portfolio state: deferred. This is future architecture work, not an implemented capability, an adopted implementation slice, or a Rubick capability. The completed foundation intentionally has no confidence score, reinforcement score, frequency ranking, or adaptive strategy weight.

Before reconsideration, a dedicated planning and review pass must define:

• the independent evidence that may justify a state change; model self-assessment cannot reinforce its own advice;
• the exact reinforcement unit (for example a scoped experience, strategy, planning heuristic, evidence relationship, or capability-specific advisory preference) without assuming one in advance;
• explicit domain, actor, subsystem, capability, and problem-class scope, with no implicit cross-domain transfer;
• deduplication by underlying evidence identity and treatment of correlated receipts from the same execution or validation chain as non-independent;
• failure, contradiction, and explicit supersession semantics that preserve historical evidence rather than producing simplistic score oscillation;
• whether evidence freshness makes a derived posture stale and whether any decay model is justified; automatic decay is not approved;
• an immutable replay projection containing the exact ranking inputs and state supplied to historical cognition;
• deterministic inputs, ordering, bounds, and tie-breaking for any advisory ranking;
• whether automatic evidence-derived updates and operator-authored judgments are durable mutations, and the governance required for each;
• an explanation contract that answers why one experience ranked above another using evidence and provenance rather than opaque learned state.

Any design must preserve the authority firewall: confidence or reinforcement cannot grant authority, reduce Lich requirements, change authority_mode, make a capability ready, select an unauthorized executor, alter deterministic semantic routing, approve mutation, or authorize pending-action continuation. Its first consumer, if separately adopted, must remain inside an established post-boundary advisory path. LegionCommander is the only current experiential consumer; no additional consumer is approved by this roadmap.

The prohibited feedback loop is explicit: experience may advise cognition, but cognition selecting a strategy and declaring itself successful cannot increase experiential posture without independent certification.

Recommended reconsideration sequence, with each step requiring its own bounded decision where applicable:

1. accumulate and validate real certified experiences under the completed foundation;
2. add missing evidence or exact subject-binding adapters only when stable repository contracts justify them;
3. perform the confidence/reinforcement architecture planning and governance review described above;
4. consider one bounded deterministic advisory-ranking implementation; and
5. review any additional advisory consumer separately.

This sequence is not an adopted queue and does not authorize implementation.

Adoption contract

An adoption proposal must contain:

1. stable capability ID and one bounded operator outcome;
2. explicit scope, targets, operations, and non-goals;
3. implementation, integration, and operator-route evidence;
4. dependency and provider configuration requirements;
5. authority classes and the exact Lich boundary for mutation;
6. Zeus evidence, receipt, and outcome-reconciliation requirements;
7. persistence and restart behavior;
8. rollback, compensation, or explicit non-reversibility;
9. security, privacy, identity, and blast-radius analysis;
10. fixture, local, credentialed integration, and live-provider validation expectations;
11. focused, transport, package-isolation, documentation, and full repository validation;
12. explicit operator decision metadata.

Oracle and Rubick may assemble advisory evidence for this packet. They cannot change its lifecycle state. The operator records adopted, deferred, or rejected.

Adoption is not mutation approval. An adopted capability can remain default-disabled, and every live action can remain Lich-gated.

Delivery standard

Read-only capability

A read-only capability must demonstrate:

• bounded evidence and stable identity;
• provider configuration and request-time readiness without unsafe probes;
• deterministic failure for missing, stale, malformed, or unauthorized evidence;
• transport-neutral Runtime Kernel routing;
• Runtime Composition and Kernel Record linkage;
• operator-friendly and diagnostic rendering;
• no write-capable method reachable from the read path;
• focused, integration, transport, and repository-wide validation.

Governed mutation capability

A mutation capability must additionally demonstrate:

• deterministic durable proposal construction;
• exact action, target, scope, actor, hash, and expiry binding;
• durable Lich approval separated from execution;
• request-time freshness and precondition validation;
• bounded typed execution with no general command path;
• durable Zeus before/after evidence and receipts;
• reconciliation for external outcomes;
• exact rollback, compensation, or explicit non-reversibility;
• restart-safe continuation and explanation;
• default-disabled configuration and explicit allowlists;
• fixture and local acceptance plus honest external validation posture.

Platform extension gate

Capabilities should consume existing platform primitives. A shared platform extension requires either:

• at least two independent capability consumers; or
• a demonstrated correctness, security, compatibility, or truthful observability need.

The proposal must document consumers, failure semantics, persistence or migration impact, compatibility, and validation boundaries. Capability-local parsing, policy, allowlists, providers, evidence normalization, execution, and rollback should remain outside shared runtime layers.

Do not introduce a general executor, scheduler, registry, named subsystem, protocol, persistence hierarchy, or transport-specific business rule merely to anticipate candidate work.

Decision record

Future decisions must be added here or in a linked canonical decision record, then reflected in architecture metadata and the master portfolio view. Editing a candidate description alone is not adoption.

Historical relationship

The completed Era 8 contract proved configuration edit, atomic rename, Home Assistant light state, and capability discovery. Earlier detailed rankings, recommended sequences, and implementation prompts were planning inputs for that completed program. They are preserved by Git history and must not be replayed as the current queue.

Root era plans and other proposals are historical unless docs/documentation_status.md explicitly classifies them as canonical.