Retention Periods
How long each category of data is kept, and what the service actually does today.
Last revised: 20 August 2026.
This document states what the service does today, not what it is meant to do one day. The table covers only Operifex storage: its own database and file storage. Provider-side retention terms are in the Subprocessors document. Where there is no automatic deletion, it says there is none.
| Data | Today | Intended period |
|---|---|---|
| Single-use access link | Valid for fifteen minutes and usable once. The record stays in the database after it expires. | The record is deleted thirty days after expiry. |
| Signed-in session | The session credential expires after seven days. It can be revoked sooner. | Unchanged. |
| Account and email address | Kept for as long as the account exists. | Erased within thirty days of an erasure request. |
| Conversations and generated answers | Kept indefinitely. There is no automatic cleanup and no history limit. | Twelve months after the session was last used, or erasure on request, whichever comes first. |
| Experts, apps and published versions | Kept for as long as the account exists. Published versions are immutable by design. Work saved under the previous structure before 8 August 2026 was archived rather than destroyed, and is still kept on the same terms. | Erased with the account, except for anything you published to the catalog, which is dealt with in the second-to-last row of this table. |
| Knowledge files and their change history | Kept for as long as the account exists, with the history of changes. | Erased with the account. |
| Workspace on the server | Kept on disk. Some workspaces outlive the account that created them, which is a known defect. | Erased with the account, within the same thirty days. |
| Mail sent and received | Recipient, subject and a delivery identifier are recorded. Received mail is kept on disk. | Twenty-four months, to be able to evidence delivery. |
| Approvals and run records | Kept indefinitely. Nothing prunes them. | Twenty-four months. |
| Server technical logs | Rotated by the operating system. They may contain email addresses. | Thirty days. |
| Entries you published to the catalog | They survive the erasure of the account, by decision. Before an entry is published it goes through a process that makes it generic and strips private information from it, and it is credited only to a creator name that is not linked to your account. On erasure the link to the account is severed and the entry stays published. | Unchanged: the entry is not withdrawn. If the creator name contains your address it is replaced by a pseudonym at the moment of erasure. |
| Record of shares other accounts granted to your address | Kept indefinitely. It is another account’s audit record: it shows who was given access, to which resource, and when. | The row is kept and your address is replaced, at the moment of erasure, by a pseudonym computed with a keyed hash function. The share stays provable and countable; it no longer identifies anybody. The pseudonym cannot be turned back into the address. |
An erasure request sent to the privacy address is carried out against the database and against the account’s workspace, and it reaches every row of this table except the last two: the entries you published to the catalog stay published, and the rows of other accounts’ sharing records stay, with your address replaced. Both exceptions are described in their own rows; they are decisions taken openly, not omissions.
Continue to Home