Archive, retain and erase personal data
Archiving closes an edition’s visible lifecycle. Retaining, exporting and erasing personal data follow separate rules. Creating a technical database backup is not privacy processing.
Archive an edition
First inspect outstanding obligations: communication, orders, compensation and processing. Archive the intended edition and verify it disappears from regular public and administration selections. Archiving retains associated records and can be reversed.
Check retention
Treat profile details, practical answers, emergency contacts, messages, audit and financial documents as different categories. Their clocks can start from different events. “Delete everything after 30 days” is not an Omnia rule.
Check installation settings and module obligations before worker upgrades or cleanup sweeps. Do not retain data indefinitely because it might someday be useful.
A retention period can be counted in days or, since the reviewed revision, in calendar months from the end of the edition in the event’s time zone. No category uses months yet. Operators find the settings under operations.
Assistant activity and the MCP audit
Each call to an MCP tool leaves one audit record with metadata only: time, kind of actor, tool, operation reference and outcome. Arguments, results and credentials are not stored.
- A person can read their own assistant activity through the API
(
/v1/me/assistant-activity). - Staff with identity management can read the
organisation-wide view (
/v1/admin/assistant-activity). - Records are kept 60 days by default; operators can change this period.
- The MCP audit takes part in person erasure: records where the person was the actor or the responsible person are deleted.
There is no screen for either view yet. See integrations for what assistant connections can and cannot do.
Which registration terms an attendee accepted
Each ticket type’s registration terms have a version number (see registration terms and their version). A sponsor lead disclosure is specified to record the version that applied at the scan (LEAD-003, PRIV-006), so you can tell which wording a disclosure rested on even after the terms changed. Today Commerce stores the version and offers it to other modules; the lead scan that records it is not built, so no disclosure carries a version yet. Only the current version is kept as a number. The earlier wording itself is not kept by this feature, so export or note the text before changing it if you must be able to show it later.
Track an erasure request
The specification requires identity verification, suitable confirmation, a cooling-off period where applicable and processing by every relevant domain. Keep progress and restrictions visible.
A CFP success alone does not establish completion in Commerce, files and Identity. The overall result must not be marked complete while a relevant domain remains unhandled.
Under the specification, person erasure retains the person ID without its personal data and introduces no pseudonym for that person. Records retained for a required obligation have bounded reasons and access. A new registration using the same address does not automatically reconnect the erased person.
Erasure foundation in the reviewed revision
Person erasure is switched off by default and is not yet a usable end-user service. The production erasure flow, with all per-domain outcomes, is still open (platform #1821). What exists is the coordination between domains and a first set of participants. Each domain reports its own outcome, for example Erased, PersonalDataRemoved, NothingHeld or Failed:
| Domain | What happens |
|---|---|
| Commerce: waitlist | Entries for the person are erased, or the domain reports that it holds nothing. |
| Commerce: orders, tickets, ticket transfers | Personal data is removed while the rows stay on the same person ID; no pseudonym is introduced. |
| Sponsors: acceptance journal | Nothing is deleted; PersonalDataRemoved means only the person ID remains. |
| Identity: action-link receipts | Receipts about the person are erased. |
| Forms: personal data | Takes part as its own domain. |
| Integrations: MCP audit | Records where the person was actor or responsible person are deleted. |
A failure in one domain is reported for that domain only. Other personal-data categories still count as unhandled, so a request cannot be marked complete yet.
Action-link receipts. Every confirmed completion of an action link, such as claiming a ticket or confirming a sponsor acceptance, now writes a Confirmed receipt. After a cleanup sweep, a confirmed claim therefore reads as confirmed instead of unknown. Sponsor recovery confirms the receipt after settlement. A rejected completion writes no receipt yet (#2577 open) and can still read as unknown. Unacknowledged receipts are removed after 30 days by default.
This page describes product behaviour and operational checks, not general legal retention advice. A full cross-module erasure test belongs in acceptance of the installed release.