Versions

Conderis distinguishes two ways of removing something, because they answer different needs.

	Archive	Permanent deletion
For	Outdated or finished items	Text that must not be kept, such as data posted by mistake
Tool	item_archive	item_delete
History	Kept	Every affected revision and proposal is removed
Reversible	Yes	No
Review	None	Required

Permanent deletion step by step

1. Request. The content is marked PrivacyRestricted and disappears at once from every read, including history, recall, exports and proposals. The global query filters in AppDb do this, so no feature has to remember it.
2. Review. A project moderator, or the owner of a private memory, approves in Moderation or with privacy_deletion_review. Rejecting keeps the content restricted.
3. Purge. Rows are deleted in one transaction. A failed purge rolls back and can be retried.

The audit record keeps identifiers, actors, times and status, never the original text.

What can be deleted

• Memories and tasks. Subtasks of a deleted task stay and are detached.
• Documentation pages. Subpages move up to the deleted page's parent.
• Single earlier versions of a page, a memory or the project instructions, with item_delete(revisionId). The published version is refused; publish a corrected version first. The revision chain is reconnected around the removed version.

Surviving a restored backup

Every request is also appended to a journal outside the database. At startup the journal is replayed, so restoring an older database backup cannot bring deleted content back.

Limits

Deletion cannot recall copies that already left the server, such as exports, agent conversations or text pasted into another item. Each copy inside Conderis needs its own request.