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.
[ Privacy and retention ]
Keep what the law requires. Forget what it allows.
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.
01 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.
02 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.
requesterase a personwith a reason
personsigns in freshholds the permission
keydestroyeddata unreadable
ledgershred sealedreplayed on restore
historystill verifiesrecords kept
01
02
The trail outlives the data
The person's sealed values in the audit trail become unreadable with the key, while every entry still verifies.
03
Survives a restore
Each erasure is sealed in the ledger and replayed on every restore, so a backup cannot bring the data back.
04
Records stay whole
The person's identifier, the records about them and the links to them are kept, so nothing else breaks.
05
Reads are on the record
Every read and list of personal data about a person is an access event, in every logging mode.
06
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.
03 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.
01
Stable IDs in the ledger
Every entry names its actor by a pseudonymous ID that never changes.
02
Names resolved on read
A directory resolves IDs to display names for readers who hold its permission, without exposing login names or roles.
03
Disabled people still resolve
A person who has left still resolves to a name, so old history stays readable.
04
Vendor staff apart
Vendor support staff come from a separate identity issuer, and their optional name and email are shown only to the company.
04 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. |
01
Logged before the first byte
The access event is written before content is served, so nothing is read off the record.
02
Sealed like the rest
Access events are sealed into the ledger in segments and can be proven like any other entry.
03
Vendor reads, one by one
Reads by vendor support are logged per read in every mode, never grouped.
05 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.
01
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.
02
A deployment minimum
The deployment sets a minimum period that no type can go below.
03
Cases carry their members
Retention triggers and holds on a case flow to its members, so the members follow their case.
04
Legal holds
A hold blocks disposition and destruction, and extends the store lock where the store enforces one. Narrowing a hold needs approval.
05
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.
06
Configured like everything else
Retention policies ship in approved configuration releases, so every change to them is reviewed and recorded.
06 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.
scheduleretention endsper type
systemproposesdisposition
hold?blocksif active
administratorapprovesor rejects
contentcrypto-shreddedhistory kept
01
Proposed, never automatic
The scan finds what is due and proposes it. Nothing is destroyed until a records administrator approves.
02
Destroyed by key
Destroying the content key makes the stored bytes unreadable. A tombstone keeps the record's identity and history.
03
The ledger still verifies
Audit entries of a destroyed object stay verifiable while their sealed values become unreadable.
04
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.
05
Never under a hold
An early destruction order is refused while a hold is active.
06
Replayed on restore
Destruction entries are sealed and replayed on every restore, so a backup cannot bring destroyed content back.
07 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.
01
Sealed bundles
A disclosure is a deterministic, signed bundle that verifies offline, and can release a redacted copy or a case with its members.
02
Accounting by recipient
For any recipient or any item: every version released, through which disclosure, with digests.
03
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.
08 FAQ
Questions from privacy and records teams.
01How 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.
02Can a backup bring erased data back?
No. Each erasure and each destruction is sealed in the ledger and replayed on every restore.
03What happens when two retention rules disagree?
The longest period that applies wins, and the deployment's minimum period applies to every type.
04Can 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.
05Is 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.
06Can 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 ]
Keep it, hold it, forget it.
Tell us what your customers must keep and what they must erase. We'll show you how retention, holds and erasure fit your product.