# Retention schedule, and how erasure is resolved

**Draft for counsel.** The periods below are Mirror's proposed defaults for what the **operator** holds. Each member bank's own record-keeping obligations govern what it keeps, and may be longer. Not legal advice.

## What the operator holds, and for how long

| Record class | Where | Proposed retention | Why | Disposal |
|---|---|---|---|---|
| Governance events (members, corridors, witnesses, revocations) | `mirror_registry_events` | The life of the rail | The registry is the root of trust; every verdict is judged against it | Never deleted. A retired corridor or member is its own event. |
| Signed verdicts (the ledger) | `mirror_verdicts` | At least 10 years | Members' AML record-keeping periods; the verification escrow (`mirror-archive`) is built for the ten-year record | Kept intact, so the hash-linked log stays verifiable. Made unlinkable by crypto-shredding (below). |
| Member public keys | `mirror_member_keys` | The life of the rail | Old verdicts must stay verifiable | Never deleted |
| pKYC triggers (entity commitments) | `mirror_trigger_bus` | The period the legal basis allows | Each trigger is shared under a named basis | Pruning by basis is **not automated today** |
| Webhook subscriptions | `mirror_webhooks` | While subscribed | Delivery | Deleted on unsubscribe |
| Webhook deliveries (the outbox) | `mirror_webhook_deliveries` | Proposed 90 days after delivered, dead or gone | Delivery evidence for the member | Pruning is **not automated today** |
| Delegations | Not stored | — | Presented at each sign-in | — |

## The erasure conflict, resolved by design

A data subject's right to erasure (GDPR Art. 17) and the members' duty to keep AML records pull in opposite directions. Art. 17(3)(b) exempts processing necessary for a legal obligation, which covers the members' record-keeping period.

What happens **after** that period is where Mirror's construction helps. A commitment is only linkable to anything through the secret that salted it:

- the corridor secret, for band commitments and locators;
- the network secret, for pKYC entity commitments;
- the receipt or certificate secret, for witness commitments;
- the document salt, for origin commitments.

**Destroying that secret is crypto-shredding.**

- **After:** no one, the members included, can open or re-link any commitment made under it. The operator's signed ledger stays byte-for-byte intact and verifiable; its content is unlinkable for everyone.
- **When:** the destruction is scheduled in the [corridor-key rotation](/corridor-key-rotation.md) plan (`retain_old_until`), after the retention period.
- **Only if nothing holds it:** a litigation hold or a supervisory request stops it first. `mirror-rotation.state()` reports `old_key_shred_due` and names the consequence.
- **Where it happens:** in the members' HSMs, under their dual control. Mirror never holds the secret, so it cannot shred it, and cannot fail to.

## What is not solved here

- **Automated pruning** of pKYC triggers and delivery rows.
- **Retention in a member's own systems:** its bander run logs, its case system, its copies of verdicts. That is the member's schedule.
- **Backups of the operator's store.** They follow the store provider's backup regime (see [sub-processors](/subprocessors.md)). Crypto-shredding covers them too, because what they hold is also unlinkable without the destroyed secret.