Retention and legal hold

Cordy commented

2026-07-29 23:20:00 +00:00

Owner

Derived from the public-sector analysis (#59, docs/PUBLIC-SECTOR.md). Records regimes impose minimum-keep periods and litigation holds; today anything can be deleted (trash softens but does not prevent — trash can be emptied, and admins can delete inside /.trash).

Scope:

Retention — per-space (and optionally per-path-prefix) minimum-keep: a file may not be permanently deleted until mtime + retention has passed. Deletes inside the window go to trash as usual; purging from trash is refused until the window ends.
Legal hold — admin marks a path (file or subtree) as held: no delete, no overwrite, no rename, by anyone including admins, until the hold is lifted. Holds and their lift events belong in the audit log (#61).
Storage: sidecar JSON per hold + a policy section in the settings store — no database.
Enforcement at the storage decorator chokepoint (covers web/REST/WebDAV/TUS uniformly).

Explicitly out of scope: WORM/immutability guarantees against a hostile root operator — that layer belongs to backend snapshots/object-lock and is documented as such (same delegation decision as versioning, #23).

Acceptance: purge inside retention window → 403 with a clear error; held file rejects delete/overwrite/rename from web + WebDAV; lifting the hold restores normal behavior; hold set/lift visible in audit output.

Derived from the public-sector analysis (#59, docs/PUBLIC-SECTOR.md). Records regimes impose minimum-keep periods and litigation holds; today anything can be deleted (trash softens but does not prevent — trash can be emptied, and admins can delete inside `/.trash`). **Scope:** - **Retention** — per-space (and optionally per-path-prefix) minimum-keep: a file may not be permanently deleted until `mtime + retention` has passed. Deletes inside the window go to trash as usual; *purging* from trash is refused until the window ends. - **Legal hold** — admin marks a path (file or subtree) as held: no delete, no overwrite, no rename, by anyone including admins, until the hold is lifted. Holds and their lift events belong in the audit log (#61). - Storage: sidecar JSON per hold + a policy section in the settings store — no database. - Enforcement at the storage decorator chokepoint (covers web/REST/WebDAV/TUS uniformly). **Explicitly out of scope:** WORM/immutability guarantees against a hostile root operator — that layer belongs to backend snapshots/object-lock and is documented as such (same delegation decision as versioning, #23). **Acceptance:** purge inside retention window → 403 with a clear error; held file rejects delete/overwrite/rename from web + WebDAV; lifting the hold restores normal behavior; hold set/lift visible in audit output.