> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# Retention

> How long traces, payloads, memory, and derived data stay around.

Every category of data has its own retention. Some you can tune; some are governed by your plan.

## What has retention

| Category                                          | Default                              | Configurable?   |
| ------------------------------------------------- | ------------------------------------ | --------------- |
| **Trace metadata** (timestamps, cost, verdict)    | 1 year                               | Yes, per Flow   |
| **Trace payloads** (prompts, tool args/responses) | 90 days                              | Yes, per Flow   |
| **Memory items** (notes, nodes, edges)            | Indefinite                           | Per-space TTL   |
| **Documents**                                     | Indefinite unless superseded         | Per-collection  |
| **Superseded documents**                          | Indefinite                           | Per-collection  |
| **Audit entries**                                 | 1 year (Team) / 7 years (Enterprise) | Enterprise only |
| **Pipeline run logs**                             | 90 days                              | Yes             |
| **Signals / Improvements**                        | Indefinite                           | No              |
| **Datasets**                                      | Indefinite                           | Manual delete   |
| **Approvals (decided)**                           | 1 year                               | Enterprise only |

## Trace retention

Two separate knobs:

* **Metadata** — the trace's structural info (timestamps, cost, verdict, feature flags). Cheap to keep long-term.
* **Payload** — the full content (prompts, retrievals, tool responses, final answer). Storage-heavy and privacy-sensitive.

Configure per Flow: **Flow settings → Retention**.

Common patterns:

* **Regulated workloads** — payload 30 days, metadata 7 years. Enough for audit; short exposure of raw content.
* **High-volume support** — payload 14 days, metadata 90 days. Aggressive to control storage cost.
* **Regulated + long audit** — payload 90 days, metadata indefinite.

When payload retention expires, the trace remains — you can still filter by cost, latency, verdict — but the payload fields are scrubbed.

## Memory retention

Every memory space has a **default TTL** for new items and a **retention policy** for existing items:

* **Retention: permanent** — items never decay unless explicitly deleted or superseded.
* **Retention: importance-decay** — low-importance items retire after not being used for a while.
* **Retention: TTL** — items auto-expire per their individual TTL.

Configure per space: **Memory → space → Settings**. See [Forgetting](/build/memory/forgetting) for the full model.

## Document retention

* **Documents** — kept indefinitely by default.
* **Superseded documents** — kept indefinitely too, but excluded from retrieval. Configure a supersede-retention policy per collection to auto-hard-delete after N days.

Hard-delete of documents (via UI, with confirmation) is permanent.

## Audit retention

Free: 30 days. Team: 1 year. Enterprise: configurable (up to 7 years or indefinite).

Older entries archive (still exportable) but don't show in default views. See [Audit](/settings/security/audit).

## Signal / Improvement retention

Not deleted. The reliability history is preserved indefinitely — the point of the improvement flow is compounding, and losing history breaks that.

You can archive individual signals to hide them from the default queue (still queryable).

## Deletion vs. supersede vs. archive

Three levels:

* **Archive** — hidden from default views. Reversible. All associated data intact.
* **Supersede** — excluded from retrieval / active queues. Auditable. Reversible.
* **Delete** — permanently removed. Not reversible. Some short-grace-period undo (7 days for many object types).

Prefer archive when in doubt. Prefer supersede for content that should stop being active but stay auditable. Prefer delete only for legal / compliance requirements.

## GDPR / CCPA erasure

For a specific user's data erasure request:

**Settings → Data → Erasure requests → New**:

1. Enter the user identifier (email or scope key).
2. Preview what would be deleted (traces referencing them, memory items scoped to them, feedback attributed to them).
3. Confirm.
4. Erasure runs; audit entry logged (the erasure event itself, not the deleted content).

Erasure is permanent — plan carefully.

The [`nora feedback`](/cli/feedback) `--external-user` field enables this cleanly: user-attributed feedback can be erased in one operation.

## Enforcement

Retention runs on a nightly schedule per workspace:

* Expired trace payloads: scrubbed.
* Expired memory items with TTL: removed.
* Aged-out audit entries: archived.
* Expired soft-deletes: hard-deleted.

Manual force-run available for owners: **Settings → Data → Run retention now**. Usually unnecessary.

## Policies

Workspace policies (see [Access](/settings/workspace/access)) can enforce retention:

* **Maximum payload retention** — no Flow may retain payload beyond N days.
* **Mandatory audit retention** — must be at least N days.
* **Mandatory redaction** — all Foundry pipelines must include a PII redaction step.

Set at workspace level; every Flow inherits.

## Related

* [Data export](/settings/data/export) — get your data out before retention hits.
* [Compliance](/settings/data/compliance) — regulatory modes.
* [Forgetting (memory)](/build/memory/forgetting) — memory-specific retention.
* [Audit](/settings/security/audit) — audit retention specifically.