Conversation history and personal-interfaces source context
This reference preserves cross-cutting context for personal conversation continuity and owner access paths. It also records why persistent personal memory, panels, home views, and app navigation are compositions or audience projections rather than additional generic capabilities.
Source roles and limits
| Source | Role | Can establish | Cannot establish alone |
|---|---|---|---|
| Current PIOS framework | architecture authority | one information Core, event/History distinction, replaceable interfaces, Core-app role, source preservation, interaction-to-canonical-object boundaries, and state treatment | one chat table, one interface layout, one app launcher, or one deployment-specific access route |
| Historical PIOS Global at the selected revision | historical design and realization evidence | continuous conversation history, append-oriented correction, imported-source provenance, memory-layer composition, interface roles, access paths, panel separation, and navigation patterns | current architecture authority, current deployment, or mandatory product layout |
Restricted application evidence RAS-01 | requirements and bounded static realization evidence | one owner-linked chat-history structure, source-aware entries, filter-linked views, session markers, and a read-only raw-history surface | a complete interoperable conversation model, verified owner access-path lifecycle, tests, deployment, or production behavior |
Conversation continuity boundary
- Personal conversation history preserves continuity across sessions, views and eligible sources; it is not the same as the broader event log or curated owner-facing History.
- A collaboration message is one attributable communication. Personal conversation history governs membership, order, provenance, correction/hiding state and continuity across many such interactions.
- Channels and threads may organize or filter the history. PIOS does not require a dedicated
chat_historytable or mandate that every collaboration context share one physical stream. - Imported conversations reuse source retention, import-session, source-promotion, context-allocation, retrieval, consolidation, pattern and proposal capabilities. Their source identity cannot be flattened away.
- Persistent personal memory is a system-level composition over sources, events, notes, conversation history, knowledge, relationships, corrections, decisions, retrieval and derived representations; it does not pass as one Capability MLE.
Personal-interface boundary
- The Core app, Ally-style conversational surfaces, structured PIOS panels, Circle, dashboards, native clients and command-line tools are replaceable interfaces or composed products.
- Home overviews, app grids, panels, swipe gestures, colors, tile layouts, recent-item lists and saved view state are audience or realization patterns.
- An owner access path is independently meaningful when its identity, role, assurance, supported operations, priority, health, verification and fallback lifecycle are governed.
- Primary, secondary, master and fallback are historical access-path roles, not mandatory product names. A deployment profile may use a different vocabulary while preserving the contract.
- An execution-tracking surface reuses operational-run inspection, work-object, background-operation and result capabilities rather than defining a separate execution system.
Documentation and realization reconciliation
The historical model describes one owner conversation history with channels and threads as filters, append-oriented correction, source-aware imported entries, and explicit boundaries from notes, updates and the wider unified timeline. Current PIOS instead makes the event log the canonical cross-source spine and permits replaceable communication interfaces. The reusable capability therefore preserves logical conversation continuity without requiring the historical table design.
The selected restricted application implements one owner-linked chat-history record, paired owner-input/assistant-response entries, channel filters, session markers, a bounded recent-entry context window, and a read-only raw-history view. This is partial static evidence. It does not establish message-level multi-actor attribution, complete imported-history governance, append-only enforcement, cross-harness continuity, tests, deployment, or production behavior.
The historical personal-interface model distinguishes primary, secondary, master and fallback paths and separates conversational, structured and operational views. The current PIOS framework confirms that owner interfaces are PIOS-native or independent clients over governed Core capabilities and must not become a second canonical Core. No complete restricted implementation of access-path governance was confirmed.