Data retention schedule
How long each kind of data is kept, what deleting something actually removes, and what persists afterwards. This schedule states the platform's real behaviour, including its current limits.
The schedule
| Data | Kept for | Notes |
|---|---|---|
| Documents, research conversations, and matters | Until deleted by the practitioner or an administrator | Nothing expires on its own. Deleting removes the item from live storage; derived working data and backups follow the rows below. |
| Empty conversations that were never used | Swept after 24 hours | A conversation opened and abandoned with no messages, no title of its own, no documents and nothing favourited is removed a day later. A conversation with any content in it is never swept. |
| Derived document data — processing job records and review checkpoints | Swept after 14 days | Bookkeeping created while a document is processed. A sweep removes entries older than the window; deleting a document does not yet remove its entries immediately. |
| Derived document data — cached readings and section summaries | Swept after 90 days of disuse | Machine-written summaries of document sections, kept so later questions on the same matter cost less. Deleting a document now removes its derived summaries in the same act; the sweep remains as a backstop for material created before this behaviour existed. |
| Provider usage aggregates | 62 days | Per-day counts of requests and tokens by organisation, user, workflow and model. The 62-day window applies to these provider usage buckets only. |
| Other operational records — run timings, failures, storage readings, incidents, job records and health snapshots | Most recent 500 records of each kind | Bounded by record count rather than by time, so how far back they reach depends on how busy the platform has been. Running per-provider totals are not time-bounded at all. Aggregate numbers and bounded metadata only; no client content. |
| Billing events | Most recent 2,000 events per organisation | Older events roll off as new ones arrive. Amounts and references only; no client content. |
| Audit log | Rotated at 25 MB, a bounded number of generations kept, twelve by default | A record of who did what, kept for accountability. It records actions and bounded metadata, never the content of documents or questions. When the live file reaches 25 MB it is rotated and the oldest generation beyond the configured count is discarded, so the log is bounded in size rather than kept for a fixed period. Both the size threshold and the number of generations are configurable by the operator. |
| Offsite backups of application data | Seven daily and four weekly snapshots | Taken nightly, encrypted, and stored offsite. This is the backup that holds accounts, matters, documents and research history. A deletion is only complete once every snapshot made before it has expired. |
| Whole-container archive | Retention not stated here | A daily archive of the whole server container is also taken, and is written to storage on the same host rather than offsite. How long those archives are kept is set outside the platform, so this schedule does not state a period for them; ask your administrator if it matters to an erasure request. |
What deleting something removes today
A practitioner or administrator can delete documents, research conversations, matters, and user accounts. Deletion removes the item from live storage at once: it disappears from the workspace and no new work can draw on it.
Two things persist after a deletion, for bounded periods:
- Derived working data. Cached readings, summaries, and processing records derived from a deleted document are removed by the scheduled sweeps described above — after 14 days for processing records and up to 90 days for reading caches — rather than at the moment of deletion. Work to cascade deletion into these caches immediately is planned but has not yet landed.
- Backup copies. Backups taken before the deletion continue to hold the deleted material until they expire. The offsite daily and weekly snapshots roll off within about a month. The daily whole-container archive is kept under a policy set outside the platform, so ask your administrator how long it holds material if an erasure request turns on it.
Two things worth knowing before you rely on a deletion
- Deleting a practitioner's account deletes their Legal Library submissions too. Documents that practitioner filed to the shared Legal Library are their records, and a purge removes them along with the shared library's index entry. If a submission should outlive the person who made it, it must be preserved before the account is deleted. Removal of the shared index entry is attempted once and not retried, so if it fails an indexed copy can be left behind; report it to your administrator if a submission remains searchable after the account has gone.
- Deleting a user from the command line does not cascade. Deleting an account through the administration screens purges that user's matters, documents and conversations first. The command-line maintenance tool removes only the account, its memberships and its approval records, and leaves everything else in place owned by an account that no longer exists. Until that is fixed, delete accounts through the administration screens.
Erasure requests
If a client or a matter requires erasure, ask your administrator to delete the relevant documents, conversations, and matters. Be aware of the honest limits: the material leaves live storage immediately, the derived caches clear on the sweep windows above, and backup copies expire on the backup cycle — so complete erasure of the offsite snapshots takes about a month from the deletion, and the whole-container archives expire on whatever cycle the operator has set for them. Offsite backups are encrypted throughout and are restored only to recover the service, never to retrieve deleted material. Use the administration screens rather than the command-line tool, for the reason given above.
Related
- Subprocessor notice — every third party that processes data when you use the platform.
- Personal Information Collection Statement — the platform's PDPO notice, including how to make an access or correction request.