LisaOS Docs
Operations

Session Close

The session-close protocol — committing summaries, transcript, and durable memory fragments across both stores.

Session close is the mirror of activation: before the session ends, it commits everything worth keeping to persistent memory so the next session — on either door — starts richer. Like activation it runs without approval gates.

The sequence

  1. Audit. Review the session and cluster its work by subject. A session with nothing substantive to commit (a greeting, a single quick question) short-circuits here.
  2. Write semantic summaries. One compact, per-subject summary capturing what was decided, produced, and left open.
  3. Write the episodic record. A fuller transcript of the session, filed under the primary subject.
  4. Update the memory index. So the new summaries and record are discoverable next time.
  5. Commit to the gateway. Push the summaries to persistent memory, embeddings and all.
  6. Commit durable fragments (dual-write). Extract, score, classify, deduplicate, and write the session's durable facts — a working-style preference, an entity fact, a standing decision — to both the vault and the gateway. Deduplication happens against both stores before writing, so a fact already known is updated, not duplicated.
  7. Security scan. If code was changed this session, scan it; if not, skip with a note.
  8. Deregister and signal. Remove the session from the registry and emit the completion signal.

Why the dual-write matters

The durable-fragment step writes to two stores on purpose. The vault is the canonical, human-readable, version-controlled record; the gateway is the fast, embedded, cross-surface index. A fact committed to both is immediately available to a parallel session on the other door and survives as a reviewable file. This is the same dual-write invariant that governs persistent memory generally — session close is just the moment it fires in bulk.

Fail-open

If the gateway is unreachable at close, the protocol writes the vault files anyway and records "gateway offline — vault only". The commit is never lost to a transient outage; it degrades to the durable store and reconciles later.

Not deferred to the end

Durable memory is not only committed at close. The moment a standing preference, correction, or entity fact appears mid-session, it is dual-written immediately — because the session could compact or end before reaching this protocol. Session close is the safety net, not the only net.

On this page