Skip to content

AncientOS Rote design corpus

Status: source ingestion is complete. This remains the canonical entry point for preserved design records, not a registry or an authority grant. The historical ingestion reconciliation retains its original repository baseline and source interpretations.

As of September 9, 2026, commit 79dc3628b5e1627c7e9aec29bc6f903c9c1b6ca7 implements bounded informational-Rote exchange. That current capability document controls implementation scope: two explicitly verified peers, operator-mediated exchange, LifeVault custody, exact consent and restricted propagation. General discovery, effectful Rotes and automatic indexing are not implemented. Project-corpus reads and narrow source establishment have also been validated through deployed cognition; the full investigation-to-plan path is not established by that result. These later facts do not alter the preserved sources or blanket-adopt their proposals.

Source authority inventory

The operator supplied these five files in /home/khrynisx/upload from Pixel8Pro on ser6buzz for this ingestion goal. Originals below are byte-identical copies; their filenames are preserved. Internal titles and status labels control over filenames, upload times, and filesystem dates. Only C, O, and A form the Rote corpus; P and T are its supplied architecture context.

Ref Exact source and title Version/date and authority Relationship and registration
C AncientOS Rote — Conceptual Specification, Draft 1 Draft 1; September 2026 body date; product/architecture design draft. New recommendations remain proposals until operator adoption. Derived from P. Historical source preserved here; reading copy is a derivative, not a competing specification.
O AncientOS Rote — Ontology and Effect Semantics Specification, Draft 1 Draft 1; September 2026 body date; product/architecture design draft. Its local status vocabulary and §17 decision register apply. No independently established authoring timestamp. Refines C; resolves some design directions while leaving explicit operator choices. Preserved and catalogued here without blanket adoption of recommendations.
A AncientOS Rote — Collectibility, Decentralized Curation, and Provenance Addendum Authoritative reconstructed design addendum. Opening provenance records reconstruction from the September 2, 2026 session and operator adoption on September 7, 2026 as replacement for the unavailable original. This supplied replacement is authoritative at its stated status; it is explicitly not verbatim recovery. Connective reconstruction is acknowledged. Narrow explicit additions govern their subject; O's unrelated open choices are not silently adopted.
P AncientOS — Curated Architecture Packet Curated conceptual context, with source-file boundaries and mixed decision labels. No independently established version date. The internal title resolves the Work filename alias. Governs conceptual context, not present repository/runtime state. Eight embedded source sections remain intact.
T AncientOS Target Repository and Product Architecture Architecture recommendation for review, with operator-settled Chen clarifications and provisional component assignments; no repository inspection claimed. Context for Core/App reconciliation, not adopted repository topology, technology selection, or migration authority.

No competing copy was found in the supplied folder. The DOCX -1 suffix is not evidence of a newer design. Its package revision is 1; generic 2013 creation and modification timestamps conflict with its September 2026 body date and are not treated as authoring chronology. A's session/adoption provenance is recorded by the supplied source, not independently authenticated from an original transcript. The unavailable earlier addendum has not been reconstructed by this ingestion.

Byte integrity

SHA-256 identifies the supplied artifacts for this ingestion; hashes do not prove truth, authorship, operator authority, or semantic identity.

Ref Bytes SHA-256
C 58,279 03b26b4ac9b46edbd4b719337c5ed94688c2f5b3f8cf93927384e043bf389f59
O 101,083 47a402fedc1203fc744e4cf188d444334441e1ed15c7a28581cb3c07afe347da
A 51,964 da6c216d492f2a76ec27879c621b53893b1e1ec5b6a77cab5edade1c405368ab
P 28,602 b6fb8c3b91a20dc8f3b73079c2c0888e02e65a82b44ac3fb5d16c168e8d7d092
T 47,023 125be645ebe5ceb9f3d728750f6cf41d7693d1b1c02ce69fc955ed0d74565e17

The reading copy preserves all 448 nonempty DOCX body paragraphs in order, with exact paragraph wording (only the two trailing spaces on each of the Status and Authority paragraphs are removed), 18 first-level and 75 second-level section headings, 99 bullet items and 111 numbered items across 13 explicitly numbered lists. Original numbering starts and sequence are preserved. Five empty paragraphs, typography, pagination, repeated header and page-number footer are presentation differences, explicitly excluded from the derivative. The DOCX has no body tables, tracked insertions/deletions, hyperlinks, embedded media, footnotes or endnotes. Byte comparison of originals and paragraph/style/list comparison of the derivative are the fidelity checks; the original remains available for any formatting-dependent interpretation.

Authority rules and current AncientOS sources

  1. Operator-approved intent remains intent, not implementation evidence.
  2. Proposed architecture and design directions retain their individual labels.
  3. Unresolved/deferred choices remain open until a separately evidenced decision.
  4. Repository/runtime observations determine what is implemented and reachable.

Recency does not override subject authority. C §18, O §17 and A §18 remain historical decision registers. The reconciliation records later resolutions beside earlier questions without editing their source text. A §1 uses “RECOMMENDED FOR ADOPTION” for connective design adopted with this replacement; O uses the same words for recommendations still needing adoption. “PROPOSAL” in A still means unadopted. Do not normalize away that distinction.

Current source Authority role and relevant sections
AGENTS.md Engineering scope, governance, validation and report rules; task authorization bounds this documentation work.
Documentation status Canonical documentation classification and roadmap authority. This corpus is a design record, not a present-feature claim.
Core/App boundary Boundary Classes and State Ownership: Chen is Core; Luna/Keeper Console interfaces; Apps own domain concerns.
Canonical terminology and kernel specification Existing component responsibilities and constitutional authority.
Governance kernel and durable actions Exact principal/action, approval distinct from execution, evidence and fail-closed transitions.
Identity model System/persona/transport separation; canonical-principal preference ownership. This is not a cryptographic multi-instance Rote identity implementation.
Memory architecture Layers and Memory Authority Hierarchy: LifeVault broader than Rotes, canonical docs separate from promoted memory.
Compositional cognition Reviewed read contracts, principal authorization, safe adapters, finite composition, provenance and bounded presentation.
Knowledge surfaces and knowledge/component_catalog.md Existing bounded component-document discovery, not an arbitrary architecture-corpus reader.
Portfolio roadmap Current portfolio and P1: sole adoption authority; Keeper exact-task completion remains the adopted implementation slice.
Operator roadmap view Derived project view, not a separate adoption authority.

Current implementation comparison is anchored at dbc5e8c6d2eed50ff366244e25121188cb775f16. Exact code paths, observations, contradictions, and the Luna retrieval boundary are in the reconciliation. This catalogue registers documents within existing canonical documentation navigation; it does not alter knowledge/component_catalog.md, register a new component, create a second index, or grant conversational exposure rights.