docs(postbox): define function-bound encrypted vault semantics

docs/POSTBOX_CONCEPT.md

@@ -4,7 +4,13 @@
 
 GovOPlaN Postbox provides in-platform postboxes that are addressable containers for messages, files, workflow evidence, and operational handoff. They can be used internally, exposed through portals, and connected to campaign workflows.
 
-The key distinction from a mailbox is ownership. A mailbox is usually bound to a login, user credential, or external mail account. A GovOPlaN postbox is bound to platform context: organization, role, process, portal, campaign, or service responsibility.
+The key distinction from a mailbox is ownership. A mailbox is usually bound to
+a login, user credential, or external mail account. A GovOPlaN postbox is a
+durable communication and content-access container bound to institutional
+context: primarily a function in an organizational unit, and where explicitly
+needed a role, process, portal, campaign, or service responsibility. It may look
+like an inbox for a message task or like a vault for content shared with the
+current holders of that responsibility; neither form is owned by one account.
 
 The strategic target is an encrypted administrative postbox. The first
 implementation may start with ordinary persisted messages, but the model must
@@ -31,6 +37,13 @@ role for `District Office North` can see the postbox. When the function,
 delegation, or role mapping is removed or expires, access disappears without
 moving messages or reassigning a mailbox.
 
+The postbox exists independently of its holders. It remains addressable while
+the function is vacant and may accept durable deliveries according to policy;
+the UI must then show that no current human holder can open or act on the
+content. Assigning one or several incumbents grants access in their explicit
+function context. It does not transfer ownership of the container or rewrite
+its history.
+
 This makes postboxes useful for responsibilities that outlive individuals:
 
 - intake desks
@@ -39,6 +52,24 @@ This makes postboxes useful for responsibilities that outlive individuals:
 - portal message inboxes for organizational responsibilities
 - file or evidence drops linked to a role in an organization
 
+### Incumbency, hand-over, and delegation
+
+- Zero, one, or several people may hold a function at the same time.
+- A postbox can remain vacant without being deleted, redirected to a personal
+  account, or losing content.
+- A new assignment can grant access to the function's permitted history through
+  a current key epoch. Which historical epochs a new incumbent receives is an
+  explicit postbox policy, not an accidental consequence of account creation.
+- A delegation is a time-bounded access grant in the represented function
+  context. Expiry removes future platform key access and action authority; it
+  cannot destroy plaintext or exports already obtained.
+- Hand-over and revocation rotate the function/postbox key epoch. Per-content
+  data keys should normally be rewrapped; policy may require content
+  re-encryption for a stronger rotation event.
+- Stored content is not silently substituted or overwritten. A correction,
+  replacement, or new version is a new linked object with provenance while the
+  previous signed/ciphertext manifest remains governed by retention policy.
+
 ## Authorization Model
 
 Postbox authorization should be derived from access-owned identity and role data through core/access contracts. The postbox module stores postbox bindings and postbox-specific permissions, but it should not duplicate membership, group, or role resolution.
@@ -106,8 +137,14 @@ Optional consumers:
 
 ## Operational Rules
 
-- Current role state controls current access.
-- Historical message records remain durable even when no current person holds the role.
+- Current function assignment and delegation state controls current access.
+- Historical message records remain durable even when no current person holds
+  the function; vacancy is a visible attention/access state, not a missing
+  postbox.
+- Multiple incumbents receive independent device-bound key grants and remain
+  distinguishable in access and action evidence.
+- Delegation start, expiry, withdrawal, key grant, and key-epoch rotation are
+  separate auditable events.
 - Administration of bindings should require explicit postbox administration permission plus access/RBAC authority for the target organization.
 - Sensitive access decisions and binding changes should emit audit events.
 - Retention rules should be postbox-owned but able to reference campaign, file, and portal provenance.
@@ -194,3 +231,19 @@ Before the data model is considered stable, verify that it can represent:
 - external recipient token state
 - expiry and withdrawal state separate from deletion
 - retention state that can operate without decrypting content
+
+## E2EE decisions still to settle before implementation
+
+The product direction above is selected, but the first trusted profile still
+needs bounded decisions on:
+
+- whether a new incumbent receives all retained history, history from a
+  policy-defined date, or only content delivered during the assignment;
+- organizational recovery/escrow and the authority required when every holder
+  loses all registered device keys;
+- whether ordinary rotation only rewraps per-content keys or also re-encrypts
+  ciphertext, and which events require the stronger path;
+- assurance and quorum requirements for delegation, hand-over, emergency
+  access, export, and destructive retention; and
+- how attention/escalation works during a vacancy without granting plaintext
+  access to an unrelated personal account.