# Keep what the law requires. Forget what it allows

> Privacy and retention. Regulations require you to keep records for years, and privacy laws such as the GDPR require you to erase personal data. Tabellix supports both without breaking the audit trail.

## Both at once: Two duties, one system.

Retention says keep it. Privacy says forget the person. Tabellix separates the record from the personal data inside it, so each duty can be met without breaking the other.

### Privacy

- **A key per person.** Personal data about each person that records concern sits under its own key.
- **Erasure by key destruction.** Destroying that key erases the person's data, while the records, their links and the ledger stay intact.
- **Pseudonymous attribution.** The ledger names the people who act by stable IDs. Display names are resolved only when the history is read.
- **Access is logged.** Reads of the personal data held about a person are logged at every level the deployment can set.

### Retention

- **Retention per type.** Periods per record type, including permanent, above a minimum the deployment enforces.
- **Longest period wins.** When rules overlap, the longest period that applies is the one kept.
- **Holds stop the clock.** A legal hold blocks disposition and destruction, whatever the schedule says.
- **People approve disposal.** The system proposes what is due, and records administrators approve it.

## Erasure: Forget the person, keep the record.

Erasing a person destroys the key that protects their personal data. The records about them, their identifier and their links remain, and the ledger still verifies.

1. **erase a person** (request; with a reason)
2. **signs in fresh** (person; holds the permission)
3. **destroyed** (key; data unreadable)
4. **shred sealed** (ledger; replayed on restore)
5. **still verifies** (history; records kept)

- **Erased by a person, never an agent.** Erasure needs a reason, its own permission and a fresh sign-in, and no agent may perform it under any preset.
- **The trail outlives the data.** The person's sealed values in the audit trail become unreadable with the key, while every entry still verifies.
- **Survives a restore.** Each erasure is sealed in the ledger and replayed on every restore, so a backup cannot bring the data back.
- **Records stay whole.** The person's identifier, the records about them and the links to them are kept, so nothing else breaks.
- **Reads are on the record.** Every read and list of personal data about a person is an access event, in every logging mode.
- **Scoped to the people records concern.** Erasure covers the personal data held about the people your records are about, such as patients, customers or claimants.

## Attribution: Who did it, without who they are.

The ledger names the people who act by stable IDs. Names are resolved when the history is read, under their own permission, so the chain carries IDs, not names.

- **Stable IDs in the ledger.** Every entry names its actor by a pseudonymous ID that never changes.
- **Names resolved on read.** A directory resolves IDs to display names for readers who hold its permission, without exposing login names or roles.
- **Disabled people still resolve.** A person who has left still resolves to a name, so old history stays readable.
- **Vendor staff apart.** Vendor support staff come from a separate identity issuer, and their optional name and email are shown only to the company.

## Access logging: Every look, on the record.

Views and downloads are logged before any content is served, at the level the deployment sets. Reads of the personal data held about a person are logged at every level.

| Level | What is logged |
| --- | --- |
| Every access (default) | Every view and every download, each as its own event. |
| Window | Repeated views by the same person within a set window share the first event. Downloads are always logged. |
| Exports | Downloads, exports and prints, and every share, inspector, break-glass and agent access. Staff views are not logged, except reads of the personal data held about a person. |

- **Logged before the first byte.** The access event is written before content is served, so nothing is read off the record.
- **Sealed like the rest.** Access events are sealed into the ledger in segments and can be proven like any other entry.
- **Vendor reads, one by one.** Reads by vendor support are logged per read in every mode, never grouped.

## Retention: Kept exactly as long as required.

Retention is set per record type. When several rules apply, the longest wins, and a hold stops the clock whatever the schedule says.

- **Policies per type.** Each record or document type carries its retention policies: a trigger, a period or permanent retention, and what happens at the end.
- **A deployment minimum.** The deployment sets a minimum period that no type can go below.
- **Cases carry their members.** Retention triggers and holds on a case flow to its members, so the members follow their case.
- **Legal holds.** A hold blocks disposition and destruction, and extends the store lock where the store enforces one. Narrowing a hold needs approval.
- **Store locks where available.** Where the deployer's store supports Object Lock, content can be written locked until its retention ends. That is a per-deployment setting.
- **Configured like everything else.** Retention policies ship in approved configuration releases, so every change to them is reviewed and recorded.

## Disposition: The system proposes. People decide.

When retention ends, Tabellix proposes the disposition and records administrators approve or reject each one. Destruction is crypto-shredding: the content becomes unreadable, and its identity and history remain.

1. **retention ends** (schedule; per type)
2. **proposes** (system; disposition)
3. **blocks** (hold?; if active)
4. **approves** (administrator; or rejects)
5. **crypto-shredded** (content; history kept)

- **Proposed, never automatic.** The scan finds what is due and proposes it. Nothing is destroyed until a records administrator approves.
- **Destroyed by key.** Destroying the content key makes the stored bytes unreadable. A tombstone keeps the record's identity and history.
- **The ledger still verifies.** Audit entries of a destroyed object stay verifiable while their sealed values become unreadable.
- **Lawful early destruction.** Under a legal order, a record can be destroyed early by crypto-shredding, with two distinct approvers, where the deployment allows it.
- **Never under a hold.** An early destruction order is refused while a hold is active.
- **Replayed on restore.** Destruction entries are sealed and replayed on every restore, so a backup cannot bring destroyed content back.

## Disclosures: What left, to whom, and when.

Every release outside the organization is a sealed, signed bundle, and Tabellix keeps an accounting of every disclosure by recipient and by item.

- **Sealed bundles.** A disclosure is a deterministic, signed bundle that verifies offline, and can release a redacted copy or a case with its members.
- **Accounting by recipient.** For any recipient or any item: every version released, through which disclosure, with digests.
- **Redaction by two people.** A redaction is proposed, approved by a second person with a fresh sign-in, and released as an image-only PDF with reason codes.

[Offline verification](https://tabellix.dev/trust/)

## FAQ: Questions from privacy and records teams.

### How can personal data be erased if the audit trail cannot change?

Personal data about each person that records concern is encrypted under its own key. Erasure destroys that key, so the data becomes unreadable, while the ledger entries keep verifying and the records and links stay in place.

### Can a backup bring erased data back?

No. Each erasure and each destruction is sealed in the ledger and replayed on every restore.

### What happens when two retention rules disagree?

The longest period that applies wins, and the deployment's minimum period applies to every type.

### Can records be destroyed before retention ends?

Only where the deployment allows early destruction, under a legal order with two distinct approvers, and never while a hold is active. Destruction is crypto-shredding, and the audit trail still verifies.

### Is access to personal data logged?

Reads and lists of the personal data held about a person are access events at every logging level the deployment can choose. Other views and downloads are logged at the level the deployment sets.

### Can an AI agent erase data or dispose of records?

An agent never erases a person's data, places a hold or proposes a disposition, under any preset. Approving a disposition is open to an agent only if the deployer turns that switch on under the flexible preset.

## Contact

Tell us what your customers must keep and what they must erase. We'll show you how retention, holds and erasure fit your product.

Contact form: https://tabellix.dev/contact/

---

This page as HTML: https://tabellix.dev/privacy-retention/ · [Site guide for language models](https://tabellix.dev/llms.txt)