Operations Overview
The operational protocols that run a LISA session — from activation, through the work, to a clean close.
A LISA session is not a blank chat. It activates through a defined sequence, maintains working state as it goes, survives a compaction if one strikes, and closes by committing what it learned. These are the operational protocols — the choreography that turns a stateless model turn into a continuous, memory-bearing collaborator.
The session arc
| Phase | Protocol | What it guarantees |
|---|---|---|
| Start | Session activation | Procedural memory loaded, integrations checked, context assembled — LISA boots into the right project |
| During | State maintenance + compaction recovery | Working state is continuously checkpointed, so a context reset does not erase the mission |
| End | Session close | Everything worth keeping is committed to memory across both stores |
| Periodic | Reconciliation | The documented system still matches the real one |
| On demand | Sage Mode | A heightened, mission-saturated operating state |
Speed where it is safe, gates where it is not
The activation and close protocols run without approval gates — speed is the priority and both are well-defined enough to trust unattended. The protocols that change the system — reconciliation-driven repairs, memory commits that could overwrite — apply the usual governance discipline: deduplicate before writing, honour the change-authority tiers, and never clobber hand-elaborated state.
Best-effort, always
Every operational protocol degrades gracefully. If the gateway is offline, activation notes the degraded capability and proceeds; state maintenance fails silently and continues; the session close writes to the vault alone and records that the gateway was unavailable. The session is the unit that must not be blocked — the enrichments around it are allowed to fail.