diff --git a/docs/POSTBOX_CONCEPT.md b/docs/POSTBOX_CONCEPT.md
index e8ee430..6c13a95 100644
--- a/docs/POSTBOX_CONCEPT.md
+++ b/docs/POSTBOX_CONCEPT.md
@@ -117,6 +117,57 @@ Optional consumers:
   key epochs, recipient device references, and external capability tokens even
   before full E2EE ships.
 
+### Retention, Audit, And Privacy
+
+Postbox retention is owned by the postbox module because postbox messages are
+platform-native communication records, not mailbox folders and not ordinary file
+shares. Retention policies may reference provenance from campaign, file, portal,
+mail, or workflow modules, but those modules should pass stable ids and typed
+evidence references through capabilities instead of giving postbox direct access
+to their internals.
+
+The postbox module should emit audit events for:
+
+- postbox creation, archival, and destructive retirement
+- binding creation, changes, expiry, and removal
+- sensitive access checks when an actor gains or loses visibility
+- message creation, read/download of sensitive content, attachment linking, and
+  delivery handoff
+- retention holds, retention expiry, export, and destruction decisions
+
+Privacy behavior must separate current access from historical evidence. Losing
+a role removes future visibility, but it does not rewrite the fact that a person
+previously accessed a message or that a message existed. Deletion and
+destructive retention actions must preserve legally required audit/evidence
+records while removing or redacting content according to the effective policy.
+
+When E2EE is enabled later, retention and audit metadata must remain operable
+without decrypting message content. UI copy should be honest: expiry,
+withdrawal, or revocation can prevent future platform access, but it cannot
+guarantee removal of plaintext already fetched, exported, printed, or delivered
+outside the platform.
+
+### Migration And Compatibility Ownership
+
+Postbox-owned tables, DTOs, migrations, and capability names belong in
+`govoplan-postbox`. Core may temporarily contain compatibility imports or
+legacy migration references only when needed to keep existing installations
+upgradable while code is being extracted.
+
+Compatibility code must be narrow and documented:
+
+- new postbox behavior is implemented in `govoplan-postbox`
+- old import paths may re-export postbox DTOs or helpers during a transition,
+  but must not become active owners of postbox logic
+- migrations that move tables to postbox ownership must preserve existing data
+  and have explicit downgrade/retirement notes
+- optional integrations with campaign, files, portal, or mail remain capability
+  contracts, not direct imports
+
+Once supported release migrations have crossed the compatibility window, legacy
+core import aliases and old table ownership comments should be removed through
+a normal cleanup issue.
+
 ## First Implementation Shape
 
 The first implementation should define the backend manifest, permissions, DTOs, and migrations before building rich UI. A minimal API can then support directory lookup, access checks, message creation, message listing, and binding administration.