Data retention

Olympusx AI keeps everything until you say otherwise. A platform administrator sets a retention window per class of data, for the whole platform or for one tenant, and a daily sweep deletes what has aged out. Two holds keep data the sweep would otherwise delete: unbilled usage, and the start of a verifiable audit trail.

Retention windows are set through the API.

Who can set them

Platform administrators only, because a window decides when a compliance record stops existing. Every change is recorded in the audit trail as retention.policy.updated, with who set it, the class, the window and the scope.

The classes

Class	Default	What the sweep deletes	What survives
`audit_log`	Keep forever	Audit entries older than the window	An anchor recording where the trail was cut and the hash it ended at, so the rest still verifies
`usage_ledger`	Keep forever	Metered usage older than the window	Everything after the last billing period that is stated. See Billing holds usage.
`assistant_threads`	Keep forever	Whole conversations idle longer than the window	Nothing: their messages go with them
`agent_runs`	Keep forever	Agent runs older than the window	Nothing: their steps go with them
`agent_sessions`	Keep forever	Agent conversations idle longer than the window	Approvals that held a call stay, with names only; their review then says the arguments are no longer available
`gateway_samples`	30 days	Captured gateway turns older than the window	Nothing: scores recorded against them go with them
`security_assessments`	Keep forever	Security assessments that finished before the window, and findings no assessment has reported since	A finding seen inside the window, its dismissal included
`code_reviews`	Keep forever	Merge request reviews made before the window, with the diffs they kept	Nothing
`security_investigations`	Keep forever	Investigations that finished before the window, with the rows they quoted	The findings they reported, which follow `security_assessments`

gateway_samples is the one class with a default window. Capture is off for every tenant until someone turns it on, so the table starts empty, and what it holds is captured production traffic: the prompts people actually typed. Thirty days is long enough for a review cycle and short enough that a forgotten switch does not become a corpus.

Set a window

Call the management API with a platform administrator’s sign-in token. Through the console’s host, the API is under /api:

curl -X PUT "https://<console-host>/api/v1/platform/retention" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"dataClass": "assistant_threads", "keepDays": 90}'

Field	Meaning
`dataClass`	One of the classes above. Anything else is refused with `400 invalid_data_class`, listing the valid ones.
`keepDays`	A positive number of days, or `null` to keep forever. `null` is the only way to turn a class off again. 0 or a negative number is refused with `400 invalid_keep_days`.
`tenantId`	Optional. Omit it to set the platform default; include it to override one tenant.

The response repeats what was set. Without a token the API answers 401; with a tenant role, 403.

Read what is set

curl "https://<console-host>/api/v1/platform/retention" \
  -H "Authorization: Bearer $TOKEN"

It returns the stored policies, platform defaults and per-tenant overrides, and the list of valid classes.

The sweep

One control-plane replica applies the windows every 24 hours, starting five minutes after it comes up. A failure for one tenant is logged and the sweep moves on to the next; it does not stop honoring everyone else’s windows.

A change you make takes effect at the next sweep, not immediately.

Two holds that refuse deletion

Billing holds usage

Until a billing period is stated, its metered usage is the only record of what a tenant owes. So the sweep never deletes usage after the end of the last stated period with nothing unstated before it. If a tenant has no stated period, none of its usage is deleted, whatever the window.

When the hold keeps usage the window would have removed, the control plane logs:

retention: usage ledger held back by unstated billing
  tenant_id=… removed=0 requested_cutoff=2026-05-17 actual_cutoff=2026-02-01 …

Alert on that line. It means a retention promise is not being met, and the fix is to close the period and issue its statements on Billing, not to change the window.

The audit trail stays verifiable

The audit trail is a hash chain: each entry is sealed against the one before it. Deleting the oldest entries would normally look like tampering. So the sweep writes an anchor, the id and hash of the last entry removed and how many went under which policy, and verification starts from the anchor instead of the beginning. A pruned trail still verifies, and still catches tampering after the cut.

The sweep checks the remaining trail inside the same transaction, and rolls back if the result would not verify. The control plane then logs retention: audit chain not pruned, and the sweep moves on.

The protection that stops the platform’s own service account from writing an anchor itself applies when tenant isolation is on at installation, so the platform connects to its database with a restricted role. See Network and hardening.

Retention and erasure

A window removes everything older than a date. Erasing one named person on request is separate: see Erasure. For erasure and backups, see Erasure and backups.

Limits

Limit	Value
Sweep interval	Every 24 hours, first sweep 5 minutes after start
`keepDays`	A positive whole number, or `null`
Scope	Platform default, or one tenant
Set through	The API