---
title: "Data retention & purge"
manual: "TYPO3 LLM Extension"
version: "0.35"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-llm:administration-data-retention@0.35"
source: "Administration/DataRetention.rst"
modified: "2026-09-16T22:09:16+00:00"
---

# Data retention & purge

The extension writes several kinds of row that can carry request content:
conversation transcripts, agent-run event payloads, evaluation output, the skill
audit trail and provider telemetry. All of them are governed by one central
privacy policy ([ADR-064](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-064@0.35)): what is stored at all, and for how
long.

## What is stored

The extension configuration setting **Content Privacy Level**
(`privacy.level`) decides how much request content is persisted:

-   **`none` / `metadata` (default)**

    Content payloads are dropped. Metadata — timings, token counts, cost, tool
    names, sizes, error class — is kept. Agent-run steps are stored in this
    reduced form too, so persistence does not quietly build a prompt archive.

-   **`redacted`**

    Content is stored with obvious credentials and email addresses masked and the
    length capped. A heuristic, not a guaranteed PII scrubber.

-   **`full`**

    Content is stored verbatim. Choose this deliberately — for an agent run it
    means the whole transcript, including tool arguments and results.

Conversation messages are the exception: their content is the feature. A session
replays its own history on every turn, so the transcript is always stored — and
therefore governed by retention rather than by the level.

## How long it is kept

`privacy.retentionDays` (default 30) is the window for every category. Each
category can override it under `privacy.retention.*` — set `0` to keep the
default:

| Setting | Covers |
| --- | --- |
| `privacy.retention.conversation` | Conversation sessions and their message transcripts |
| `privacy.retention.agentRun` | Finished agent runs and their event payloads |
| `privacy.retention.approval` | Agent runs that never reached a terminal status, above all runs suspended for a human approval |
| `privacy.retention.telemetry` | Provider pipeline metadata (no prompts, no responses) |
| `privacy.retention.evaluation` | Graded evaluation output |
| `privacy.retention.skillAudit` | Skill scan findings |
| `privacy.retention.governance` | Tool-gate denials and guardrail blocks (no prompts, no responses) |

A zero, negative or non-numeric value never means "delete immediately" — it
means "no override". When to set one at all, and how to read the window that
is in force, is covered under
[The seven retention overrides](https://docs.typo3.org/permalink/netresearch/nr-llm:administration-governance-retention-overrides@0.35).

Runs awaiting a decision are deliberately separate. A run suspended for an
approval carries the state needed to resume it, so it is only deleted on the
`approval` window. Give it a longer value than `agentRun` if approvers may
take days.

## Running the purge

Nothing is deleted until a purge runs. Schedule the central command — it covers
every content-bearing table in one pass:

```bash
vendor/bin/typo3 nrllm:privacy:purge
```

It reports the window applied and the rows deleted per category. `--days=N`
overrides every category at once, which is useful for a one-off cleanup:

```bash
vendor/bin/typo3 nrllm:privacy:purge --days=7
```

Two single-table variants exist for operators who want separate schedules. They
read the same policy, so they cannot drift from it:

```bash
vendor/bin/typo3 nrllm:session:purge
vendor/bin/typo3 nrllm:telemetry:purge
```

All three appear in the scheduler's **Execute console commands** task —
no extra registration is needed.

> [!NOTE]
> Usage rows (`tx_nrllm_service_usage`) are **not** purged: they are the
> billing ledger the budget limits and the Analytics module report on. They
> hold no prompt content, only counts, cost and the acting backend user.