Sistava deletes operational data on a fixed schedule instead of keeping it forever by default. A cleanup job runs every day and removes rows past their retention window: short-lived debug data within a week or two, working memory after 30 days of inactivity, and usage and activity history after two years. Chat messages, documents your employees write, and persistent notes are kept indefinitely unless you delete them yourself. There is no setting to change these windows; they apply the same way to every workspace.
Every day, a background job walks through the tables that grow the fastest and removes anything past its retention window. Each data type is cleaned independently and in small batches, so a slow table never blocks the others and the cleanup never competes with your employees for database capacity during business hours.
The windows are not uniform. Working memory, the raw checkpoint state behind an in-progress chat thread, is pruned after 30 days with no activity, because it is expensive to store and rebuildable from what survives it: the chat messages themselves, any document your employee produced, and persistent memory notes, all of which are kept indefinitely. Debug traces used for short-term regression checking are pruned within a week. Usage records, activity history, task completions, and work journal entries, the data that lets you audit what an employee did and when, are kept for two years. Idempotency keys used to prevent duplicate billing on retried jobs are dropped after a week, once the retry window they exist for has closed.
Most platforms describe retention with a vague promise like 'we keep data as long as necessary,' which tells you nothing about what happens to your history six months from now. Sistava's windows are fixed numbers, not a policy statement: the same schedule that runs against production is the one documented publicly, so what we say we delete and what actually gets deleted are the same thing, checked against each other rather than left to drift apart.
Short-lived operational data goes first. Debug trace snapshots used for week-over-week regression checking are removed after 7 days; the full trace still lives in the underlying tracing tool if you need it beyond that. Idempotency keys, used only to stop a retried job from double-charging you, are dropped after 7 days once the retry window has closed.
Working memory, the checkpoint state behind a chat thread, is pruned after 30 days of inactivity on that thread. Schedule trigger logs, which record when and why a recurring job fired, are kept for 90 days, enough to cover a full quarter of debugging. If you reopen an old thread past its checkpoint window, your employee rebuilds context from the chat history and its persistent notes instead of replaying the deleted working state, so the conversation still makes sense, it just starts from a fresh internal state.
Chat messages, documents your employees write, and persistent memory notes are excluded from this cleanup entirely and kept indefinitely unless you remove them yourself through Data Export or account deletion. Activity history, usage records, completed tasks, and work journal entries are kept for two years, long enough to review a full year of billing and performance trends before they age out.
Personal Mailbox messages sent or received through an employee's own address, and delegation logs recording how employees coordinated with each other, are kept for one to two years for audit and debugging purposes. None of this is stored for marketing or profiling; it exists so you and support can reconstruct what happened on your account.
A daily cleanup job enforces a fixed retention window per data type
A scheduled job runs once a day, off-peak, and works through each data store independently: PostgreSQL tables, object storage, and the knowledge graph. For each one it deletes rows or objects older than that data type's specific window, in small batches with short pauses between them so the deletes never lock a table long enough to slow down live traffic.
Deleting a row here means the underlying record is gone, not archived or soft-deleted. A failed cleanup run on one table is logged and retried without blocking the others, and none of it is visible or configurable from inside your workspace: the schedule is the same for every tenant on the platform.
When a customer or auditor asks how long you keep usage logs or debug traces, you can point to a specific, published number instead of a vague promise, because the schedule that runs in production is the one that's documented.
Chat history, documents, and persistent memory notes are excluded from the cleanup entirely, so reopening a six-month-old thread still shows the full conversation even though the underlying working-memory checkpoint expired long ago.
Fast-growing tables like debug traces and idempotency keys are capped at a short window automatically, so the data you don't need long-term never accumulates into a storage bill you didn't plan for.
Usage records, activity history, and completed tasks are kept for two years, giving you enough runway to review billing history or an employee's performance trend well after the work happened.
No. Retention windows are a fixed, platform-wide policy, not a per-workspace or per-activity setting. Every tenant on Sistava is cleaned up on the same schedule, so you get a consistent, verifiable guarantee instead of a knob that could be left misconfigured.
No. The checkpoint is just the raw internal working state of one chat turn. The conversation itself, the chat messages, is kept indefinitely, along with any document the employee wrote and its persistent memory notes. If you reopen an old thread, the employee rebuilds context from those instead of the deleted checkpoint.
The published retention schedule lists the window for every data type we store, and it is kept in sync with the internal policy enforced by the daily cleanup job, so the public page and the code that runs against production never drift apart.
No. It runs off-peak, once a day, deletes in small batches with pauses between them to avoid locking tables, and a failure in one table's cleanup never blocks another. Retention cleanup is invisible from inside the workspace.
Data Retention is part of How you run the account itself.
Sign in the way your company already does, decide who can do what, and keep the money side legible. Credits, plans, invoices, referrals, and the controls that decide who reaches which part of the workspace.