# Retention labels

Kind

concept

For

developer · operator · governance

Verified against

@veritio/core@0.4.7

`retention` is a portable label recorded inside an audit event. It tells a reader which policy the producer assigned; it does not schedule deletion, prove that deletion occurred, or define a universal duration.

## Policy evidence on an event

[Section titled “Policy evidence on an event”](#policy-evidence-on-an-event)

```json
{
  "id": "evt_session_revoked_01",
  "action": "security.session.revoked",
  "retention": "security_1y",
  "metadata": {
    "policyVersion": "security-retention.v3"
  }
}
```

The SDK preserves the label in the normalized event and therefore in the record hash. A later silent edit from `security_1y` to another label produces a verification failure.

## Enforcement belongs to the operating boundary

[Section titled “Enforcement belongs to the operating boundary”](#enforcement-belongs-to-the-operating-boundary)

The system that owns the authoritative records must map the label to lifecycle behavior. A complete policy defines:

-   the policy version and effective date;
-   which record and derived-data classes it covers;
-   the time origin used to calculate eligibility;
-   legal hold or suspension behavior;
-   deletion or anonymization mechanics;
-   the evidence produced when the policy runs;
-   backup, archive, and projection handling;
-   verification behavior across the removed range.

Do not publish a number of days or years unless the operating implementation applies that duration and the claim has current evidence.

## Deletion changes what can be verified

[Section titled “Deletion changes what can be verified”](#deletion-changes-what-can-be-verified)

Removing an interior record from a complete chain creates a sequence or previous-hash gap. That is correct for an undeclared deletion: the verifier should not pretend the original full chain is intact.

An intentional retention boundary therefore needs an explicit verification design. Depending on the implemented system, that may be a scoped export manifest, retained evidence commit, tombstone or policy-run record, or a new verifiable segment. The website must not invent one of these behaviors when the owning repository has not implemented it.

## Authoritative and derived data

[Section titled “Authoritative and derived data”](#authoritative-and-derived-data)

Deleting from a derived archive or analytics projection does not delete the authoritative record. Conversely, removing an authoritative record does not guarantee that backups, caches, exports, or downstream processors have applied the same policy. The operating contract must name every copy and its owner.

## Review a retention implementation

[Section titled “Review a retention implementation”](#review-a-retention-implementation)

Trace one policy label from event creation to policy resolution, eligibility calculation, authoritative mutation, derived-tier propagation, and a post-operation verification artifact. If any transition lacks an observable result or failure path, the retention workflow is incomplete.

Continue with [Storage overview](/docs/storage/overview/) and the [export format](/docs/reference/export-format/).

[Edit page](https://github.com/getveritio/veritio-website/edit/main/src/content/docs/docs/concepts/retention.md)

Last updated: Aug 23, 2026

[Previous  
Redaction](/docs/concepts/redaction/)[Next  
Governed actions](/docs/guides/governed-actions/)

Veritio provides evidence support, not legal advice or automatic compliance.

This site uses cookieless, anonymous analytics (Umami) by default. With your consent, we also enable Google Analytics, which sets cookies and sends usage data to Google. [Privacy Policy](/legal/privacy/)